こんにちは。廣木です。
ネットワーク運用を担当していると、「障害が起きていたのに気づくのが遅れた」という経験はありませんか?
ネットワーク障害は、業務停止やサービス品質低下といったビジネスリスクを引き起こします。こうしたリスクを最小化するためには、障害を即座に検知し、通知する仕組みが不可欠です。
CatoのLink Health Rulesを利用すると、「Connectivity(接続性)」や「Quality(品質)」状態を監視し、通知を行うことができます。
今回、前編・後編の2記事に分けてLink Health Rulesの機能をご紹介します。
前編となる本記事では「Connectivity Health Rule(接続性監視)」にフォーカスし、その概要と活用方法を解説します!
次回の後編では「Quality Health Rule(品質監視)」について投稿予定です。
Link Health Ruleとは?
「Connectivity Health Rule」についてご紹介する前に、まずは「Link Health Rule」の機能概要からご説明します。
Link Health Ruleには2種類あります。Connectivityは「接続性」、Qualityは「品質」を対象とし監視を行い、ルールに従って通知を行うことでネットワークの安定運用を支援します。
Link Health Ruleの種類
- Connectivity Health Rules
接続性(Connectivity)を監視し、接続性に関するイベントをトリガーに通知を行います。 - Quality Health Rules
品質指標(Quality)を監視し、設定した閾値を超えた場合に通知します。
CatoのBest Practiceでは、これらの設定を行うことが推奨されています。
ただし、具体的な設定値は定義されていないため、各企業様の環境に応じて設定する必要があります。
Connectivity Health Rulesとは?
それでは「Connectivity Health Rule」についてのご紹介です。
まずは、具体的に何を監視できるのか?を確認してみましょう。
Connectivity Health Rulesでは表1にある接続性に関するイベントの発生状況を監視します。
表1:Connectivity Health Rulesで選択可能なイベント一覧
| No | イベントの種類 | 説明 |
| 1 | Failover | プライマリリンクとセカンダリリンク間、またはその逆のフェイルオーバー |
| 2 | Active WAN Link Disconnect | アクティブ状態のリンクの切断 |
| 3 | Passive WAN Link Disconnect | パッシブ状態またはラスト リゾート ステートのリンクの切断 |
| 4 | Socket Failover | HA 構成のソケット間のフェイルオーバー |
| 5 | Internet as a Transport | インターネット(Cato Cloudではない)を介してデータを転送しているリンクの切断 |
選択するイベントは構成により異なります。
例えば、Socketがシングル構成でWANリンクも非冗長の場合は 「Active WAN Link Disconnect 」を選択するのが一般的です。また、SocketがHA構成の場合やWANリンクが冗長構成の場合は、必要に応じてさらに「Failover」「Socket Failover」「Passive WAN Link Disconnect 」を追加することで、障害発生時の状況をより正確に把握することができます。
なお、複数イベントを選択した場合は「OR」の関係が成り立ちます。つまり、選択したイベントのうちいずれかのイベントが発生したら通知が行われます。
Connectivity Health Rulesの設定例
次に、具体的な設定例を見ていきます。
※本記事でご紹介するのはあくまで一般的な設定例です。実際の設定は、各企業の環境に応じて設定いただきます。
今回はこんなシナリオを想定して設定を行っていきます。
- 拠点「SCSK-Demo-Site」の「Active WAN Link Disconnect」イベントをトリガーに管理者へ通知する
設定方法
2025年11月現在、Connectivity Health Rulesの設定項目は以下の通りです。*は任意の設定項目で、その他は必須です。
※実際にはTrackingも任意ですが、通知先を指定する項目なので基本的には設定必須とお考えください。
表3:Connectivity Health Rulesの設定項目
| No | 設定項目 | 設定内容 | |
| 1 | General | Name | 任意のルール名を入力 |
| 2 | Source | – | 監視対象をSite/Group/System Groupから選択 |
| 3 | Condition | On Event | トリガーとするイベントを選択 |
| 4 | Alert Upon* | 通知の条件を設定 | |
| 5 | Tracking | Frequency | Immediate/Hourly/Daily/Weekly |
| 6 | Send notification to | Mailing List/SubscriptionGroup/Webhookから選択 | |
設定値はこちらです。任意の設定項目であるAlert Uponは未設定としています。
- General
- Name:Test
- Source
- Site:SCSK-Demo-Site
- Condition
- On Event:Active WAN Link Disconnect
- Alert Upon:–
- Tracking
- Frequency:Immediate(即時)
- Send notification to:Mailing List(All Admin)
設定を行うと、下図のような表示になります。
通知タイミング
この時、通知のタイミングをまとめるとこうなります。
通知タイミング
- リンクダウン検知後、2.5 分以上ダウン状態を継続している場合にDisconnectイベントを生成し通知
- リンクダウン検知後、2.5分以内に再接続があった場合に、Reconnectイベントを生成し通知
- Reconnectイベントは、接続が復元されてから最大 30 秒の遅延で検出される場合があります。
- リンクアップ検知後、30 秒間アップ状態を継続していることを確認後 Connected イベントを生成し通知
POINT
この結果から、押さえておきたいポイントは2つあります。
1. 即時通知されない
Catoではリンクダウン後、2.5分間の評価期間を設けています。この間に再接続があれば「瞬断」扱いとなり、Disconnectイベントは生成されません。そのため、リンクダウンを検知しても即時で通知はされない仕様となっています。
Catoのイベント生成ルール
- リンクダウン検知 → 「Session Disconnected」ジョブ開始(トリガー時間:2.5分)
- この時間内に再接続が発生した場合:
- 同じPoPへ再接続 → 「Session Disconnected」ジョブ開始ジョブキャンセル → 「Session Reconnect」ジョブ開始(30秒)
- 異なるPoPへ再接続 → 「Session Disconnected」ジョブ開始ジョブキャンセル → 「Session Changed PoP」ジョブ開始(5秒)
2. 切断時だけでなく復旧時も通知される
2025年8月の機能拡張により、復旧イベント(Connected・Reconnected・Changed PoP)も通知される仕様に変更されています。
次に説明するオプション設定で通知回数を調整する際には、この点に注意が必要です。復旧イベントも回数にカウントされるため、設定値は慎重に検討することを推奨します。
オプション
それでは、瞬断を検知し即時通知したい場合や、切断/復旧時の通知が大量に発生してしまっている場合はどうすればよいでしょうか?
このようなケースでは、オプション機能を利用し通知条件をカスタマイズすることで、環境やご要件に応じてチューニングを行うことができます!
なお、この設定は先ほどご紹介した設定項目の中で任意となっていた Alert Uponで行います。
リンクダウン期間の調整
瞬断を検知し即時通知したい場合は、Alert Uponでリンクダウン時間を設定します。
例えば、「1分間リンクダウン状態が継続した場合に通知したい」という場合は、リンクダウン期間を1分に設定します。

この時、通知のタイミングをまとめるとこうなります。
通知タイミング
- リンクダウンを検知後、1分間リンクダウン状態を継続している場合にDisconnectイベントを生成し通知
- リンクダウンを検知後、2.5 分以内に再接続された場合Reconnectのイベントは生成されない
- リンクアップを検知後、30 秒間アップ状態を継続していることを確認後 Connected イベントを生成し通知
このリンクダウン期間は、極端に短い期間を設定すると通知が大量に発生する可能性があるので注意が必要です。
通知回数の調整
また、切断/復旧時の通知が大量に発生してしまっている場合はAlert Uponでイベント発生回数を設定します。
例えば、「1時間に4回イベントが発生したら」という条件を設定することで、通知回数を調整できます。

この回数は、実際のイベント発生状況を確認しながら、適切な値を設定することを推奨します。
また、繰り返しになりますが復旧イベント(Connected・Reconnected・Changed PoP)も回数にカウントされるため、設定時には注意が必要です。
さいごに
今回は、Link Health Rulesの中でもConnectivity Health Rulesについてご紹介しました。
障害を迅速に検知し、通知する仕組みを構築することで、ネットワーク運用の安定性を高めることができます。
ぜひ本記事を参考に、貴社の運用にお役立ていただければ幸いです!

