最新のアップデートの詳細はこちら
New Relic アップデート(2023年2月)
New Relic アップデート一覧
はじめに
まずは設定方法だけを抑えたい!!という方はこちらに一気にジャンプして下さい。
ネットワークの運用監視に関わっているエンジニアの皆様、こんにちは。New Relicではネットワーク運用監視を行っている方向けにNetwork Performance Monitoring(通称: NPM)を提供しています。さまざまな機能を提供しているのですが、SNMP、Syslog、Network Flowといった様々なプロトコルに対応しています。(ソリューションの概要はこちらです。)
既にNew Relicの公式ブログでは公開されているのですが、Linux上でのNPMの導入をパッケージマネージャ経由で行うことができるようになっており、そちらを試すのと合わせて、SNMPプロファイルのカスタム登録も気軽に行えたので、記録してみようと思います。
SNMPプロファイルってなに？
New Relicが提供するNPMに限らず、SNMPを用いて機器の情報を収集するツールやソリューションを用いる場合、どのデータを取得するかという定義は非常に重要です。しかしながら、ベンダーや機器モデルによって特定のデータを取得するための番号(ObjectIDやOIDと呼ばれています)が異なっていることもあり、一般的に機器のモデル毎に適切なデータ項目とOIDの紐付けが重要となります。このマッピングを行なっている定義ファイルのことを、NPMではSNMPプロファイルと呼んでいます。
そもそも...
NPM自体は元々はdockerのコンテナイメージとして提供されていました。dockerイメージの取得方法や起動方法についてはNew Relicが具体的なコマンドとして提供は行っていました。
一方で、SNMP対応の機器をカスタムして登録したりするという作業を行う場合は、プロファイル情報を作成したり編集したりという作業が必要で、かつ、その変更したファイルをコンテナにマウントして・・・という、ネットワーク畑のエンジニアにはちょっと気が重い作業(個人的な意見です💦)が必要でした。パッケージマネージャにてインストールができることから、Linux上でプロファイルの作成や編集を直接行うことができるので、難しいことを考えずにやりたいことだけを実施すれば良くなりました。ネットワークエンジニアなら、Linux上のコマンドライン作業は日々の業務でやっているだろうと(これも個人的な意見です💦)
早速やってみた
先ほどご紹介したブログに従って導入を進めました。具体的なコマンドは、ブログにある通り、New Relicが生成して提供してくれます。
以下はNPM導入後に実施するサービスの再起動のコマンドです。サービスの起動停止は、一般的なサービス同様にsystemctlを利用でき、サービス名はktranslateとなっています。
*** 後述するSNMPプロファイル作成後にNPMの再起動を行うのですが、自分の検証時に再起動コマンドを失念してしまい無駄に時間を溶かしたので、備忘録も兼ねて。(NPMはとても安定稼働するので、サービス再起動のコマンドは忘れがちです。。)
sudo systemctl restart ktranslate
以前、公式ブログでdockerイメージを用いたNPMの導入を書いたのですが、パッケージマネージャを用いた場合でもまったく違いはありませんでした。
パッケージマネージャで導入することで嬉しかったこと
最初の方でも記載させて頂いていますが、各ネットワーク機器のSNMPプロファイル(どういったMIBの情報を取得するかを定義する)を作成したり編集したイルするのがとても簡単です。もちろんdockerでも同じことを行うことはできますが、ずっと編集作業のハードルが低いのは想像がつくかと思います。
このカスタムを気軽に行うことで、
- NPMがデフォルトで収集する項目以外にもデータを追加で収集する (例: Private MIBで定義された機器固有のデータ)
- NPMがデフォルトで提供しているベンダーや機器以外の機器に対してもSNMPデータを収集する (例: ニッチな機器やテスト目的の最新機器を用いる場合など)
といったことが可能となります。
SNMPプロファイルのカスタム方法について
具体的なカスタム方法を説明する前に、簡単にNPMの重要なファイル構成がどうなっているかを説明します。ここの構成を理解するとカスタム作業の大部分を理解することができます。
NPMのファイル構成
NPMをパッケージマネージャで導入してもらうと、/etc配下にktranslateというディレクトリが作成され、非常に多くの設定ファイルが配置されます。
/etc/ktranslate$ ll
total 14308
drwxr-xr-x 4 ktranslate ktranslate 4096 Dec 18 01:49 ./
drwxr-xr-x 99 root root 4096 Jan 23 06:09 ../
-rw-r--r-- 1 ktranslate ktranslate 8298464 Dec 12 21:09 GeoLite2-ASN.mmdb
-rw-r--r-- 1 ktranslate ktranslate 6259206 Dec 12 21:09 GeoLite2-Country.mmdb
-rw-r--r-- 1 ktranslate ktranslate 2931 Dec 12 21:09 config.json
-rw-r--r-- 1 ktranslate ktranslate 38277 Dec 12 21:09 devices.json
drwxr-xr-x 2 ktranslate ktranslate 4096 Dec 16 22:56 mibs.db/
drwxrwxr-x 6 ktranslate ktranslate 4096 Dec 16 22:56 profiles/
-rw-r--r-- 1 ktranslate ktranslate 1913 Jan 26 04:50 snmp-base.yaml
-rw-r--r-- 1 ktranslate ktranslate 22001 Dec 12 21:09 udr.csv
この中でもprofiles配下に各ネットワーク機器のプロファイルが配置されています。
具体的には以下の通りです。
/etc/ktranslate/profiles/profiles/kentik_snmp$ ll
total 368
drwxrwxr-x 89 ktranslate ktranslate 4096 Dec 18 01:05 ./
drwxrwxr-x 3 ktranslate ktranslate 4096 Dec 16 22:56 ../
drwxrwxr-x 2 ktranslate ktranslate 4096 Dec 16 22:56 3com/
drwxrwxr-x 2 ktranslate ktranslate 4096 Dec 16 22:56 _general/
-rw-rw-r-- 1 ktranslate ktranslate 5891 Dec 16 22:56 _template.yml
-rw-rw-r-- 1 ktranslate ktranslate 1675 Dec 16 22:56 _trap_template.yml
drwxrwxr-x 2 ktranslate ktranslate 4096 Dec 16 22:56 a10_networks/
︙
︙
︙
drwxrwxr-x 2 ktranslate ktranslate 4096 Dec 16 22:56 brocade/
drwxrwxr-x 2 ktranslate ktranslate 4096 Dec 16 22:56 brother/
drwxrwxr-x 2 ktranslate ktranslate 4096 Dec 16 22:56 checkpoint/
drwxrwxr-x 2 ktranslate ktranslate 4096 Dec 16 22:56 chrysalis/
drwxrwxr-x 2 ktranslate ktranslate 4096 Dec 16 22:56 cisco/
drwxrwxr-x 2 ktranslate ktranslate 4096 Dec 16 22:56 citrix/
drwxrwxr-x 2 ktranslate ktranslate 4096 Dec 16 22:56 cradlepoint/
drwxrwxr-x 2 ktranslate ktranslate 4096 Dec 16 22:56 cyberpower/
drwxrwxr-x 2 ktranslate ktranslate 4096 Dec 16 22:56 dell/
︙
︙
︙
drwxrwxr-x 2 ktranslate ktranslate 4096 Dec 16 22:56 vmware/
drwxrwxr-x 2 ktranslate ktranslate 4096 Dec 16 22:56 western_digital/
drwxrwxr-x 2 ktranslate ktranslate 4096 Dec 16 22:56 zebra/
drwxrwxr-x 2 ktranslate ktranslate 4096 Dec 16 22:56 zyxel/
/etc/ktranslate/profiles/profiles/kentik_snmp配下にベンダー名のディレクトリが作成されており、ベンダー名のディレクトリ配下には具体的なプロファイル(ymlファイル)が配置されています。
_general用のディレクトリは以下のプロファイルが配置されていました。
/etc/ktranslate/profiles/profiles/kentik_snmp/_general$ ll
total 96
drwxrwxr-x 2 ktranslate ktranslate 4096 Dec 16 22:56 ./
drwxrwxr-x 89 ktranslate ktranslate 4096 Dec 18 01:05 ../
-rw-rw-r-- 1 ktranslate ktranslate 3646 Dec 16 22:56 bgp4-mib.yml
-rw-rw-r-- 1 ktranslate ktranslate 2340 Dec 16 22:56 entity-sensor-mib.yml
-rw-rw-r-- 1 ktranslate ktranslate 1644 Dec 16 22:56 host-resources-mib.yml
-rw-rw-r-- 1 ktranslate ktranslate 12102 Dec 16 22:56 if-mib.yml
-rw-rw-r-- 1 ktranslate ktranslate 12012 Dec 16 22:56 if32-mib.yml
-rw-rw-r-- 1 ktranslate ktranslate 4652 Dec 16 22:56 ip-mib.yml
-rw-rw-r-- 1 ktranslate ktranslate 1161 Dec 16 22:56 lldp-mib.yml
-rw-rw-r-- 1 ktranslate ktranslate 1005 Dec 16 22:56 net-snmp.yml
-rw-rw-r-- 1 ktranslate ktranslate 1682 Dec 16 22:56 ospf-mib.yml
-rw-rw-r-- 1 ktranslate ktranslate 496 Dec 16 22:56 system-mib.yml
-rw-rw-r-- 1 ktranslate ktranslate 867 Dec 16 22:56 tcp-mib.yml
-rw-rw-r-- 1 ktranslate ktranslate 9255 Dec 16 22:56 ucd-mib.yml
-rw-rw-r-- 1 ktranslate ktranslate 412 Dec 16 22:56 udp-mib.yml
-rw-rw-r-- 1 ktranslate ktranslate 7943 Dec 16 22:56 ups-mib.yml
SNMPの経験があるエンジニアの方だと、xxx-mib.ymlというファイル名を見て、どのようなSNMPのデータ項目を設定しているのか推測できるかもしれないです。(標準MIBにはこのような項目が存在しています。)
例えば、if-mib.ymlやif32-mib.ymlではインターフェース毎の詳細なデータを取得するためのプロファイルが定義されていたり、ip-mib.ymlだとIPアドレスの粒度でのデータのインプット/アプトプット数やIPアドレス自身の情報を収集するためのプロファイルが設定されています。
cisco用のディレクトリは以下のプロファイルが配置されていました。
/etc/ktranslate/profiles/profiles/kentik_snmp/cisco$ ll
total 352
drwxrwxr-x 2 ktranslate ktranslate 4096 Dec 16 22:56 ./
drwxrwxr-x 89 ktranslate ktranslate 4096 Dec 18 01:05 ../
-rw-rw-r-- 1 ktranslate ktranslate 4333 Dec 16 22:56 cisco-access-point.yml
-rw-rw-r-- 1 ktranslate ktranslate 38986 Dec 16 22:56 cisco-all-devices.yml
-rw-rw-r-- 1 ktranslate ktranslate 25724 Dec 16 22:56 cisco-apic-server.yml
-rw-rw-r-- 1 ktranslate ktranslate 12999 Dec 16 22:56 cisco-asa.yml
-rw-rw-r-- 1 ktranslate ktranslate 4808 Dec 16 22:56 cisco-asr.yml
-rw-rw-r-- 1 ktranslate ktranslate 53532 Dec 16 22:56 cisco-call-manager.yml
-rw-rw-r-- 1 ktranslate ktranslate 20365 Dec 16 22:56 cisco-catalyst.yml
-rw-rw-r-- 1 ktranslate ktranslate 5734 Dec 16 22:56 cisco-csr.yml
-rw-rw-r-- 1 ktranslate ktranslate 10305 Dec 16 22:56 cisco-firepower.yml
-rw-rw-r-- 1 ktranslate ktranslate 15402 Dec 16 22:56 cisco-ironport-email.yml
-rw-rw-r-- 1 ktranslate ktranslate 1002 Dec 16 22:56 cisco-ise.yml
-rw-rw-r-- 1 ktranslate ktranslate 4777 Dec 16 22:56 cisco-load-balancer.yml
-rw-rw-r-- 1 ktranslate ktranslate 6444 Dec 16 22:56 cisco-nexus.yml
-rw-rw-r-- 1 ktranslate ktranslate 699 Dec 16 22:56 cisco-sb.yml
-rw-rw-r-- 1 ktranslate ktranslate 57881 Dec 16 22:56 cisco-ucs.yml
-rw-rw-r-- 1 ktranslate ktranslate 5054 Dec 16 22:56 cisco-voice.yml
-rw-rw-r-- 1 ktranslate ktranslate 2529 Dec 16 22:56 cisco-wan-optimizer.yml
-rw-rw-r-- 1 ktranslate ktranslate 22509 Dec 16 22:56 cisco-wlc.yml
-rw-rw-r-- 1 ktranslate ktranslate 8284 Dec 16 22:56 traps.yml
プロファイルの具体的な内容
詳細についてはこちらのレポジトリをご確認下さい。以下に大事なポイントを挙げています。
_generalディレクトリ配下の確認
- プロファイル(yml)ファイル内で、SNMPのOIDとNew Relic上でデータを格納する際のカラム名(変数名や属性名とも言ったりします)のマッピングを行います。
︙
︙
︙
metrics:
- MIB: IF-MIB
table:
OID: 1.3.6.1.2.1.2.2
name: ifTable
symbols:
# Faster polling to support anomaly detection
# The total number of octets received on the interface, including framing characters. This object is a 64-bit version of ifInOctets.
- name: ifHCInOctets
OID: 1.3.6.1.2.1.31.1.1.1.6
poll_time_sec: 60
# Faster polling to support anomaly detection
# The total number of octets transmitted out of the interface, including framing characters. This object is a 64-bit version of ifOutOctets.
- name: ifHCOutOctets
OID: 1.3.6.1.2.1.31.1.1.1.10
poll_time_sec: 60
︙
︙
︙
参照プロファイルはこちらです。
上記のサンプルから、OIDが1.3.6.1.2.1.31.1.1.1.6のデータをGET/WALKした際に、取得したデータはifHCInOctetsというカラム名で保存されることを意味しています。
補足となりますが、データ取得後にNew Relic上でデータを参照する場合は、Query Builderなどで、以下のNRQLを実行してみてください。
SELECT sum(`kentik.snmp.ifHCInOctets`) FROM Metric FACET if_interface_name SINCE 3 DAYS AGO TIMESERIES
この様に簡単にグラフ化を行うことができました。
大事なポイント
_generalディレクトリの配下のプロファイルは、標準的なSNMPのデータ(標準的なMIBファイル)を対象にした設定ファイルの内容となっています。そのため、こちらを直接編集することはないかと思います。あくまでも、_generalディレクトリ配下に『データのマッピングが定義されている』という点と、『どのような変数名として取り扱っている』かの情報が格納されていると押さえてもらえれば問題ありません。
ベンダー(例: cisco)ディレクトリ配下の確認
ciscoディレクトリを例に見てみましょう。ciscoディレクトリの構成は非常に汎用性が高く、よりサンプルです。cisco-all-devices.ymlファイルにて様々なCISCO機器の共通部分が取りまとめられ知て、cisco-catalyst.ymlファイルにてCatalystモデル固有の設定が行われています。
- ベンダー用のディレクトリでは、共通機能用のプロファイルを作成し、そのプロファイルを引き継ぐ形でモデル固有のプロファイルを作成することができます。
︙
︙
︙
---
extends:
- bgp4-mib.yml
- if-mib.yml
- ospf-mib.yml
- system-mib.yml
metrics:
# A table of overall CPU statistics.
# Polled at 60s to support anomaly detection.
- MIB: CISCO-PROCESS-MIB
table:
name: cpmCPUTotalTable
OID: 1.3.6.1.4.1.9.9.109.1.1.1
symbols:
# The overall CPU busy percentage in the last 1 minute period.
- name: cpmCPUTotal1minRev
OID: 1.3.6.1.4.1.9.9.109.1.1.1.1.7
poll_time_sec: 60
tag: CPU
allow_duplicate: true
# A table of memory pool monitoring entries.
# Polled at 60s to support anomaly detection.
- MIB: CISCO-MEMORY-POOL-MIB
table:
name: ciscoMemoryPoolTable
︙
︙
︙
参照プロファイルはこちらです。
cisco-all-devices.ymlファイルには重要なポイントが2つあります。
- extendsというキーワードを用いて、標準MIBの設定(_genericディレクトリ配下のプロファイル)を拡張しています。
- metricsというキーワードを用いてCISCO Catalystモデルの共通した固有のPrivate MIBの取り込みを追加で設定しています。(ただし、必須ではありません。)
︙
︙
︙
---
extends:
- cisco-all-devices.yml
provider: kentik-switch
sysobjectid:
- 1.3.6.1.4.1.9.1.111 # Catalyst 3500
- 1.3.6.1.4.1.9.1.170 # Catalyst 2908xl
- 1.3.6.1.4.1.9.1.171 # Catalyst 2916mxl
- 1.3.6.1.4.1.9.1.175 # Catalyst 1912C
︙
︙
︙
- 1.3.6.1.4.1.9.6.1.83.10.1 # SG300-10 Managed Switch
- 1.3.6.1.4.1.9.6.1.83.52.2 # SG300-52P Managed Switch
metrics:
- MIB: CISCO-IF-EXTENSION-MIB
is_interface: true
table:
OID: 1.3.6.1.4.1.9.9.276.1.1.1
name: cieIfPacketStatsTable
symbols:
- OID: 1.3.6.1.4.1.9.9.276.1.1.1.1.1
name: cieIfLastInTime
format: gauge
︙
︙
︙
参照プロファイルはこちらです。
cisco-catalyst.ymlファイルにも非常に重要な点があります.
-
providerというキーワードを用いて、取得したデータをNPMのどのUIに表示させるかをマッピングしています。
- providerがどの様な値を設定できるかについては、こちらが参考になります。ネットワークスイッチとして取り扱いたい場合はkentik-switchと、ルータとする場合はkentik-routerとします。
例えば、スイッチなのにkentik-routerとしてしまうと、ルータの一覧に機器が表示されてしまいます。また、タイポや定義されていない値を使ってしまうとデータは取れていてもUI上に表示されません。
-
sysobjectidというキーワードを用いて、CISCO Catalystのどのモデル(どのSysOIDの値を返す機器を、このプロファイルの対象とするかをマッピングしている)を対象とするかを定義しています。
- 例えば、新しい機器はCatalystの筈なのに適切に認識されないという事象が発生した場合は、1.3.6.1.2.1.1.2(sysObjectID)の値を取得し、sysobjectidのセクションで記載している一覧に、取得した値が存在しているかを確認して下さい。
sysObjectIDの値取得コマンド例 (v2cを用いた場合)snmpget -v2c -c <GETコミュニティ名> <対象機器IPアドレス> .1.3.6.1.2.1.1.2.0
- cisco-all-devices.ymlファイルと同様にextendsキーワードを用いてcisco-all-devices.ymlファイルの設定をcisco-catalyct.ymlファイル内で拡張しており、かつ、sysobjectidのセクションで一覧化しているCatalyst機器の固有のPrivate MIB情報の定義についてもmeticsキーワードを用いて追加しています。
カスタムプロファイルを作成するための虎の巻
さてさて、NPM内部のファイル構成はわかりましたが、簡単にカスタムプロファイルを作成するにはどうすればいいでしょうか？以下は、簡単なステップです。
-
kentic_snmpディレクトリに移動し、任意名(例えば、ベンダー名)でディレクトリを作成する。
ステップ1. コマンド例cd /etc/ktranslate/profiles/profiles/kentik_snmp sudo mkdir xxxxx sudo chown ktranslate:ktranslate xxxxx sudo chmod 775 xxxxxデフォルトの構成の様にxxxxxをベンダ名にしてもらうと管理が楽になりますが、必須ではありません。上記のxxxxxの文字列部分は、適宜環境や目的に合わせて決定して下さい。また、後続のコマンドやファイル名についても同じ文字列で置き換えて実施して下さい。
-
作成したディレクトリに移動し、共通用のプロファイルと機器モデル毎のプロファイルを作成する。
ステップ2. コマンド例cd xxxxx sudo touch xxxxx-all-devices.yml sudo touch xxxxx-switch-devices.yml sudo touch xxxxx-router-devices.yml sudo chown ktranslate:ktranslate *.yml sudo chmod 664 *.ymlテンプレート: xxxxx-all-devices.ymlextends: - system-mib.yml - if-mib.yml - if32-mib.yml - ip-mib.yml - tcp-mib.yml - udp-mib.yml - ospf-mib.ymlテンプレート: xxxxx-switch-devices.ymlextends: - xxxxx-all-devices.yml provider: kentik-switch sysobjectid: - 1.3.6.1.4... - 1.3.6.1.4... - (ここにスイッチ機器から取得できたsysObjectIDの一覧を記載していく)テンプレート: xxxxx-router-devices.ymlextends: - xxxxx-all-devices.yml provider: kentik-router sysobjectid: - 1.3.6.1.4... - 1.3.6.1.4... - (ここにルータ機器から取得できたsysObjectIDの一覧を記載していく)作成したそれぞれのファイルに、上記のテンプレート内容を追記し、適切なsysObjectIDの値を1つづつ記載してください。
-
NPMのサービスを再起動し、改めてディスカバリーのプロセスを実施します。
- 実施後、しばら時間をおいた後にUIやQuery Builderにてデータの取得結果をご確認下さい。
NPM再起動コマンド (再掲)sudo systemctl restart ktranslate
最後に
New Relicが提供するNPMはとてもパワフルなソリューションです。システムを適切かつ効率的に活用するためにはサーバ、アプリケーション、ネットワークも含めたobservabilityは不可欠な状況です。是非、New Relicを用いて様々な情報を可視化し、一元的に取り扱うための環境を実現して下さい。
New Relic株式会社のQiita Organizationでは、
新機能を含む活用方法を公開していますので、ぜひフォローをお願いします。