ネットワーク監視設計とは？監視項目・しきい値・通知・監視基盤の設計方法を解説

2026年8月11日

ネットワーク上級編 19／全70記事

この記事は、「ネットワーク上級編｜要件定義・設計・クラウド・自動化へ進む」の第19回です。

第2章では、要件定義で整理した条件をもとに、 IPアドレス、VLAN、ルーティング、冗長化、WAN、VPN、 DNS・DHCP、監視、ログなどの基本設計へ落とし込みます。

NETWORK ADVANCED｜CHAPTER 2 BASIC DESIGN

ネットワーク監視設計とは？
監視項目・しきい値・通知・監視基盤の設計方法

監視ツールへルーターやスイッチを登録するだけでは、適切な監視設計とはいえません。「何を検知したいのか」「どこから監視するのか」「監視経路自体が止まったらどうするのか」「誰へ通知し、どのように対応へつなげるのか」まで設計する必要があります。この記事では、ネットワーク全体を運用できる監視アーキテクチャの作り方を解説します。

対象レベル Level 3〜4・上級

想定読了時間 約35分

身につく成果 監視アーキテクチャを設計できる

前提知識 監視基礎・冗長化・WAN

演習環境 ブラウザ・Excel等

中級編では、ネットワーク監視の基本設計として、死活監視、状態監視、性能監視、しきい値、通知などを学びました。

上級編では、さらに一段上の視点から、 「企業ネットワーク全体を、どの構成で、どこから、どの粒度で監視するか」 を考えます。

監視対象のルーターを二重化していても、監視サーバーが1台しかなく、そのサーバーが停止したら、障害を検知できなくなるかもしれません。本社から全拠点を監視している場合は、 WAN障害によって拠点内のすべての機器が「Down」に見えることもあります。

監視対象だけではなく、 監視する仕組みそのものも設計対象です。

この記事を読み終えるとできること

監視設計の目的を説明できる
監視対象を業務影響から選定できる
監視方式を使い分けられる
しきい値と重要度を設計できる
監視経路と依存関係を設計できる
監視基盤の冗長化を検討できる
分散監視の必要性を判断できる
監視設計書の項目を作成できる

ネットワーク監視設計とは何か

最初に覚える定義

ネットワーク監視設計とは、障害や性能劣化を適切に検知して運用担当者の対応へつなげるために、監視対象・監視方式・判定条件・通知・監視経路・監視基盤を設計することです。

監視というと、「pingで機器が生きているか確認する」ことを最初に思い浮かべるかもしれません。

しかし、実際の企業ネットワークでは、機器がpingへ応答していても業務通信が利用できない場合があります。

WAN回線が混雑している
OSPFやBGPの隣接関係が切れている
VPNトンネルが停止している
DNS名前解決が失敗している
DHCPアドレスプールが枯渇している
冗長構成の片系が故障している
インターフェースエラーが増加している
CPUやメモリーの高負荷が継続している

監視設計の目的は「機器を監視すること」ではありません。

業務へ影響する異常を必要なタイミングで検知し、担当者が判断・対応できる状態を作ることが目的です。

監視項目と監視設計は違う

考え方	内容
監視項目	CPU、メモリー、インターフェース、pingなど、取得する情報
監視設計	何を・なぜ・どこから・どの条件で監視し、異常時にどう対応するかを決める

要件から監視設計へ落とし込む流れ

監視ツールで取得できる項目を先に一覧化するのではなく、要件から逆算して設計します。

MONITORING DESIGN FLOW｜要件から運用まで

📋 監視要件 何を守るか

→

🎯 監視対象 どこを見るか

→

📡 監視方式 どう取得するか

→

⚖️ 判定条件 何を異常とするか

→

🔔 通知誰へ伝えるか

→

🛠️ 対応何をするか

例：インターネット接続を監視する

段階	設計例
要件	インターネット接続障害を早期に検知したい
監視対象	FW、WANポート、ISP回線、外部到達性、DNS
方式	ICMP、SNMP、Trap、外部疎通確認、DNS監視
判定	連続失敗、リンクDown、パケットロス、応答遅延など
通知	運用担当へ重大アラートを通知
対応	FW・回線・ISP・DNSのどこに原因があるか切り分ける

このように、 監視項目は「検知したい障害」から逆算して決定します。

監視の目的を先に決める

同じネットワーク機器でも、監視の目的によって必要な監視項目は変わります。

障害を検知する

機器停止、リンクダウン、回線断などを早期に把握します。

性能劣化を検知する

帯域逼迫、遅延、パケットロス、CPU高騰などを検知します。

予兆を把握する

エラー増加やリソース使用率の上昇から、障害前の変化を確認します。

容量計画へ使う

通信量や接続数の推移を確認し、回線・機器増強の判断材料にします。

障害原因を絞る

複数の監視結果を組み合わせ、どこで異常が起きたか判断します。

サービス品質を確認する

DNS、VPN、Webアクセスなどを利用者に近い視点で確認します。

「取得できるから監視する」は避けます。

監視対象を増やすほど、監視サーバーの負荷、保存データ、アラート、運用担当者の確認作業も増えます。

何を監視対象にするのか

監視対象は、機器単位だけではなく、 通信経路・プロトコル・サービス・冗長状態 まで分解して考えます。

機器

ルーター
スイッチ
ファイアウォール
無線LAN機器
ロードバランサー

インターフェース

Up／Down
通信量
エラー
破棄
光レベルなど

機器リソース

CPU
メモリー
温度
電源
ファン

ルーティング

OSPFネイバー
BGPピア
経路数
デフォルトルート

冗長化

VRRP・HSRP等
FW HA状態
LAG状態
冗長電源
回線切り替え状態

ネットワークサービス

DNS名前解決
DHCP払い出し
VPNトンネル
HTTPS応答
認証サービス

冗長構成では「通信継続」と「片系故障」を分ける

冗長化されたネットワークでは、片方の機器が停止しても通信自体は継続する場合があります。

だからといって正常として扱うと、次の障害が発生した時点で全断になる可能性があります。

状態	業務通信	監視上の扱い
2系統とも正常	正常	正常
片系故障	継続	警告・早期復旧対象
両系統故障	停止	重大・即時対応

冗長化では、 「サービスは動いているが冗長性を失っている状態」 を検知できるようにします。

監視方式をどう使い分けるか

1種類の監視方式だけですべてを確認するのではなく、取得したい情報に応じて使い分けます。

方式	主な用途	設計時のポイント
ICMP	死活・到達性・応答時間	ICMPが許可されているか、どこから監視するか
SNMPポーリング	状態・性能・通信量・リソース	監視間隔、取得項目、認証、対象機器負荷
SNMP Trap	状態変化のイベント通知	通知欠落を考慮し、定期監視との併用を検討
Syslog	イベント・異常・設定変更	詳細なログ設計は次の記事で扱う
API	コントローラー・クラウド・SD-WAN等	認証、取得制限、仕様変更、エラー処理
サービス監視	DNS、HTTP、VPNなどの利用可否	利用者に近い監視地点を選ぶ
テレメトリー	高頻度な状態・性能データ	データ量、保存先、必要な粒度を検討

監視経路も設計する

SNMPやICMPを利用する場合、「対象機器が対応しているか」だけでは不十分です。

監視サーバーから対象機器へ到達できるか
どの管理IPアドレスを監視するか
管理用VLANを使用するか
ファイアウォールやACLで必要通信を許可するか
障害時にも監視経路を維持できるか
拠点間WAN断時にどう検知するか
監視通信を一般利用者通信から分離するか

本番通信が止まったとき、 監視通信も同じ経路で同時に停止する 場合があります。

「監視できない＝対象機器故障」と即断できないため、監視経路そのものを把握しておく必要があります。

しきい値をどう設計するか

監視項目を決めたら、どの状態を「正常」「警告」「重大」とするかを決めます。

ただし、 CPU 80％以上なら必ず異常 といったように、数字だけを固定してはいけません。

しきい値は「値 × 継続時間 × 回数」で考える

正常
CPU 70％未満

警告
70％以上が10分継続

重大
90％以上が5分継続

上記は説明用の例です。実際には、機器仕様、業務要件、通常時の値、ピーク時間帯などを確認して決定します。

ベースラインを確認する

新規監視を始める場合は、平常時の通信量やCPU、メモリー、遅延などを一定期間確認します。

たとえば、通常時からWAN回線を70％程度使用している環境で、 70％を警告にすると毎日アラートが発生します。

一方、通常5％程度しか利用していない回線が突然60％まで上昇した場合、固定しきい値80％だけでは異常な変化を見逃す可能性があります。

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

しきい値付近で値が上下すると、障害通知と復旧通知を繰り返すことがあります。

例：WAN使用率

80％以上が10分継続 → 警告
70％未満が10分継続 → 復旧

発報と復旧に差を設けることで、不要な通知の繰り返しを防ぎます。

瞬間値だけを見ない

pingが3回連続失敗したら異常
CPU高負荷が5分以上継続したら警告
エラーカウンターが継続的に増加したら警告
インターフェースDownは即時検知

監視項目ごとに、即時性が必要なのか、一時的な変動を許容するのかを判断します。

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

監視で特に重要なのは、 「異常を検知した後に何が起きるか」 を設計することです。

重要度	状態例	通知例	対応
情報	通常イベント・管理情報	監視画面・記録	定期確認
警告	冗長片系故障、高使用率、エラー増加	メール・チャット等	業務時間内などに確認
重大	基幹回線断、重要機器全停止、サービス停止	即時通知・オンコール等	速やかに障害対応開始

重要度は技術だけで決めない

同じ「インターフェースDown」でも、接続先によって重要度は変わります。

未使用ポート

業務影響なし。通常は通知不要または情報レベル。

冗長回線の片系

通信は継続するが冗長性を失うため、警告として対応。

唯一の基幹回線

拠点全体へ影響するため、重大として即時対応。

エスカレーション条件も決める

一次通知 運用担当者へアラートを通知します。
一次確認 対象、影響範囲、冗長系、関連アラートを確認します。
未対応時の再通知 指定時間内に対応開始されなければ再通知します。
上位エスカレーション 責任者、設計担当、保守ベンダー、回線事業者などへ連絡します。
復旧確認 アラート復旧だけでなく、業務通信が正常化したか確認します。

依存関係とアラート抑止を設計する

大規模ネットワークでは、 1つの障害から数十、数百件のアラートが発生することがあります。

例：拠点WAN回線が切断した場合

1本のWAN障害が大量アラートになる例

本社監視 中央監視サーバー

→

WAN回線 ここで障害

→

拠点Router 応答なし

→

拠点LAN 全機器応答なし

WAN回線が停止すると、本社から見れば拠点内のスイッチやAPもすべてDownになります。

このとき、機器20台から20件の重大アラートを通知するより、 上位のWAN障害を根本原因候補として優先表示 した方が運用しやすくなります。

依存関係を定義する

回線 → ルーター → スイッチ → AP・サーバー
ファイアウォール → インターネットサービス監視
DNSサーバー → 名前解決監視
VPNゲートウェイ → 拠点間サービス監視

メンテナンス時間も設計する

計画作業で機器を停止する場合に通常アラートを発生させると、運用担当者が不要な通知へ対応することになります。

対象機器
作業開始・終了時間
通知を抑止する範囲
監視データを記録するか
予定時刻を超えた場合の扱い

通知抑止＝監視停止ではありません。

データやイベントは記録しつつ、人へ送る不要な通知だけを抑える設計が理想です。

監視アーキテクチャを設計する

上級編で特に意識したいのが、 監視サーバーをどこに配置するか という視点です。

単一拠点なら中央監視でも構成しやすい

中央監視型の基本構成

Router

Firewall

Switch

↓ 監視データ ↓

中央監視サーバー
ICMP・SNMP・Trap・API・サービス監視

↓

通知・ダッシュボード・運用担当

複数拠点では分散監視を検討する

本社に監視サーバーを1台だけ配置して全拠点を監視すると、 WAN障害時には拠点内の状態を確認できなくなる可能性があります。

そのため、規模や要件によっては、各拠点や主要リージョンへ監視用Collector・Proxyなどを配置します。

分散監視の考え方

東京拠点
Local Collector

大阪拠点
Local Collector

Cloud
Monitoring Point

↓ 集約 ↓

中央監視基盤

↓

ダッシュボード・アラート・運用チーム

分散監視を検討する主な理由

WAN断時にも拠点内部の状態を取得したい
多数機器へのポーリングを分散したい
海外・遠隔地との遅延を減らしたい
監視トラフィックをWANへ集中させたくない
拠点ごとのサービス状態を確認したい

外部からの監視も有効

社内からインターネット接続を監視するだけでは、社外利用者からサービスへ接続できるか確認できない場合があります。

外部公開サービスなどでは、社内監視とは別に、 社外から利用者視点で確認する監視 を組み合わせることも検討します。

監視基盤自体を監視する

見落としやすいのが、 監視サーバー自身の障害です。

監視サーバーが停止すると、ネットワークで障害が起きても通知できなくなる可能性があります。

監視基盤で確認したい項目

監視サーバー

CPU・メモリー
ディスク容量
監視プロセス
データベース
時刻同期

監視処理

ポーリング遅延
監視キュー滞留
Collector接続状態
通知送信失敗
データ欠損

通信

監視対象への到達性
管理ネットワーク
WAN接続
DNS・NTP

外部監視

監視基盤へのHeartbeat
別基盤からの死活確認
通知経路のテスト
定期的な発報試験

「何もアラートが出ていない」ことと「すべて正常」は同じではありません。

監視処理そのものが停止している可能性もあるため、監視基盤の正常性を別の方法で確認できる構成を検討します。

監視基盤の冗長化を決める

監視基盤をどこまで冗長化するかも要件次第です。

構成	特徴	向いているケース
単一サーバー	シンプルで低コスト	小規模・停止影響が限定的
バックアップ・手動復旧	復旧可能性を確保	一定時間の監視停止を許容できる
冗長構成	監視継続性を高める	24時間監視や重要システム
分散Collector	拠点障害・負荷分散に対応	大規模・多拠点環境

企業ネットワークの監視設計例

次のようなネットワークを例に考えます。

監視対象となる企業ネットワーク

Internet ISP

→

FW-01 / FW-02 冗長構成

→

Core SW 社内LAN

→

WAN 支店接続

対象	監視項目	方式	判定例	重要度
FW-01/02	死活	ICMP・1分	3回連続失敗	片系：警告／両系：重大
FW-01/02	HA状態	SNMP/API	想定状態から変化	警告
Internet回線	外部到達性	ICMP等・1分	複数宛先へ連続失敗	重大
WAN	遅延・ロス	定期測定	基準値超過が継続	警告
Core SW	重要ポート状態	SNMP＋Trap	Down	接続先により警告／重大
Core SW	IFエラー	SNMP・5分	単位時間あたり継続増加	警告
Router	OSPF/BGP状態	SNMP/API/Event	Neighbor/Peer Down	警告または重大
DNS	名前解決	DNS問い合わせ	連続失敗・不正応答	重大
DHCP	プール使用率	API/SNMP等	設計しきい値超過	警告
監視基盤	監視処理	自己監視＋外部監視	処理停止・データ欠損	重大

上記の監視間隔やしきい値はあくまで設計例です。

実際には、可用性要件、障害検知時間、保守体制、機器性能、監視製品の仕様、平常時の実測値などをもとに決定します。

監視設計書へ残す内容

監視設計では、最終的に監視ツールへ設定できる粒度まで情報を整理します。

監視設計書に記載したい主な項目

監視対象機器・サービス
機器名・IPアドレス
対象インターフェース
監視項目
監視方式
監視元
監視間隔
警告しきい値
重大しきい値
継続時間・連続回数
復旧条件
重要度
通知先
通知方法
再通知条件
エスカレーション先
依存関係
メンテナンス条件
一次対応
担当部署・保守先

監視設計書のサンプル

対象	項目	方式	間隔	警告	重大	通知先	一次対応
RTR-01	死活	ICMP	1分	－	3回連続失敗	NOC	上位回線・電源・到達経路確認
RTR-01 Gi0/0	使用率	SNMP	5分	80％継続	90％継続	NOC	トラフィック傾向確認
RTR-01	OSPF Neighbor	SNMP/API等	1分	片系Down	全隣接Down	NOC/設計担当	対向・IF・経路確認

監視設計書を見るだけで、 「何を異常として、誰が、どう動くのか」 が分かる状態を目指します。

監視設計でよくある失敗

1．監視できる項目を全部登録する

アラートが増え、本当に重要な障害が埋もれます。

業務影響と対応要否から監視対象を決めます。

2．pingだけで正常判断する

機器が応答していても、ルーティングやVPN、DNSなどが異常な場合があります。

3．すべて同じしきい値にする

機器や回線、業務によって正常値は異なります。

ベースラインと業務要件から調整します。

4．通知先しか決めない

アラートを受けた後の一次確認、エスカレーション、復旧確認まで設計します。

5．依存関係を考えない

回線1本の障害で大量の機器Downが通知され、根本原因を見つけにくくなります。

6．監視サーバー自身を監視しない

監視基盤が停止していても「アラートなし」に見えてしまう可能性があります。

7．監視経路を構成図に残さない

本番通信障害なのか、監視経路だけの障害なのか判断できなくなります。

8．メンテナンス設計をしない

計画停止のたびに大量の不要通知が発生します。

顧客・上司へ監視設計をどう説明するか

監視の説明で、「SNMPでCPUを取ります」「ping監視を1分間隔にします」と技術項目だけを説明しても、監視設計の価値は伝わりにくい場合があります。

技術を業務影響へ変換する

技術的な説明	業務視点の説明
WANポートを監視する	拠点間通信が停止する原因を早期に検知する
回線使用率を監視する	業務影響が出る前に帯域不足の兆候を把握する
冗長系を監視する	通信継続中でも次の障害に耐えられない状態を検知する
監視基盤を冗長化する	障害発生時にも検知・通知する仕組みを維持する
分散監視する	WAN障害時にも拠点内部の状態を把握しやすくする

顧客への説明例

「今回の監視設計では、単にネットワーク機器が停止したかどうかだけではなく、回線の性能劣化や冗長構成の片系障害も検知できるようにします。また、拠点間回線が停止した際に大量の誤ったアラートが発生しないよう、機器間の依存関係も設定します。障害を検知した後は、重要度に応じて運用担当へ通知し、必要に応じて設計担当や保守ベンダーへエスカレーションできる運用まで含めて設計します。」

上流工程では、 「何を監視するか」より「なぜ監視するのか」 を説明できることが重要です。

監視設計で使われる英語表現

よく使う単語

英語	意味
Monitoring	監視
Monitoring architecture	監視アーキテクチャ
Monitoring target	監視対象
Polling	定期的な情報取得
Collector	監視データ収集機能・収集サーバー
Threshold	しきい値
Baseline	通常状態の基準値
Alert	アラート
Severity	重要度
Dependency	依存関係
Alert suppression	アラート抑止
Maintenance window	メンテナンス時間帯
Escalation	エスカレーション
Health check	正常性確認
Failover	冗長系への切り替え

設計レビューで使える表現

What conditions should trigger a critical alert?
どの条件で重大アラートを発生させるべきですか？

The monitoring system should detect a single-link failure before service is completely interrupted.
サービスが完全停止する前に、片系リンク障害を検知できるようにする必要があります。

We need to define dependencies to avoid an alert storm during a WAN outage.
WAN障害時の大量アラートを防ぐため、依存関係を定義する必要があります。

How will the monitoring platform itself be monitored?
監視基盤自体はどのように監視しますか？

理解度チェック

上級編では、用語暗記ではなく、設計判断ができるかを確認します。

問題1． 監視設計として最も適切な考え方はどれですか。

監視製品で取得できる項目をすべて監視する
すべての機器へ同じしきい値を設定する
検知したい障害と業務影響から監視項目を決める
pingが成功していれば正常と判断する

解答を見る

正解：C

監視できる項目から考えるのではなく、業務上検知すべき異常から監視対象・方式を決めます。

問題2． FWを2台で冗長化しています。 1台が故障しましたが、もう1台へ切り替わり通信は継続しています。適切な監視上の扱いはどれですか。

通信できているため正常
冗長性を失った状態として警告する
監視対象から除外する
両系停止するまで通知しない

解答を見る

正解：B

現在の通信は継続していても、次の障害に耐えられない状態なので早期対応が必要です。

問題3． 本社監視サーバーから支店内20台を監視しています。 WAN回線が停止し、20台すべてがDownになりました。改善方法を1つ挙げてください。

解答例を見る

WAN回線や支店ルーターを上位の依存対象として設定し、 WAN障害時には配下20台の通知を抑止します。

必要であれば支店側へCollectorを配置し、 WAN断時にも支店内部の監視を継続できる構成を検討します。

問題4． CPU使用率が瞬間的に90％になっただけで毎回重大アラートが発生します。どのような改善が考えられますか。

解答例を見る

継続時間を条件へ加える
連続回数を条件へ加える
通常時のベースラインを確認する
発報条件と復旧条件を分ける

問題5． 「アラートが1件もないためネットワークは正常である」と断定できない理由を説明してください。

解答を見る

監視サーバー、監視プロセス、通知経路、監視ネットワークなどが停止している可能性があるためです。

監視基盤自体の正常性も確認できる設計が必要です。

実践演習：複数拠点ネットワークの監視設計を作る

あなたは、次の企業ネットワーク更改で監視設計を担当することになりました。

ネットワーク要件

東京本社と大阪支店がある
本社・支店間はWAN回線で接続する
インターネット出口は本社にある
本社FWは2台で冗長化する
本社・支店ともスイッチを複数台利用する
社内DNS・DHCPを利用する
ネットワーク障害は可能な限り早く検知したい
夜間の重大障害は担当者へ通知する
不要なアラートは極力減らしたい

課題1．監視対象を洗い出す

監視すべき対象・状態を10個以上挙げてください。

1．＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
2．＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
3．＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
4．＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
5．＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

解答例を見る

本社FWの死活
本社FWのHA状態
インターネットWANポート
インターネット外部到達性
本社・大阪間WAN状態
WAN遅延・パケットロス
本社コアスイッチ死活
大阪スイッチ死活
重要インターフェース状態
インターフェースエラー
CPU・メモリー・温度
ルーティング隣接状態
DNS名前解決
DHCP払い出し・プール状況
監視基盤自身の正常性

課題2．監視方式を決める

次の項目へ適切な監視方式を割り当ててください。

監視項目	監視方式
ルーター死活	＿＿＿＿＿＿
インターフェース使用率	＿＿＿＿＿＿
リンクDownイベント	＿＿＿＿＿＿
DNS名前解決	＿＿＿＿＿＿
クラウド型機器の詳細情報	＿＿＿＿＿＿

解答例を見る

ルーター死活：ICMP
インターフェース使用率：SNMP等
リンクDown：Trap／イベント通知＋定期監視
DNS：実際のDNS問い合わせ
クラウド型機器：API等

課題3．WAN障害時のアラートを設計する

大阪支店とのWAN回線が停止した場合、本社監視サーバーから大阪の機器がすべてDownになります。

大量アラートを防ぐ設計を考えてください。

WAN回線を＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿。

解答例を見る

WAN回線または大阪拠点ルーターを上位の依存対象として設定し、 WAN障害時には配下スイッチなどの通知を抑止します。

さらに高い監視継続性が必要であれば、大阪側へCollectorを配置する分散監視を検討します。

課題4．監視設計表を作成する

次の形式で最低5項目の監視設計を作成してください。

対象	監視項目	方式	間隔	判定条件	重要度	一次対応
＿＿＿＿	＿＿＿＿	＿＿＿＿	＿＿＿＿	＿＿＿＿	＿＿＿＿	＿＿＿＿
＿＿＿＿	＿＿＿＿	＿＿＿＿	＿＿＿＿	＿＿＿＿	＿＿＿＿	＿＿＿＿
＿＿＿＿	＿＿＿＿	＿＿＿＿	＿＿＿＿	＿＿＿＿	＿＿＿＿	＿＿＿＿

解答例を見る

対象	項目	方式	間隔	条件例	重要度	一次対応
FW-01	死活	ICMP	1分	3回連続失敗	警告	HA状態確認
FW-01/02	HA状態	SNMP/API	1分	片系異常	警告	Standby状態確認
WAN	到達性	ICMP等	1分	連続失敗	重大	回線・対向確認
DNS	名前解決	DNS Query	1分	3回連続失敗	重大	DNS・経路確認
Monitoring	監視処理	自己＋外部監視	1分	処理停止	重大	監視基盤確認