New Relic NPM へのプロファイル登録チュートリアル

New RelicのNPM（NetworkPerformanceMonitoring）ではSNMPを利用しネットワーク機器のパフォーマンス情報を収集します。

実際にネットワーク機器に対してSNMP Pollingを行うドッカーコンテナであるktranslate にはあらかじめい様々なネットワーク機器ベンダーのMIBが情報登録されてるいます。

しかし、全てのベンダーのMIB情報が登録されているわけではありません。

この記事ではお客様がご利用しているネットワーク機器のMIB情報をktranslateで利用する方法をご案内します。

YAMLファイル

ktranslate ではSNMPポーリングを行うためのOIDの情報をyaml ファイルに記載します。

このYamlファイルの構成をご紹介します。

この構成の原文はGithubのWikiをご確認ください。

YAMLファイルの構造

YAMLファイルは3つセクションによって構成されます。

extends

YAMLファイル同士の依存関係を記述します。ネットワーク機器のSNMPオブジェクトは、MIB（Management Information Base）ツリーとしてDNSの名前解決のようなツリー上の依存関係を持ちます。

このMIBツリーの依存関係をYAMLファイル同士の依存関係として継承したい上位のYAMLファイルを定義します。

このセクションにはファイル名のみを記載します。記載されたファイルが見つからない場合はランタイムErrorが発生します。

extends:
  - system-mib.yml
  - if-mib.yml

sysobjectid

このYAMLファイルで定義するシステムオブジェクトのOID（オブジェクトID）を記載します。

MIBツリーにおける、このファイルで定義するレベルのオブジェクトのIDをOID形式で記載します。オブジェクト名形式では記載できません。

OIDにはワイルドカードを指定する事もできます。

sysobjectid: 1.3.6.1.4.1.9.1.111

sysobjectid:
  - 1.3.6.1.4.1.9.1.111
  - 1.3.6.1.4.1.9.1.170

sysobjectid: 1.3.6.1.4.1.25461.*

metrics

先のsysobjectid で指定したオブジェクトから実際に収集するMetrics情報を定義します。

MetricsセクションではMIB名、OID、オブジェクト名を記載し、OIDの構造に合わせてSynbol型とTable型が指定出来ます。

Synbol型はそのOIDから一意の値が返るオブジェクト、

Table型はポート毎のトラフィックのようにモジュール毎に複数の値が返るようなオブジェクトで利用されます。

metrics:
  - MIB: PAN-COMMON-MIB
    symbol:
      OID: 1.3.6.1.4.1.25461.2.1.2.3.1.0
      name: panSessionUtilization
  - MIB: PAN-COMMON-MIB
    symbol:
      OID: 1.3.6.1.4.1.25461.2.1.2.3.2.0
      name: panSessionMax

上記のMetrics記述では、ktranslateはkentik.snmp.panSessionUtilization とkentik.snmp.panSessionMaxという2つの値を収集します。

  - MIB: PAN-ENTITY-EXT-MIB
    table:
      OID: 1.3.6.1.4.1.25461.1.1.7.1.2.1
      name: panEntityFRUModuleTable
    symbols:
      - OID: 1.3.6.1.4.1.25461.1.1.7.1.2.1.1.1
        name: panEntryFRUModulePowerUsed
      - OID: 1.3.6.1.4.1.25461.1.1.7.1.2.1.1.2
        name: panEntryFRUModuleNumPorts
    metric_tags:
      - MIB: ENTITY-MIB
        column:
          OID: 1.3.6.1.2.1.47.1.1.1.1.2
          name: entPhysicalDescr
        table: entPhysicalTable
        tag: entity_description

上記のYAMLファイルでの場合は次のような構造になっています。

    table:
      OID: 1.3.6.1.4.1.25461.1.1.7.1.2.1
      name: panEntityFRUModuleTable

テーブル形式でOID 1.3.6.1.4.1.25461.1.1.7.1.2.1 の情報を取得し、複数あるFRUModuleをリストとして収集します。

    symbols:
      - OID: 1.3.6.1.4.1.25461.1.1.7.1.2.1.1.1
        name: panEntryFRUModulePowerUsed
      - OID: 1.3.6.1.4.1.25461.1.1.7.1.2.1.1.2
        name: panEntryFRUModuleNumPorts

そして、そのテーブルに対して

panEntryFRUModulePowerUsedとpanEntryFRUModuleNumPorts の値をMetricsとして収集します。

    metric_tags:
      - MIB: ENTITY-MIB
        column:
          OID: 1.3.6.1.2.1.47.1.1.1.1.2
          name: entPhysicalDescr
        table: entPhysicalTable
        tag: entity_description

そして収集した値に対してentPhysicalDescr をtag情報として付与します。

Enums 型

UPSやPDUなど測定値はなく、機器のstatusを数値型で返す機器があります。

この際に利用出来るのがEnums型です。

      - OID: 1.3.6.1.4.1.318.1.1.12.2.3.1.1.3
        name: rPDULoadStatusLoadState
        enum:
          phaseLoadNormal: 1
          phaseLoadLow: 2
          phaseLoadNearOverload: 3
          phaseLoadOverload: 4

この定義によって1～4の値を文字列のstatusとマッピングします。

この定義がある場合、実際に収集される値は1～4の整数値ですが、同時にrPDULoadStatusLoadState として文字列型のattributeが作成されます。

これにより、人間による可読性が高いDataを作成することができるようになります。

タグ定義

YAMLでタグを定義することによりEntity名をわかりやすいタグに置き換える事ができます。

      - OID: 1.3.6.1.4.1.9.9.109.1.1.1.1.7
        name: cpmCPUTotal1minRev
        tag: CPU

16進数のエンコード

ネットワーク機器の中には、SNMPの応答値を16進数で返す物があります。16進数のDataをそのまま受け取った場合、通常の数値として大小関係を比較することが出来ないため、明示的に10進数への変換方法を定義する必要があります。

エンコード方法はconversionセクションで定義します。

変換方法の書式は

hextoint:BigEndian|LittleEndian:uint64|uint32|uint16

となります。

hextoint 固定

BigEndian ：ABCDEF の大文字で16進数を表現する

LittleEndian： abcdef の小文字で16進数を表現する

uint64：0から18446744073709551615までの符号無し整数

uint32：0から4294967295までの符号無し整数

uint16：0から65535までの符号無し整数

      - column:
          OID: 1.3.6.1.2.1.75.1.2.1.1.1
          name: portIndex
        tag: port_index
        conversion: hextoint:BigEndian:uint16

カスタムプロファイルの利用

このBlogの手順によってYAMLファイルを作成することによって、お客様環境独自でのYAML定義を作成することができます。

独自に作成された、YAMLファイルはktranslateには含まれていません。

このプロファイルを2つめのボリュームとしてktranslateコンテナにマウントしてご利用いただくことでプライベートプロファイルとしてご利用いただくことができるようになります。

公式コンテナイメージへの取り込みリクエスト

お客様環境独自の監視では無く、多くのお客様にメリットがありそうな監視項目やネットワーク機器に付いての定義はGithubからリクエストを行っていいただく事ができます。

この場合はお客様自身でYAMLファイルを作成いただく必要はありません。

YAMLファイルの作成はsnmp-profiles リポジトリで実施するためその元となる

ベンダー名
モデル名
OIDファイル
認証情報等の個別情報を含まない状態でのsnmpwalkの結果

以上の情報を付与してリクエストを起票してください。

起票方法の詳細は[速報版] Network Performance Monitoringに新たなSNMP Profileを登録するための手順をご確認ください。

備考

プライベートYAMLファイルの拡張子

ファイル拡張子はyamlでもymlでもご利用可能です。
ただし、どちらか片方に統一してください。

MIBファイルからのYAMLファイルの自動生成

MIBファイルが手元にある場合、以下の手順でYAMLファイルを自動生成することができます。

pysmiをインストールします。(pip install pysmi)
librenmsをインストールします。(git clone https://github.com/librenms/librenms.git)
MIBファイルを、tmp/snmp_inディレクトリに配置します。YAMLファイル出力用のtmp/snmp_outディレクトリも作成します。
pysmi に含まれるmibdumpコマンドを実行します。
mibdump コマンドはMIBファイルからjson ファイルを生成します。
出来上がったjsonファイルをyamlファイルに変換します。

mibdump コマンドの書式は次の通りです。

mibdump.py --mib-source=file:///path/to/src/librenms/mibs --mib-source=file:///tmp/snmp_in --generate-mib-texts --ignore-errors  --destination-format json --destination-directory=/tmp/snmp_out MY_MIB_NAME

例として、ZSCALER-NSS-MIBというmibファイルを使用し、librenms が /home/me/src/librenms にインストールされている場合は次のようなコマンドになります。

mibdump.py --mib-source=file:///home/me/src/librenms/mibs --mib-source=file:///tmp/snmp_in --generate-mib-texts --ignore-errors  --destination-format json --destination-directory=/tmp/snmp_out ZSCALER-NSS-MIB

ktranslate を利用してjsonファイルをyamlファイルに変換します。

変換コマンドの書式は次の通りです。

docker run --rm -v /tmp/snmp_out:/snmp_out kentik/ktranslate:v2 -snmp /etc/ktranslate/snmp-base.yaml -snmp_json2yaml /snmp_out/MY_MIB_NAME.json

先ほど例にしたZSCALER-NSS-MIB.json を変換する場合は次のようなコマンドになります。

docker run --rm -v /tmp/snmp_out:/snmp_out kentik/ktranslate:v2 -snmp /etc/ktranslate/snmp-base.yaml -snmp_json2yaml /snmp_out/ZSCALER-NSS-MIB.json

このコマンドにより/tmp/snmp_out/ZSCALER-NSS-MIB.yaml が出力されます。

最終調整

自動生成されたYAMLファイルは完璧ではありません、手動により調整と確認を行ってください。必要なチェックは次の通りです、

extends:セクションを追加します。
sysobjectid:セクションが存在し、書式が崩れていない事を確認します、必要に応じて修正してください。

まとめ

MIB ファイルからYAMLファイルを作成し、ktranslateコンテナのセカンドボリュームとしてマウントしていただく事で、お客様環境独自のネットワーク機器の情報を収集するようにktranslateを拡張していただく事ができます。

また、他のお客様でも汎用的に使えるようなモニタリング項目の場合は、snmpwalk などの必要な情報を付けて、プロファイルリクエストを行っていただく事で、公式のktranslate イメージにプロファイルを組み込む事もできます。

まだまだ、日本のネットワークベンダーのプロファイルは少ないのが現状です是非リクエストを作成していただき、New Relic NPMの拡張にご協力ください。

By 伊藤覚宏, LeadTechnicalSupportEngineer

New Relic株式会社　リードテクニカルサポートエンジニア OSSの運用監視ソフトウェアの日本におけるテクニカルサポート、テクニカルトレーニングの立ち上げを行い、VMwareベースのクラウドサービス開発、AWSテクニカルサポート、クラウドアーキテクトを経て現職。テクニカルサポート、テクニカルトレーニング、運用コンサルを専門領域としてお客様の運用負荷軽減を目指す。得意分野は運用設計、クラウド設計、OSSソフトウェア。

The views expressed on this blog are those of the author and do not necessarily reflect the views of New Relic. Any solutions offered by the author are environment-specific and not part of the commercial solutions or support offered by New Relic. Please join us exclusively at the Explorers Hub (discuss.newrelic.com) for questions and support related to this blog post. This blog may contain links to content on third-party sites. By providing such links, New Relic does not adopt, guarantee, approve or endorse the information, views or products available on such sites.

New Relic NPM へのプロファイル登録チュートリアル

780+ integrations to start monitoring your stack for free.

See All Integrations

In this article

New Relic NPM へのプロファイル登録チュートリアル

MIBファイルをプロファイルに変換して登録する方法

YAMLファイル

YAMLファイルの構造

extends

sysobjectid

metrics

Enums 型

タグ定義

16進数のエンコード

カスタムプロファイルの利用

公式コンテナイメージへの取り込みリクエスト

備考

プライベートYAMLファイルの拡張子

MIBファイルからのYAMLファイルの自動生成

最終調整

まとめ

Tags

Related