みなさんこんにちは。マネージドサービス部MSS課の塩野（正）です。
ネットワーク監視のツールは色々ありますが、今回はNew RelicのNetwork Performance Monitoring（NPM）を使って、ICMP監視がどんな感じでできるのかというのを試してみた実践編の記事になります。
目次
概要
先に、New RelicのNetwork Performance Monitoring（NPM）の概要について、簡単にご紹介したいと思います。
New Relic NPMは、ネットワークの状態を包括的に監視し、システム全体のパフォーマンスを把握するためのツールです。 その特徴は、下記の通りです。
- SNMP、Syslog、ネットワークフローなど、さまざまな種類のネットワークデータを収集できます
- オンプレミスのネットワーク機器だけでなく、AWSやGCPのVPCネットワークにも対応しています
- 最短30秒間隔でメトリクスを収集し、ネットワーク関連のトラブルシューティングをやりやすくします
設定
基本的にコンテナオーケストレーションの対応が微妙なため、EC2などのLinux OSにインストールしたDocker環境で監視を行います。ただし、全く動かないかと言われるとそういう訳でもありませんので、下記の記事に沿って自己責任で試していただくことは可能かと思います。
OS環境の設定（Dockerインストール）
さて、まずはOS環境の設定からになりますが、OSはAmazon Linux 2023で起動し、Dockerをインストールしましょう。
sudo dnf update -y sudo dnf install docker -y sudo systemctl start docker sudo systemctl enable docker
これでDocker環境のインストールが完了しました。次にネットワーク監視用のKtranslateコンテナを起動しましょう。
Ktranslateコンテナの起動
設定ファイルの作成
New RelicのNPMの実体であるKtranslateコンテナの設定は snmp-base.yaml でおこないます。 New Relic UIにガイドインストールの手順などもありますが、PING監視を行う場合の設定ファイルをガイドインストールで作成することは現時点ではできません。 そのためファイル自体は手動での作成となります。
ベース部分は下記の通り。それぞれIPアドレスと機器名称を入力してyamlファイルを作成します。設定ファイル作成時の注意点として、PINGデバイスをdiscoveryしたり、外部ファイルに書き出したりすることはおそらく仕様上できないと推測しています。Ktranslateの仕様上、PINGモジュール自体はSNMP監視のサブセットとして構成されているようです。また、PING監視を行う場合は ping_only フラグを有効にする必要があり、ping_only フラグを有効にすると対象デバイスのSNMP関連の監視は無効化されます。あくまでも推測になりますが、ping_onlyフラグを有効にする影響で、SNMP監視のためのデバイスのdiscovery機能や外部ファイルへの書き出し機能自体も無効化されているのではないかと考えています。
余談な話はここまでになりますが、PING監視の場合は、下記記載内容を監視対象デバイスの分だけ追加・編集していく流れとなります。
ping_only__<IPアドレス>: device_name: <機器の名前> device_ip: <IPアドレス> provider: kentik-ping ping_only: true ping_interval_sec: 30
snmp-base.yaml 設定ファイルの完成形はこちら。
下記設定にSNMP PollingなどのデバイスやSNMP Trapなどの設定を追加することもできますが、監視対象デバイスが多ければ多いほど devicesセクションの内容が膨らんでしまう事や、標準でのdiscovery機能を有効化した場合に自動的に設定を書き換えられてしまう恐れがあることなどから、設定の混在はしない方が運用上都合がいいように思います。
devices: ping_only__<IPアドレス>: device_name: <機器の名前> device_ip: <IPアドレス> provider: kentik-ping ping_only: true ping_interval_sec: 30 global: poll_time_sec: 30 mib_profile_dir: /etc/ktranslate/profiles response_time: true mibs_enabled: - IF-MIB timeout_ms: 3000 retries: 0
コンテナの起動
snmp-base.yaml ファイルを保存したディレクトリから下記のコマンドを実行します。
docker run -d --name ktranslate-public --restart unless-stopped --pull=always \ -v `pwd`/snmp-base.yaml:/snmp-base.yaml \ -e NEW_RELIC_API_KEY=<New Relic lisencekey> \ kentik/ktranslate:v2 \ -snmp /snmp-base.yaml \ -nr_account_id=<New RelicアカウントID> \ -metrics=jchf \ -tee_logs=true \ -service_name=<コンテナサービス名> \ -snmp_discovery_on_start=true \ -snmp_discovery_min=180 \ nr1.snmp
New Relicの公式は基本的にサポートしてくれませんが、下記のような docker-compose.yaml ファイルを作成しておくと運用が少しだけ楽になりそうです。
services: ktrans_ping: image: kentik/ktranslate:v2 restart: unless-stopped pull_policy: always container_name: ktrans-ping volumes: - ./snmp-base.yaml:/snmp-base.yaml environment: - NEW_RELIC_API_KEY=<New Relic lisencekey> - NR_ACCOUNT_ID=<New RelicアカウントID> command: - -snmp=/snmp-base.yaml - -metrics=jchf - -tee_logs=true - -snmp_discovery_on_start=true - nr1.snmp network_mode: host
コンテナが正常に起動できると、下記のような形でコンテナの情報が表示されます。
$ docker ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES e3d17441990f kentik/ktranslate:v2 "ktranslate -listen …" 48 minutes ago Up 48 minutes ktranslate-test
ダッシュボード
正直なところ、PING監視に関しては標準で提供されているダッシュボードで使い勝手のよさそうなものは見当たりませんでしたので、下記のようなダッシュボードを作成してみました。New RelicでPING監視をやってみてここがいいなと思った点は、コンフィグに記載できるデバイス情報に日本語が使用できること。他社のネットワーク管理ツールでも日本語が使用できるものもあるかと思いますが、コンフィグに記載したデバイス名がそのままNew Relicの管理コンソール上に表示されるため、後から管理情報とデバイス情報を紐づける手間が省けるのではないかと推測しています。
まとめ
New RelicのNetwork Performance Monitoring（NPM）をひと通り設定して動作確認してみましたが、ドキュメントが読みにくかったりこうしたブログを書いている人が少なかったりで、最終的な正解にたどり着くまで少し時間がかかった印象でした。また、今回試したICMP PING監視は、ネットワーク監視の中でも単なる死活監視の扱いになるためそもそも確認できる項目も少ないという点はあるものの、ダッシュボードの中でレイテンシーなどの情報が確認できるのであれば、単なる死活監視だけでなくグレー障害などの検知にも役に立ちそうに思いました。
こちらの記事がどなたかのお役に立てれば幸いでございます。
宣伝
弊社では、お客様環境のオブザーバビリティを加速するためのNew Relicアカウント開設を含めた伴走型のNew Relic導入支援サービスをご提供しております。 もしご興味をお持ちの方は、こちらのお問合せフォームよりお問合せ頂けましたら幸いでございます。
