Top takeaways
既にご存知の方も多いかと思いますが、New Relicがネットワーク層の可観測性を実現するNetwork Performance Monitoring(以下、NPM)機能をリリースしました。こんな動画やこんな動画が見れるので、とてもワクワクしますね。
例えば、New Relicが提供するInfrastructureエージェントを用いたサーバ内部からの監視だけでなく、ネットワークの重要拠点から当該サーバやネットワーク機器へのポーリングや性能情報を取得することで、ご提供されているサービスやシステムの健全性をより多くの観点で確認することができ、隠れた課題を炙り出すことができるようになりますね。
このブログがポストされるタイミングでは、NPMは大きく2つの機能が提供されいています。
- Simple Network Management Protocolを用いたポーリング機能
- Flow情報を受け取るトラフィック解析機能
今回は、インフラ監視で馴染みのあるSimple Network Management Protocol(以下、SNMP)機能を簡単に試すためのローカル環境を作ってみたいと思います。
- 公式な導入手順はこちらよりご参照ください。
このブログで記載した作業を通して、以下の点をご理解いただけます。
- SNMPの簡単な導通確認手順
- NPMの管理サーバの導入方法と監視対象検知の手順
- New Relic One上での収集したSNMPデータの確認方法
上記の技術的な理解を通して、ネットワーク機器やサーバを含めたネットワーク層に対して可観測性をどのように拡張していけばよいかと考察する一助となれれば幸いです。
作業の流れ
作業の流れは以下の通りとなります。
- [前提] New Relicのアカウントを取得する
(取得先URLはこちらになります。) - [前提] 動作検証を行う環境にdockerを導入する
- 監視対象サーバのセットアップ (10分程度)
- NPM管理サーバの導入 (10分程度)
構築する環境のイメージは以下の通りです。
補足: 以下の作業は、Linux, Mac環境下で動作確認を行っています。Windows環境の方は適宜、読み替える、あるいは、Linux環境をご用意の上で確認されることをお勧めします。
以下より、作業を進めて行きます。
監視対象サーバのセットアップ
本来であれば、ネットワーク機器を対象とすべきですが、ローカル環境のみで確認をできることを優先するため、サーバを監視対象として環境を構築していきます。
dockerネットワークの作成
【注意】実監視環境では、こちらの作業は不要です。ローカルでの検証のために実施する作業となります。
監視対象サーバと管理サーバを同一dockerネットワークに配置するために、事前にdockerネットワークを作成します。
# docker network create <任意のdockerネットワーク名>
docker network create nrnpm_dnetwork
監視対象サーバのdockerイメージ取得とコンテナ化
【注意】実監視環境では、こちらの作業は不要です。ローカルでの検証のために実施する作業となります。
今回は、ubuntuイメージを利用していますが、慣れているイメージをご利用ください。
# docker run -it -d --network <作成したdockerネットワーク名> --name <管理し易いコンテナ名> ubuntu:latest
docker run -it -d --network nrnpm_dnetwork --name managed-node ubuntu:latest
後でSNMPでクエリをかけるために、dockerネットワーク内のIPアドレスをdocker inspectコマンドで確認しておきましょう。
例えば、以下の様にすることで、割り振られているIPアドレスを確認することができます。
# docker inspect <コンテナ名>
確認コマンド例 (Linux, Mac環境)
docker inspect managed-node | grep IPAddress
(出力例)
"SecondaryIPAddresses": null,
"IPAddress": "",
"IPAddress": "172.18.0.2",
監視対象サーバインスタンス内での作業
docker execコマンドでインスタンス内にアクセスし、以下の作業を実施します。
docker exec -it managed-node /bin/bash
# apt-get update
# apt-get install snmpd snmp vim
# vi /etc/snmp/snmpd.conf
[変更前]
agentaddress 127.0.0.1,[::1]
[変更後]
agentaddress 127.0.01,<先ほど確認したIPv4アドレスを記載する>
# /etc/init.d/snmpd start
# snmpwalk -v2c -c public localhost または、 # snmpwalk -v2c -c public <指定したIPv4アドレス>を実行し、レスポンスが返ってくれば設定が正しく行えています。
出力例
SNMPの参照できる領域を拡張します。(注意: 実際の運用の際は、適切な設定を行ってください。)
# vi /etc/snmp/snmpd.conf
[変更前]
# system + hrSystem groups only
view systemonly included .1.3.6.1.2.1.1
view systemonly included .1.3.6.1.2.1.25.1
[変更後]
# system + hrSystem groups only
view systemonly included .1.3.6.1
変更後、snmpdを再起動し、snmpwalkの返り値が増えていることを確認します。
補足: 動作を確認している際に、kill -9にてプロセスを止めなければならないケースがありました。再起動してもsnmpwalkの返す値に変更がない場合には、kill -9を実行して、snmpdを再起動して下さい。
NPM管理サーバの導入
New Relic Oneポータルにアクセスし、ログインします。
ログイン後、"+Add more data"ボタンより"Network performance monitoring"セクションの"SNMP"ボタンをクリックして下さい。
設定画面が表示されましたら、account情報が適切なものをプルダウンメニューから選択します。
次に、監視対象サーバのSNMP設定をUI上で指定します。
SNMP versionの設定を行う際は、一般的に利用されているv2cを選ぶのが良いかと思います。
補足: 実運用の際は、Community stringsは、"public"以外のものをご活用下さい。
設定後、"Validate and continue"ボタンを押し、設定画面下部のコマンドを生成させて下さい。
補足: このブログでは、ローカル環境で触ってみることを目的としていますので、"Launch device discovery"で生成されたコマンドを、そのまま使っておりません。実際の運用環境では、生成されたコマンドの手順に従って導入を進めて下さい。
一旦、ローカル環境に戻り、任意のパスで空の"snmp-base.yaml"ファイルを作成します。
(注意: NPMの設定画面は閉じずに、そのまま開いた状態にしておいて下さい。後の作業でも続けて利用します。)
作成後、"Launch device discovery"で生成されたコマンド内の"YAML"で挟まれた箇所を、"snmp-base.yaml"ファイル内に記載して下さい。
cat > snmp-base.yaml <<- YAML
<この複数行の中身を、snmp-base.yamlに転記してください。>
YAML
docker run...
(v2cのサンプルsnmp-base.yaml)
"snmp-base.yaml"ファイルの内容を記載後、生成されたコマンドのdocker部分以降を実行します。
実行の際に、dockerネットワーク部分の設定を、先ほど作成したdockerネットワークを利用する様に変更して下さい。
docker run -ti --name ktranslate-discovery --rm --network nrnpm_dnetwork \
--user `id -u`:`id -g` \
-v `pwd`/snmp-base.yaml:/snmp-base.yaml \
kentik/ktranslate:v2 \
-snmp /snmp-base.yaml \
-log_level info \
-snmp_discovery=true
上記の実行により、NPMの監視対象ノードの検出プロセスが走り、その結果を先ほど作成したsnmp-base.yamlに反映されます。
上記の作業が完了しましたら、再度、NPMの設定画面に戻り、"Poll target devices"にて生成されたコマンドを実行します。コマンドを実行する際に、ローカル検証だとわかるコンテナ名の設定を行うことと、先ほど生成したdockerネットワークを利用する様にして下さい。
docker run -d --name ktranslate-snmp-localeval --restart unless-stopped --network nrnpm_dnetwork \
-v `pwd`/snmp-base.yaml:/snmp-base.yaml \
-e NEW_RELIC_API_KEY=<表示されるKeyの値を、そのまま利用する> \
kentik/ktranslate:v2 \
-snmp /snmp-base.yaml \
-nr_account_id=<割り振られたアカウントID> \
-log_level=info \
-metrics=jchf \
-tee_logs=true \
-service_name=snmp \
nr1.snmp
上記の作業を実施すると、ローカル環境でNPMのコンテナが起動し、監視対象サーバにSNMPポーリングを実施し、その結果をNew Relic Oneプラットフォームに送り始めます。
ここまで来ましたら、NPMの設定画面は閉じて下さい。
導入作業、お疲れ様でした!!
それでは、収集されたSNMPデータがどの様にNew Relic Oneポータル上で参照できるかを見てみましょう。
Data explorerのMetricsとして
収集されたSNMPデータは、MetricsとしてData Explorer上で参照することができます。Metrics名は、"kentik."で始まる名前になっています。
補足:
- SNMPを介して、さまざまなデータを取得すると、kentik.snmp.<OID名>という形式で、データが集められます。例えば、kentik.snmp.ifInErrorsや、kentik.snmp.ifHCInOctetsとなります。
- NPMは、監視対象がサーバであると判定しているため、IF-MIBなどのデータを取得しません。もしサーバの詳細がどうしても必要という場合には、Infrastructure agentのご利用をご検討下さい。
Query builderにて
SELECT * FROM Metric WHERE metricName like 'kentik.%'
とNRQLを入力頂くことで、どのようなデータを収集しているかを確認することができます。より詳細については、こちらのページをご参照ください。
これらのデータから、SNMPデータが取得できなかった際に、アラートを発砲するといった設定ができるようになります。
例えば、
SELECT latest(kentik.ktranslate.chf.kkc.snmp_fail) FROM Metric FACET device_name
というNRQLを用いることで、1ではない値になった場合、SNMPクエリに応答できなくなっているサーバを特定することができます。
LogsによるSNMPポーリング状況確認
Data explorerにてSNMPで得られたデータ内容を参照することができますが、そのSNMPポーリングを行われているかは、Logsにて確認することが可能です。message内にKtranslate/snmpという文字列を含んでいますので、機器の検出後に定期的にポーリングを行えているかをLogsを介して確認することができます。
Logsの例: (こちらはAWS環境下での出力例となります。)
次のステップ
まとめ
本ブログポストをお読み下さりありがとうございます。改めて、簡単にポイントを以下にまとめます。
- Network Performance Monitoringを用いて、SNMPによるデータ収集ができるようになった
- サーバに対してSNMPポーリングを行うことで、外部から死活監視を行うことができるようになった
- Network Performance Monitoringはコンテナで提供しているため、導入を即座に行うことができる
本ブログポストを通して、New Relicが提供しているNPMを、運用されている環境に使ってみようと思っていただければ幸いです。
NPMに関するトレーニングや、New Relicに関するトレーニングも定期的に提供しておりますので、ご興味がありましたらこちらもご確認ください。
本ブログに掲載されている見解は著者に所属するものであり、必ずしも New Relic 株式会社の公式見解であるわけではありません。また、本ブログには、外部サイトにアクセスするリンクが含まれる場合があります。それらリンク先の内容について、New Relic がいかなる保証も提供することはありません。
