変更要約: 初版
5.1ネットワーク管理と監視
SNMP（マネージャ／エージェント／MIB／OID）による機器監視、ポーリングとトラップの使い分け、SNMPv3のセキュリティ強化、NetFlow・sFlowによるフロー監視、シスログによるイベント収集、そして障害を早期発見するための監視設計の考え方を学びます。
ネットワーク運用者にとって「障害が起きてから気づく」のと「障害の予兆を検知して先手を打つ」のとでは、サービス影響が大きく変わります。この節では、機器の状態を定期的・自発的に把握するSNMPの仕組みと、大量の通信を俯瞰するフロー監視、そしてイベントを集約するシスログを組み合わせ、「何をどう監視すれば異常を早期に検知できるか」という監視設計の判断力を養います。
5.1.1SNMPの仕組み（マネージャ／エージェント／MIB／OID）
- SNMP（Simple Network Management Protocol）＝ネットワーク機器を集中的に監視・管理するためのプロトコル。監視する側のマネージャ（監視サーバ）と監視される側のエージェント（ルータ・スイッチ等に常駐するソフトウェア）から成る。
- MIB（Management Information Base）＝エージェントが公開する管理情報を階層的に整理したデータベース定義。個々の管理項目（インタフェースの通信量、CPU使用率等）はOID（Object Identifier）という木構造の番号で一意に識別される。マネージャはOIDを指定して値を取得・設定する。
5.1.2ポーリングとトラップ
- ポーリング＝マネージャがエージェントに一定間隔で問い合わせ（GETリクエスト）を送り、値を能動的に収集する方式。収集周期を短くすれば検知は早まるが、機器・回線への負荷とトラフィックが増えるトレードオフがある。
- トラップ＝エージェント側が異常や状態変化（インタフェースダウン等）を検知した時点で、マネージャの問い合わせを待たずに自発的に通知する方式。即時性は高いが、UDPで送りっぱなしのため到達保証がない（トラップが届かず異常検知が遅れるリスクがある）。実務ではポーリングによる定期確認とトラップによる即時通知を併用し、片方の欠落を他方で補うのが定石。
5.1.3SNMPv3によるセキュリティ強化
- SNMPv1/v2cはコミュニティ名（平文のパスワードに相当）だけで認証するため、盗聴・なりすましに弱い。SNMPv3はユーザ単位の認証（USM：メッセージ改ざん・なりすましの検出）と暗号化（ペイロードの秘匿）を追加し、管理者権限の悪用や盗聴のリスクを大きく下げる。
- 社外からもアクセスしうる管理用ネットワークや、重要な基幹機器を監視する場合は、後方互換のためだけにv2cを使い続けるのではなくSNMPv3への移行が優先度の高い設計判断になる。
5.1.4フロー監視（NetFlow／sFlow）とシスログ
- NetFlow＝送信元/宛先IP・ポート番号・プロトコル等が同じ通信の集まり（フロー）単位で、トラフィックの統計情報（バイト数・パケット数等）を収集する技術。「どのアプリケーション・どの宛先が帯域を消費しているか」を可視化でき、輻輳の原因特定や異常なトラフィック（DDoS等の兆候）の検知に使う。sFlowはパケットを一定確率でサンプリングして集計する方式で、超高速回線でも低負荷に統計を取れる。
- シスログ（syslog）＝機器やサーバが出力するイベントログ（エラー・警告・状態変化等）を、UDP/TCPの514番ポート等で一元的に集約するための仕組み。重大度（severity）別に分類でき、集約先のログサーバでリアルタイム相関分析やアラート発報を行うことで、複数機器にまたがる障害の全体像を素早く把握できる。
「トラップ＝即時性はあるがUDPで到達保証なし」「ポーリング＝確実だが周期に依存し負荷が増える」「SNMPv3＝認証＋暗号化でv1/v2cの平文コミュニティ名問題を解決」が最頻出です。NetFlow/sFlowは「フロー単位の統計」対「サンプリングで低負荷」という対比で押さえましょう。
あるデータセンター運用チームが、深夜のバッチ処理中にコアスイッチの特定ポートで断続的なパケットロスが発生する障害を経験し、再発防止の監視体制を設計するとします。まず既存構成を確認すると、ポーリング周期が5分のSNMP監視のみで、トラップ受信の仕組みが未導入でした。5分周期のポーリングでは、数十秒〜数分で自然回復する断続的な障害を見逃す（次のポーリングタイミングまでに正常値に戻ってしまう）リスクが高いと判断し、まずインタフェースダウン等の重大イベントはトラップで即時通知させ、ポーリングは補完的な定期確認（例えば1分間隔に短縮）に位置づけ直しました。次に「特定ポートのパケットロス」の原因を切り分けるため、NetFlowを有効化してポート単位・フロー単位のトラフィック統計を取得することにしました。これにより、断続障害の発生時間帯に特定の宛先への通信量が急増していたことが判明すれば「輻輳が原因」、通信量に変化がなければ「物理層・機器故障が原因」という切り分けが可能になります。最後に、コアスイッチ・関連するファイアウォール・ロードバランサのログをシスログサーバに集約し、障害発生時刻を軸に複数機器のログを相関分析できる体制を整えました。このように監視設計は、単一の技術に頼るのではなく、即時性（トラップ）・定期確認（ポーリング）・原因特定（フロー監視）・全体像の把握（シスログ集約）を組み合わせ、検知の抜け漏れと原因不明のまま長期化するリスクを同時に減らす判断が核になります。
| 手段 | 得意なこと | 弱点/注意点 |
|---|---|---|
| ポーリング（SNMP GET） | 確実に定期取得できる | 周期に依存し短期障害を見逃しうる・負荷増 |
| トラップ | 異常発生を即時通知 | UDPで到達保証なし |
| NetFlow／sFlow | フロー単位で原因を切り分け | sFlowはサンプリングのため厳密値ではない |
| シスログ集約 | 複数機器のログを横断的に相関分析 | 重大度設計を誤るとノイズに埋もれる |
ひっかけ： 「トラップだけ導入すればポーリングは不要になる」は誤りです——トラップはUDPで到達保証がないため、トラップの喪失に気づく手段として定期的なポーリング（生存確認）が依然必要です。また「SNMPv1/v2cはコミュニティ名を複雑にすれば安全になる」も誤り＝コミュニティ名は平文で送信されるため、複雑にしても盗聴には無力であり、根本対策はSNMPv3への移行です。
5.1.5この節のまとめ
- SNMPはマネージャ／エージェント／MIB／OIDで構成。ポーリング（定期・確実だが負荷）とトラップ（即時だが到達保証なし）は併用が定石
- SNMPv3は認証＋暗号化でv1/v2cの平文コミュニティ名問題を解決
- NetFlow/sFlowでフロー単位の原因切り分け、シスログ集約で複数機器を横断した障害の全体像把握
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. あるネットワーク運用チームは、5分周期のSNMPポーリングのみで監視していたところ、数十秒で自然回復する断続的なインタフェース障害を検知できなかった。再発防止のために追加すべき監視強化として最も適切なものはどれか。
Q2. 社外からもアクセス可能な管理用ネットワークで重要な基幹スイッチをSNMPで監視する構成を新規設計する場合、セキュリティ上最も優先すべき判断はどれか。
Q3. コアスイッチの特定ポートで発生したパケットロスの原因が「特定の宛先への通信急増による輻輳」なのか「物理層の機器故障」なのかを切り分けたい。最も有効な監視手段はどれか。