New Relicネットワーク監視の実践設定ガイドー SNMP・Syslog収集とメトリクス分析

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

前回の記事では、New Relicのネットワーク監視における「オブザーバビリティ」の考え方と、扱うデータの種類について解説しました。今回は、実際に収集したメトリクスをどう読み解くか、効果的な監視を実現するためのポイントを見ていきます。

数値を見るだけなら簡単ですが、その数値が何を意味しているのか、どう解釈すべきかを理解することが、真のオブザーバビリティにつながっていくと思います。

blog.serverworks.co.jp

インターフェース監視の実践

ネットワーク監視で最も重要なのが、インターフェース（ポート）の監視です。ここでは、転送量の測定、インターフェース状態、エラーメトリクスの3つの視点から見ていきましょう。

転送量 - ネットワークトラフィックの実態把握

New RelicのSNMP監視では、インターフェースの転送量（バイト数）を直接監視できます。利用率（パーセンテージ）ではなく、実際のバイト数で監視することで、より具体的な状況が把握できます。

取得できるメトリクス

SNMPで取得できる転送量のメトリクスには、32bitと64bitの2種類があります。

64bitカウンター（高速インターフェース向け）
- ifHCInOctets - 受信バイト数の累積値（64bit）
- ifHCOutOctets - 送信バイト数の累積値（64bit）
32bitカウンター（低速インターフェース向け）
- ifInOctets - 受信バイト数の累積値（32bit）
- ifOutOctets - 送信バイト数の累積値（32bit）

これらは累積カウンターなので、実際の転送量を知るには前回の値との差分を計算します。New Relicは自動的にこの差分計算を行ってくれます。

32bitと64bitカウンターの違いと注意点

カウンターのビット数によって、扱える最大値が大きく異なります。この違いを理解しておかないと、高速インターフェースで正確な測定ができません。

32bitカウンターの制限
32bitカウンターは最大値が約4.3GB（2³²バイト）です。高速インターフェースでは短時間でカウンターがオーバーフローしてしまいます。

例えば、1Gbpsリンクでフル稼働の場合、約34秒でオーバーフローします。10Gbpsリンクでは約3.4秒でオーバーフローしてしまいます。オーバーフローが発生すると、カウンターが0に戻るため、差分計算が正確にできなくなります。

64bitカウンターの利点
64bitカウンターは最大値が約1800万TB（2⁶⁴バイト）です。実質的にオーバーフローを気にする必要がありません。高速インターフェースでも安定した監視が可能です。

使い分けの指針
インターフェース速度に応じて、適切なカウンターを選択する必要があります。

100Mbps以下のインターフェースなら、32bitカウンターでも問題ありません。ポーリング間隔が1分程度であれば、オーバーフローのリスクは低いです。1Gbps以上のインターフェースでは、64bitカウンター（HC）を必須で使用します。特に10Gbps以上では、32bitカウンターは使えません。

古いデバイスの場合、64bitカウンターに対応していない場合があります。事前にSNMP MIBの対応状況を確認しておきましょう。

転送量監視の利点

転送量監視では、実際のデータ量に基づいた分析が可能です。

時間帯別のトラフィック傾向を把握できます。業務時間帯とそれ以外でどれだけトラフィックが変化するかが見えます。実際のデータ量に基づくキャパシティプランニングができます。1Gbpsリンクで50%の利用率と10Gbpsリンクで50%の利用率では、実際の転送量は大きく異なります。転送量で見れば、この違いが明確になります。

アプリケーション別のトラフィック消費量の比較も可能です。どのアプリケーションがどれだけ帯域を消費しているかを、具体的な数値で把握できます。

監視すべき2つの方向

転送量は、送信と受信の両方を監視する必要があります。

送信転送量（kentik.snmp.ifHCOutOctetsの差分）は、内部からインターネットへ、支社から本社へのトラフィックを示します。アップロード系アプリケーションの監視に重要でしょう。

受信転送量（kentik.snmp.ifHCInOctetsの差分）は、インターネットから内部へ、本社から支社へのトラフィックを示します。ダウンロード系アプリケーションの監視に重要でしょう。

送受信の転送量パターンを見ることで、そのリンクがどのような用途で使われているかが分かります。送信が多ければWebサーバーやファイルサーバーからの配信、受信が多ければクライアントのダウンロードやバックアップ処理などが推測できます。

インターフェース状態の組み合わせを理解する

New RelicのSNMP監視では、if_AdminStatus（管理状態）とif_OperStatus（動作状態）という2つの状態が収集されます。この組み合わせを正しく理解することが重要と考えています。

AdminStatusとOperStatusの意味

AdminStatusは、管理者が設定した状態です。「このポートを使う（up）」「使わない（down）」という設定値です。

OperStatusは、実際の動作状態です。物理的にリンクが確立しているか（up）、していないか（down）を示します。

組み合わせパターンの解釈

この2つの状態の組み合わせで、何が起きているかがわかります。

AdminStatus	OperStatus	意味	対応
up	up	正常稼働	対応不要
up	down	物理的問題あり	即座の調査が必要
down	down	意図的な停止	正常（メンテナンス等）
down	up	通常あり得ない	設定の再確認

本当に注意すべきなのは「Admin=up、Oper=down」の状態です。これは「使いたいのに使えない」状態、つまり障害を意味します。逆に「Admin=down、Oper=down」は、意図的に停止している状態なので、正常です。メンテナンスで一時的に停止している場合などがこれに当たります。

単純に「down」だけを監視すると、意図的な停止も検知してしまい、誤検知が増えます。また、状態監視を確実におこなうには実際のポートへの接続と設定的なポート開放を確実に管理する必要があり、運用上ポート開け閉めの管理をするのがツライからという理由でポートを全開放してしまうとこの運用は成り立たないので注意が必要です。

こうした状況をきっちり把握しておかないと、トラブルがあった時に迅速な対処なんてできませんよね？そう、オブザーバビリティとはこうした詳細の状態の意味を正しく理解して把握することなんですよ。

エラーメトリクスの解釈

インターフェースのエラー数も重要な監視対象ですが、エラーの種類によって原因が異なります。

エラーの種類と原因

ifInErrorsとifOutErrorsは、CRCエラー、フレームエラー、アライメントエラーなどを示します。原因としては、物理層の問題、ケーブル不良、EMI（電磁干渉）などが考えられます。

ifInDiscardsとifOutDiscardsは、バッファ不足による破棄を示します。原因としては、トラフィックバースト、不適切なQoS設定などが考えられます。

エラー率で判断する

エラーの絶対数だけでなく、エラー率で判断することが重要です。

エラー率 = エラー数 / 総パケット数

0.01%未満なら、許容範囲です。通常のノイズレベルと考えられます。0.1%以上なら、調査対象です。何か問題がある可能性があります。継続的にエラーが発生している場合は、物理層の問題を強く示唆しています。例えば、1時間に10個のエラーが出ていても、その間に100万パケット流れていれば、エラー率は0.001%で問題ありません。でも、1万パケットしか流れていないのに10個のエラーなら、エラー率は0.1%で調査が必要です。

デバイスパフォーマンス監視の実践

次に、ルーターやスイッチ自体のパフォーマンス監視について見ていきましょう。

CPU使用率の正しい解釈

CPU使用率は一見シンプルな指標ですが、その解釈には文脈が重要です。

数値だけでは判断できない

90%でも正常な場合があります。トラフィック処理が主な負荷で、予測可能なパターンなら問題ありません。逆に、70%でも問題な場合があります。通常30%なのに急上昇して、原因が不明な場合は調査が必要です。

ベースラインを確立する

CPU使用率を監視する際は、以下の問いかけが重要です。

このデバイスの通常のCPU使用率は何%か？（ベースライン）
現在の値は通常からどれだけ逸脱しているか？
この上昇は予測可能なパターンか、それとも異常か？

例えば、毎日夜間にバックアップが走ってCPUが上がるなら、それは正常なパターンです。でも、普段30%なのに突然80%になったら、何か異常が起きている可能性があります。

Syslogと組み合わせて理解する

CPU使用率が急上昇した際、同じ時刻のSyslogを確認することで原因を特定できます。

OSPFの再計算なら、隣接ルーターの変更によるルーティングテーブルの再構築が原因です。BGPフラップなら、BGPピアの不安定性によるルート更新の増加が原因です。設定変更のコミットなら、大規模な設定変更の適用が原因です。

これがオブザーバビリティの実践です。複数のシグナルを相関させて理解する能力が重要なんです。

メモリ使用率の考え方

メモリ使用率は、デバイスタイプによって正常範囲が大きく異なります。

デバイスタイプ別の正常範囲

ルーターの場合、ルーティングテーブルやBGPテーブルで常にメモリを使用するため、70-80%でも正常な場合が多いです。ただし、通信が多いなどの環境で短期的にセッションが多くなる場合、こうしたことが起因してメモリが不足する可能性も考えられます。

スイッチの場合、MACアドレステーブルやARPテーブルを保持するため、50-60%程度が一般的といわれています。

トレンドを監視する

メモリ使用率で重要なのは、絶対値よりもトレンドです。

月次・週次での増加傾向を見ることで、メモリリークやテーブル肥大化を早期に検知できます。これはキャパシティプランニングにも活用できます。

NRQLでトレンド分析するなら、こんなクエリが使えます。

FROM Metric 
SELECT average(kentik.snmp.MemoryUtilization) 
WHERE device_name = 'core-router-01' 
TIMESERIES 1 day 
SINCE 90 days ago

これで過去90日間の日次平均を見ることができます。徐々に増加しているなら、何か問題がある可能性があります。

応答時間（RTT）の意味

応答時間（Round Trip Time）は、デバイスまでの通信にかかる時間です。これも、物理的な制約を理解しておく必要があります。

物理的距離とレイテンシの関係

光ファイバー内の光の速度は約200,000 km/秒です。この物理的制約により、距離に応じた理論値があります。東京-大阪間（400km）なら、理論上2ms、実際は5-10msで、実際の値が理論値より大きいのはルーターでの処理時間やキューイング遅延、経路の迂回などが加わるためです。

ベースラインの確立が必須

RTTを監視する際は、まず拠点間の正常時RTTを記録しておきます。そして、正常値から50%以上増加したら調査対象とします。急激な変化があったら、ルーティング変更や経路迂回の可能性を疑います。

パケットロスとの相関

RTTとパケットロスを組み合わせて見ることで、問題の性質がわかります。RTT上昇とパケットロスが同時に発生しているなら、回線品質の問題です。RTTは正常でパケットロスだけ発生しているなら、ローカルな問題（インターフェースやバッファ）です。

実践的な設定のコツ

ここまでメトリクスの読み方を見てきましたが、実際に設定する際のコツもいくつか紹介します。

ポーリング間隔の考え方

SNMPのポーリング間隔は、デフォルトで60秒（1分）です。これを変更する際は、トレードオフを理解しておく必要があります。

短い間隔（30秒など）にすると、より細かい変化を捉えられますが、デバイスへの負荷が増え、New Relicへのデータ送信量も増えます。長い間隔（5分など）にすると、デバイスへの負荷は減りますが、短時間のスパイクを見逃す可能性があります。

一般的には、コアデバイスは60秒、アクセススイッチは300秒（5分）といったような使い分けが推奨されます。

タイムアウト設定の調整

SNMPのタイムアウトは、デフォルトで5秒です。ネットワーク環境によっては、これを調整する必要があります。

遠隔地のデバイスや、低速回線経由のデバイスは、タイムアウトを10秒程度に延ばすことを検討したり、同一セグメント内のデバイスは、3秒程度に短縮するようなことを検討してもいいかもしれません。タイムアウトが頻発する場合は、エージェントの配置場所を見直すことも検討しましょう。

リトライ回数の設定

SNMPのリトライ回数は、デフォルトで1回です。ネットワークが不安定な環境では、2-3回に増やすことで、一時的なパケットロスによる失敗を減らせるでしょう。ただし、リトライ回数を増やすと、タイムアウト時の待ち時間が長くなるので、バランスが重要です。

まとめ

今回は、New Relicで収集したメトリクスの読み方と、実践的な設定のコツを見てきました。

重要なポイントをおさらいすると、帯域使用率は送信と受信を分けて監視し、インターフェース速度の設定が正確かを確認します。インターフェース状態は、AdminStatusとOperStatusの組み合わせで判断します。CPU使用率やメモリ使用率は、ベースラインを確立してトレンドを見ることが重要です。

次回の記事では、監視の優先順位をどう設計するか、効果的な運用戦略について解説します。すべてのデバイスを同じように監視するのではなく、ビジネスへの影響度に基づいた戦略的な監視を実現する方法を見ていきましょう。

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

宣伝

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

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

New Relicネットワーク監視の実践～メトリクス設定と読み解き方～

目次