ネットワーク監視の基本設計とは

監視ツールには、Zabbix、PRTG、SolarWinds、Nagios、Prometheusなど、さまざまな製品があります。 しかし、製品が変わっても設計で考える内容は大きく変わりません。

たとえば、ルーターを監視するときには、最低でも次の内容を決めます。

• ルーター自体が応答しているか
• WANインターフェースがUpか
• 通信量やエラーが増えていないか
• CPU・メモリー・温度に異常がないか
• 再起動、リンクダウン、認証失敗などのログが出ていないか
• 異常を何回連続で検知したら通知するか
• 業務時間外は誰へ通知するか
• 復旧時にも通知するか
• 通知を受けた担当者が最初に何を確認するか

監視の全体像

ネットワーク監視は、機器から情報を集めるだけでは完了しません。 収集、判定、通知、対応、復旧確認までを一つの流れとして設計します。

「検知できる」だけでは不十分

監視サーバーがリンクダウンを検知しても、通知先が未設定なら対応は始まりません。 通知先が決まっていても、対象ポートの用途が分からなければ影響を判断できません。

したがって、監視項目には技術情報だけでなく、次の運用情報も必要です。

• 対象機器・インターフェースの役割
• 利用部門・業務・システム
• 障害時の影響範囲
• 運用担当、保守ベンダー、回線事業者
• 一次対応手順とエスカレーション条件

監視項目を5つに分ける

監視項目は、次の5つへ分けると漏れや重複を整理しやすくなります。

pingが通る＝サービス正常ではない

pingへ応答するWebサーバーでも、Webサービスが停止していればページは表示できません。 反対に、セキュリティポリシーでICMPを拒否していても、HTTPSは正常に動作する場合があります。

監視方式を使い分ける

監視方式は、大きく「監視サーバーから定期的に取得する方式」と「機器からイベントを送る方式」に分けられます。

監視項目ごとに決める情報

「CPUを監視する」「リンクダウンを監視する」だけでは、設計情報として不足しています。 監視項目ごとに、少なくとも次の内容を整理します。

監視間隔は短いほどよいとは限らない

監視間隔を短くすると、異常を早く検知できます。 一方で、監視サーバー、ネットワーク、対象機器への負荷や、保存データ量が増えます。

しきい値の決め方

しきい値とは、取得した値を正常・警告・重大などへ分類する境界です。 しきい値を固定値だけで決めると、誤検知や見逃しが増えることがあります。

1．平常時の値を測る

まず、通常時・繁忙時・バックアップ時などの値を一定期間記録し、基準となる状態を把握します。 この基準をベースラインと呼びます。

たとえば、平常時のWAN使用率が常に60～70%の拠点で、70%を警告にすると、毎日アラートが発生します。 反対に、普段5%しか使わない回線が突然60%になった場合は、固定しきい値80%では異常に気づけません。

2．瞬間値ではなく継続時間を見る

CPUや通信量は、処理の開始時に一時的に上がることがあります。 1回だけしきい値を超えた時点で通知すると、不要なアラートが増えます。

• 3回連続でping失敗したら障害
• CPU使用率90%以上が5分続いたら重大
• パケットロス5%以上が3回続いたら警告
• インターフェースDownは即時通知

3．発報条件と復旧条件を分ける

しきい値付近で値が上下すると、障害と復旧が何度も通知されることがあります。 これを防ぐため、発報条件と復旧条件に差を設けます。

4．累積カウンターは増加量で見る

インターフェースのエラーカウンターは、機器起動後から累積されることがあります。 累積値が100という事実だけでは、現在もエラーが増えているか判断できません。

監視では、前回取得値との差分や単位時間あたりの増加率を確認します。 通信量も、オクテットカウンターの差分からbpsへ換算して利用率を判断します。

重要度・通知・エスカレーション

すべてのイベントを同じ方法で通知すると、重要な障害が埋もれます。 業務影響と緊急度に応じて重要度を分け、通知経路を変えます。

通知設計で決めること

• 通知先の部署・担当者・オンコール
• メール、チャット、電話、チケットなどの手段
• 平日・休日、昼間・夜間の通知先
• 何分未対応なら再通知するか
• どの条件で上位担当・保守ベンダーへ連絡するか
• 復旧通知を誰へ送るか
• 利用者・顧客へ状況を報告する条件

大量アラートを防ぐ設計

監視対象が増えると、一つの障害から多数のアラートが発生することがあります。 この状態を放置すると、担当者が根本原因を見つけにくくなります。

親子関係・依存関係を設定する

WAN回線が停止すると、拠点内のスイッチ、アクセスポイント、サーバーも監視サーバーから見えなくなります。 すべてを個別障害として通知するのではなく、上位経路の障害を優先して表示します。

メンテナンス時間を登録する

計画停止中にアラートが発生すると、不要な通知が大量に送られます。 作業開始前に対象機器・時間帯をメンテナンスモードへ登録し、通知抑止と記録を行います。

同じ障害をまとめる

• 同一イベントの重複通知をまとめる
• 障害継続中は一定間隔で再通知する
• 短時間のDown／Upを一つの事象として扱う
• 冗長構成では片系障害と全系障害を分ける
• 不要な未使用ポートやDebugログを監視対象から外す

小規模オフィスの監視設計例

次の構成を例に、監視項目一覧を作ります。

アラートを受けたときの確認順序

1. アラート内容を確認する 対象、時刻、監視項目、重要度、継続時間、関連アラートを確認します。
2. 業務影響を確認する 利用者、拠点、VLAN、サービス、冗長系の状態から影響範囲を判断します。
3. 上位経路から確認する 監視サーバー、回線、ルーター、スイッチ、対象サービスの順に到達性を確認します。
4. 状態・ログ・履歴を確認する 現在値だけでなく、直前の変化、Syslog、設定変更、グラフを確認します。
5. 一次報告・エスカレーションを行う 発生時刻、影響、確認結果、暫定対応、次の確認事項を整理して連絡します。
6. 復旧と再発を確認する アラート復旧だけでなく、利用者視点の通信試験と一定時間の安定性を確認します。

監視設計で作る成果物

監視設定を担当者の記憶だけで運用すると、機器追加や担当変更のたびに品質が変わります。 最低限、次の成果物を残します。

監視項目一覧のテンプレート

No.
拠点名
機器名
管理IPアドレス
監視対象・インターフェース
監視項目
監視方式
取得間隔
警告条件
重大条件
復旧条件
重要度
通知先
通知時間帯
再通知・エスカレーション
一次対応
保管期間
備考

ネットワーク監視設計でよくある失敗

自分の言葉で説明する課題