ネットワーク...と聞くと、『専門家に任せる領域だよね。』と思う方は多いかと思いますが、取得できるデータをわかりやすい形でまとめておくと、いろいろな気づきや、普段と違う状況の発生を抑えることができますね。
いろいろなお客様とネットワークで苦しんだ経験を基に役に立ちそうなデータをダッシュボード化してみましたので、ご報告です。
New Relic株式会社のQiita Organizationでは、
新機能を含む活用方法を公開していますので、ぜひフォローをお願いします。
NPMというと、開発を経験したエンジニアの方だと、『Node.jsとかの話？』と思う人が多いかもしれませんが...別物です。個人的には、Node.js大好きです!!
はじめに
New Relicの1つの機能として、ネットワークデバイスで使われているSNMPを介してパフォーマンス情報を収集することが可能です。
その際に、NPMというエージェントをネットワーク内に配置し、そこから定期的にSNMPポーリングを実施して、機器の詳細情報(わかり易い項目としては、インターフェース単位でのIn/Outのデータ量とかです)を取得することが可能です。
具体的な内容については、以下のQiita記事がとても参考になるので紹介します。
一般的な話になるのですが、こういった計測するマネージメントサーバは、導入するまでに大きなハードルが存在しているのですが...導入して少し落ち着いた後に、本当にポーリングサイクルが粛々と適切に行われているかという不安を感じ始めることってありませんか？
(オンプレ環境に大型のアプリやシステムを導入していた古きエンジニアの発想だったりして...涙)
NPMは、SNMP Community名をしっかり抑えておけば、導入はワンラインのコマンドを実施すると完了してしまうくらい簡単でした。いい時代になったものだ...(遠い目)
そんな導入後にちゃんとポーリングが行われている状況を可視化するためのダッシュボードを作ってみたので、共有です。
頑張ってログとかをゴニョゴニョすれば良いのかもしれないけど、毎回やるのは手間暇だけがかかるので、そこは省エネするためにダッシュボードの作成が便利です!!
こんなダッシュボードを作ってみたよ
早速のご紹介
ダッシュボードの詳細に触れる前に、ダッシュボードを作成する際に知っておくと理解が捗るトピックをお伝えしますね。
ダッシュボード上の選択に合わせて変数の活用
テンプレート変数という機能を用いています。プルダウンメニュー上から任意の値を選択すると、その選択した内容が変数に格納され、他のチャート上に、その変数を反映した結果(例えば、WHERE句でフィルタをかけるなど)を反映することができます。
例えば、スイッチだけを参照した、特定のインターフェースだけを参照したいなど、UI上で目的に合わせて表示を変更させることができます。
以下のQiita記事も参考になるかと思います。
Metricのデータを用いてチャートを描画する
New Relicのダッシュボードを作成する際は、Eventを用いて描画することが多いのですが、NPMのSNMPデータはMetricとして格納されます。そこで、参照したいデータ(例えば、インターフェースのIn/Outデータ量)を取得するには少し特徴のあるNRQLが必要となります。
具体的にどんな内容でそれぞれのチャートを作ったのかのご紹介
テンプレート変数の作成
まずは、以下の様に3つの変数を作成しました。
テンプレート変数を設定する際に、その変数の変数名を設定します。その変数名を用いて、他のチャートに設定するNRQL内で選択した値として取り扱うことができる様になります。
手元に変数名を残しておくと、NRQLの編集が少〜〜〜〜し楽になります。
FROM Metric
SELECT uniques(entity.type)
WHERE kentik.snmp.ifHCInOctets IS NOT NULL
SINCE 30 minutes ago
FROM Metric
SELECT uniques(entity.name)
WHERE kentik.snmp.ifHCInOctets IS NOT NULL AND entity.type IN ( {{ deviceType }} )
SINCE 30 minutes ago
FROM Metric
SELECT uniques(if_interface_name)
WHERE kentik.snmp.ifHCInOctets IS NOT NULL
WHERE entity.name IN ( {{ deviceName }} )
SINCE 30 minutes ago
これらのテンプレート変数を設定することで、例えば、Device Typeで全てのタイプを指定した場合、例えば、以下のように多くのDevice Nameを選択することができますが...
Device TypeでROUTERのみを選択すると、Device Nameの選択肢が最初から減っていることがわかるかと思います。
同様に、Device Nameで特定の機器をしていして、Interface Namesで全てのインターフェースが選択されている状況から特定のインターフェースだけを選択すると、チャート上に表示されるグラフがとてもスッキリしているのがわかりますね。
インターフェースへのポーリングが適切に行われているかを把握する
特定のデバイスの特定のインターフェースに絞ってグラフを参照しています。これによって、SNMPポーリングが期待通りに行われているかを確認することができます。
例えば、NPM自体の負荷が高くなっていたり(ポーリング対象が多すぎるとか)、管理対象となっているネットワーク機器の負荷が上がりSNMP Get Responseを返せていない、途中の経路でパケットロスや遅延が発生してしまったなどに気づける取っ掛かりになるかと思います。その場合、チャート上では、データ間に空白ができたり、同一時間に複数のデータが表示される(countなので、実際には1と表示される部分が2となったりします)ことになります。
FROM Metric
SELECT count( kentik.snmp.ifHCInOctets )
FACET entity.name, if_interface_name
WHERE entity.name IN ( {{ deviceName }} ) AND if_interface_name IN ( {{ deviceIfNames }} )
TIMESERIES 1 minute
SINCE 3 hours ago
インターフェースのIn/Outのデータ量を可視化する
こちらについても、特定のデバイスの特定のインターフェースに絞ってグラフを参照しています。
このチャートを用いて、ネットワークトラフィックの急激な変化や、INあるいはOUTだけが大きなトラフィックを発生させているなどの異常に気づく取っ掛かりとなります。
想定されていないタイミングでのトラフィックの急増に気づいたら、セキュリティチームに相談するなどの運用ルールを検討しておくといいかもしれません。
急激なトラフィック量の変化は気づきやすいので、これらのチャートで気づくことは可能ですが、低量のトラフィックで少しづつ外部と通信するというパターンは、フローデータのdestination情報をみたり、適切なセキュリティソリューションと組み合わせて確認をしていく必要があります。
FROM Metric
SELECT average( kentik.snmp.ifHCInOctets )
FACET entity.name, if_interface_name
WHERE entity.name IN ({{ deviceName }}) AND if_interface_name IN ({{ deviceIfNames }})
TIMESERIES 1 minute
SINCE 3 hours ago
FROM Metric
SELECT average( kentik.snmp.ifHCOutOctets )
FACET entity.name, if_interface_name
WHERE entity.name IN ({{ deviceName }}) AND if_interface_name IN ({{ deviceIfNames }})
TIMESERIES 1 minute
SINCE 3 hours ago
インターフェースのIn/Outでの利用率を可視化する
こちらについても、特定のデバイスの特定のインターフェースに絞ってグラフを参照しています。
先ほどのチャートは量だったのに対して、こちらは利用率を可視化しています。
ネットワーク機器の適切なサイジングを行ったり、帯域を確保するためのヒントになりますね。
FROM Metric
SELECT average( kentik.snmp.IfInUtilization )
FACET entity.name, if_interface_name
WHERE entity.name IN ({{ deviceName }}) AND if_interface_name IN ({{ deviceIfNames }})
TIMESERIES 1 minute
SINCE 3 hours ago
FROM Metric
SELECT average( kentik.snmp.IfOutUtilization )
FACET entity.name, if_interface_name
WHERE entity.name IN ({{ deviceName }}) AND if_interface_name IN ({{ deviceIfNames }})
TIMESERIES 1 minute
SINCE 3 hours ago
利用率といった特定の範囲の値を取ることが決まっている項目をプロットする際は、Y-axisで最小値/最大値(今回だと、最小値 = 0, 最大値 = 100)を設定しましょう。
CPUの利用状況を可視化する
こちらは特定の機器に絞り込んだグラフを参照しています。機器を絞り込むこど絵、それに関連した複数あるCPUの情報を参照しています。
FROM Metric
SELECT average(kentik.snmp.CPU)
FACET entity.name, Index
WHERE kentik.snmp.CPU IS NOT NULL AND entity.name IN ({{ deviceName }})
TIMESERIES 1 minute
SINCE 3 hours ago
FROM Metric
SELECT average(kentik.snmp.CPU)
FACET entity.name, Index
WHERE kentik.snmp.CPU IS NOT NULL AND entity.name IN ({{ deviceName }})
TIMESERIES 1 minute
SINCE 3 hours ago
Chart typeをBillboardとした場合、Thresholdsから各タイルの値に合わせてステータスを定義することができ、そのステータスに合わせて表示させる色が変化します。
メモリの利用状況を可視化する
こちらは特定の機器に絞り込んだグラフを参照しています。機器を絞り込むこど絵、それに関連した複数あるメモリの情報を参照しています。
FROM Metric
SELECT average(kentik.snmp.MemoryUtilization)
FACET entity.name, Index
WHERE kentik.snmp.MemoryUtilization IS NOT NULL AND entity.name IN ({{ deviceName }})
TIMESERIES 1 minute
SINCE 3 hours ago
FROM Metric
SELECT average(kentik.snmp.MemoryUtilization)
FACET entity.name, Index
WHERE kentik.snmp.MemoryUtilization IS NOT NULL AND entity.name IN ({{ deviceName }})
TIMESERIES 1 minute
SINCE 3 hours ago
Chart typeをBillboardとした場合、Thresholdsから各タイルの値に合わせてステータスを定義することができ、そのステータスに合わせて表示させる色が変化します。
NPMのログやSyslogを直ぐに参照できるようにする
ここではNPM自体が生成しているログ(例えば、NPMの起動時のログや、ポーリング時に取得できなかったOIDなどを確認することができます)や、NPMが受け取ったSyslogなどを参照できるようにしています。
ダッシュボードを作成した環境ではCisco機器があり、そのSyslogを受け取っているためSyslogに紐づいている重要度情報を例として記載していますが、環境に合わせた有用な情報を記載することで、参照者の誤認を防いだり、コミュニケーションの効率化を図ることが可能です。
# syslog重要度の全体像
## Ciscoの重要度は0から7までの8段階で定義されています。数字が小さいほど緊急性が高く、大きいほど詳細な情報（デバッグなど）になります。
---
0: Emergency システムが使用不可（最も緊急）\
1: Alert 即時の対応が必要 \
2: Critical 致命的な状態 \
3: Error エラーメッセージ \
4: Warning 警告メッセージ \
5: Notifications 重大な通知（インターフェースのUP/DOWNなど）\
6: Informational 一般的な情報メッセージ \
7: Debugging デバッグメッセージ（詳細な解析用)
---
FROM Log
SELECT count(*)
FACET severity
WHERE collector.name = 'ktranslate' AND severity != 'Info'
SINCE 3 hours ago
LIMIT MAX
TIMESERIES
FROM Log
SELECT *
WHERE collector.name = 'ktranslate' AND severity != 'Info'
SINCE 3 hours ago
LIMIT MAX
生成されるログのうち、重要度がinfoのログは表示対象から除外しています。severityのカラムを用いることで、目的に合わせたログ情報だけに絞り込むことが可能です。
補足
ダッシュボードを作成した環境は、デモを目的とした環境だったので、よいグラフを作ることはできなかったのですが、以下のNRQLを駆使すると、NPMのSNMPポーリングがどのOIDで失敗したか...を可視化することができます。
FROM Log
SELECT count(*)
WHERE position( message, <ここに参照したい機器名を指定> ) > 0 AND message LIKE '%SNMP polling error%'
FACET aparse( message, '%walking OID * after%')
SINCE 3 hours ago
LIMIT max
TIMESERIES
このグラフに表示されるデータがなくなるように改善を行うことで、ネットワーク自体の負荷を適切に下げていく一つの指標として利用することができます。
さいごに
今回紹介したこと以外にも、Lookup Table機能を活用してポーリング対象機器の物理的な所在地情報(例えば、住所、データセンタ、ラック配置場所などなど。場合によっては、管理責任者なども)を紐づけてダッシュボード情報で活用するなんてことも可能です。例えば、特定のデータセンターだけの機器を抽出してチャート上に表示したり、影響を受けた機器名から即座に管理責任者を確認したりなど。
ちなみに、初学者向け...ではないのですが、ネットワーク監視の理解をより深める連載記事を弊社メンバーが執筆しています。
どういう観点でネットワーク監視を行なっていけばいいのかな？という疑問にヒントを与えてくれるのではないかと思うので、お時間がある時にご一読頂ければ幸いです。
無料のアカウントで試してみよう！
New Relic フリープランで始めるオブザーバビリティ！
