New Relicで実現するネットワークオブザーバビリティの始め方

みなさんこんにちは。マネージドサービス部MS課の塩野（正）です。

ネットワーク監視ツールって、正直どれも似たようなものだと思っていませんか？メトリクスを集めて、グラフにして、しきい値を超えたらアラートを出す。確かにそれも大事なんですが、New Relicを使ったネットワーク監視は、もう少し違った視点を持っています。

この記事では、New Relicでネットワーク監視を始める前に理解しておきたい「オブザーバビリティ」という考え方と、実際にどんなデータを扱うのかを解説します。設定手順の前に、まずは全体像を掴んでおきましょう。

目次
「監視」と「オブザーバビリティ」って何が違うの？
New Relicで扱うデータの種類
データを組み合わせることの重要性
- SNMPだけだと何が困る？
- SNMPとSyslogを組み合わせると見えてくるもの
New Relicのアーキテクチャを理解しよう
- KTranslateエージェントの役割
- データはどこに保存される？
設定を始める前に押さえておきたいポイント
まとめ
宣伝
関連記事

「監視」と「オブザーバビリティ」って何が違うの？

よくある監視の悩み

ネットワーク監視をしていて、こんな経験はありませんか？

「CPU使用率が90%になってアラートが鳴った。でも、なぜ高いのかがわからない」「帯域使用率が急上昇したのは検知できた。でも、何が原因なのか調べるのに時間がかかる」「アラートは受け取ったけど、次に何を調べればいいのかわからない」

これらは、単に数値を監視しているだけでは解決できない問題です。メトリクスを集めることはできても、その背景にある「なぜ」が見えないんですよね。

オブザーバビリティという考え方

オブザーバビリティ（Observability）は、システムの内部状態を外部の出力から理解する能力のことです。ちょっと難しく聞こえますが、要するに「システムに質問して、答えを得られる状態」を作ることです。

従来の監視との違いはこんな感じです。

従来の監視は「事前に決めた項目をチェックする」アプローチです。CPU使用率が80%を超えたらアラート、みたいな感じですね。これだと、想定していない問題には対応できません。

一方、オブザーバビリティは「何が起きているのか問いかけて、答えを探す」アプローチです。「なぜこのメトリクスが上昇したのか？」「どのトラフィックが帯域を占有しているのか？」といった問いに、データを掘り下げて答えを見つけられます。

ネットワークでオブザーバビリティを実現すると何が変わる？

New Relicのネットワーク監視を使うと、こんなことができるようになります。

まず、問題の根本原因を素早く特定できます。ネットワークのパフォーマンス低下が、本当にネットワーク層の問題なのか、それともアプリケーションやインフラの問題なのかを判断できるんです。

次に、問題が大きくなる前に対応できます。メトリクスのトレンドから予兆を検知して、計画的に対応できるようになります。

そして、ビジネスへの影響を理解できます。ネットワークのパフォーマンス低下が、どのアプリケーションやユーザーに影響するかを把握できるので、優先順位をつけた対応が可能になります。

New Relicで扱うデータの種類

New Relicのネットワーク監視では、主に3種類のデータを扱います。それぞれに役割があって、これらを組み合わせることで初めて全体像が見えてきます。

SNMPデータを使って今の状態を数値で把握する

SNMP（Simple Network Management Protocol）は、ネットワーク機器の状態を定期的に取得するプロトコルです。New Relicでは、このSNMPを使ってデバイスのパフォーマンスメトリクスを収集します。

具体的には、こんな情報が取れます。

デバイスのパフォーマンスとして、CPU使用率やメモリ使用率があります。ルーターやスイッチがどれくらいリソースを使っているかがわかります。

インターフェースの情報として、各ポートの状態（up/down）、帯域使用率、エラー数などが取得できます。どのポートがどれくらいトラフィックを流しているか、エラーが出ていないかを確認できます。

応答時間（RTT: Round Trip Time）も測定できます。デバイスまでの通信にどれくらい時間がかかっているかがわかります。

SNMPの役割は「今、デバイスやインターフェースがどんな状態か」を定量的に把握することです。

SNMP Trapを使って重要なイベントをリアルタイムで知る

SNMP Trapは、デバイス側から送られてくるイベント通知です。通常のSNMPは定期的にこちらから問い合わせる（ポーリング）方式ですが、Trapはデバイス側からプッシュで送られてきます。

例えば、インターフェースがダウンした、電源が落ちた、温度が異常値になった、といった重要なイベントが発生したときに、デバイスが自発的に通知してくれるんです。

SNMP Trapの役割は「デバイスで発生した重要なイベントを即座に検知する」ことです。

Syslogメッセージからなぜそうなったのかを理解する

Syslogは、デバイスが出力するログメッセージです。設定変更、エラーメッセージ、ルーティングプロトコルのイベント、インターフェースの状態変化など、デバイスで起きたことが記録されています。

Syslogに記録される情報には、こんなものがあります。

設定変更のログでは、誰がいつ何を変更したかがわかります。エラーメッセージと警告では、デバイスが検知した問題の詳細がわかります。ルーティングプロトコルのイベントでは、OSPFやBGPの状態変化が記録されます。インターフェースの状態変化では、ポートがup/downした理由が記録されることもあります。

Syslogの役割は「なぜメトリクスが変化したか」の理由を理解することです。

データを組み合わせることの重要性

ここが一番大事なポイントなんですが、これらのデータソースを単独で使っても、真のオブザーバビリティは実現できません。複数のデータを組み合わせて初めて、問題の全体像が見えてきます。

SNMPだけだと何が困る？

SNMPだけでは、こんな状況に陥ります。

現象はわかるけど原因がわからない。CPU使用率が急上昇したことはわかるけど、何が原因で上昇したのかわからない。

変化のきっかけがわからない。インターフェースがダウンしたことは検知できるけど、それが計画的なメンテナンスなのか、予期しない障害なのかが判断できない。

つまり、「何が起きているか」はわかるけど、「なぜ起きているか」がわからないんです。

SNMPとSyslogを組み合わせると見えてくるもの

実際の例で見てみましょう。

ある日、ディストリビューションスイッチのあるインターフェースで、エラーカウンターが急増しました。SNMPのメトリクスでこれを検知できます。でも、これだけだと「エラーが増えている」という事実しかわかりません。

ここで同じ時刻のSyslogを確認すると、そのインターフェースで「Duplex mismatch detected」（デュプレックス不一致）というログが見つかりました。さらに調べると、接続先の機器が半二重、スイッチ側が全二重に設定されていたことがわかります。

これで全体像が見えてきました。デュプレックス設定の不一致によって衝突が発生し、CRCエラーやフレームエラーが増えていたわけです。この場合、接続先の機器の設定を全二重に変更すれば問題が解決します。

このように、複数のシグナルを関連付けて理解する能力が、オブザーバビリティの本質なんです。

New Relicのアーキテクチャを理解しよう

KTranslateエージェントの役割

New Relicのネットワーク監視では、KTranslateというエージェントを使ってデータを収集します。このエージェントは、ネットワークとNew Relicの間の橋渡し役です。

KTranslateエージェントは、こんな仕事をしています。

SNMPポーリングでは、定期的にデバイスからメトリクスを収集します。SNMP Trapリスニングでは、デバイスから送信されるTrapを受信します。Syslog受信では、デバイスから送信されるSyslogメッセージを受信します。そして、収集したデータをNew Relicプラットフォームに送信します。

データはどこに保存される？

収集されたデータは、New Relic内で異なる形式で保存されます。これを理解しておくと、後でクエリを書くときに役立ちます。

SNMPで収集したパフォーマンスメトリクスは、Metricデータとして保存されます。NRQLでクエリするときは FROM Metric を使います。

SNMP Trapの内容は、イベントデータとして保存されます。クエリするときは FROM KSnmpTrap を使います。

Syslogメッセージは、Logデータとして保存されます。クエリするときは FROM Log を使います。

この違いを理解しておくと、「あのデータはどこにあるんだっけ？」と迷わなくて済みます。

設定を始める前に押さえておきたいポイント

詳細な設定手順は公式ドキュメントに譲りますが、ここでは設定する際に特に重要なポイントを3つ紹介します。

エージェントは監視対象の近くに置く

KTranslateエージェントは、監視対象デバイスの近くに配置することが重要です。「近く」というのは、物理的な距離だけでなく、ネットワーク的な距離のことです。

なぜかというと、SNMPやICMPは管理トラフィックなので、QoS設定によっては優先度が低く設定されている場合があります。また、ネットワークホップが多いと、各ホップでの処理遅延やキューイング遅延が積み重なり、タイムアウトで失敗することがあります。

理想的には、監視対象デバイスと同じデータセンター、同じネットワークセグメント内に配置します。ネットワークホップ数を最小化することで、ポーリング時のタイムアウトを防止でき、より正確な応答時間（RTT）を測定でき、安定したデータ収集が可能になります。

デバイス名は統一する

SNMPとSyslogの両方を収集する場合、設定ファイルで指定する device_name の値を統一する必要があります。

なぜこれが重要かというと、New Relic UIでは、同じデバイス名のデータを同一のエンティティとして扱うからです。デバイス名が異なると、SNMPデータとSyslogデータが別々のエンティティとして表示されてしまい、相関分析ができなくなります。

例えば、SNMPの設定では core-router-01 という名前にして、Syslogの設定では core-router-1 という名前にしてしまうと、New Relicは別のデバイスだと認識してしまいます。

すべての設定ファイルで、同じデバイスには同じ device_name を使うようにしましょう。

必要なMIBを有効化する

MIB（Management Information Base）は、SNMPで取得できる情報の定義です。監視したいメトリクスに対応するMIBを有効化しないと、そのメトリクスは収集されません。

設定ファイルの global.mibs_enabled セクションで、必要なMIBを指定します。

global:
  mibs_enabled:
    - IF-MIB                    # インターフェース情報（標準MIB）
    - HOST-RESOURCES-MIB        # CPU/メモリ情報（標準MIB）

まずは、IF-MIBとHOST-RESOURCES-MIBという標準MIBを有効化しておけば、基本的なインターフェース情報とデバイスパフォーマンスを監視できます。

ベンダー固有の詳細な情報が必要な場合は、追加でベンダー固有のMIBを有効化します。例えば、Ciscoデバイスなら CISCO-MEMORY-POOL-MIB や CISCO-PROCESS-MIB などです。

New Relicの公式SNMPプロファイルには、デバイスタイプやベンダーごとに推奨されるMIBのリストが用意されているので、それを参照すると良いでしょう。

まとめ

New Relicのネットワーク監視は、単なるメトリクス収集ツールではなく、オブザーバビリティを実現するためのプラットフォームです。

重要なポイントをおさらいすると、オブザーバビリティとは「システムに問いかけて答えを得られる状態」を作ることです。SNMPで「何が起きているか」を把握し、Syslogで「なぜ起きているか」を理解します。複数のデータソースを組み合わせることで、初めて全体像が見えてきます。

次回の記事では、実際に収集したメトリクスをどう読み解くか、どんな設定をすればいいかを具体的に解説します。インターフェースの帯域使用率やデバイスのCPU使用率など、実践的な監視のポイントを見ていきましょう。

こちらの記事がどなたかのお役に立てれば幸いです。

宣伝

弊社では、お客様環境のオブザーバビリティを加速するためのNew Relicアカウント開設を含めた伴走型のNew Relic導入支援サービスをご提供しております。もしご興味をお持ちの方は、こちらのお問合せフォームよりお問合せ頂けましたら幸いでございます。

https://blog.serverworks.co.jp/newrelic-network-observability-metrics-setupblog.serverworks.co.jp https://blog.serverworks.co.jp/newrelic-network-observability-operationsblog.serverworks.co.jp

目次