死活監視とは、ITシステムが稼働しているかどうかを監視する方法の一つで、外部から継続的にシステムは『生きているか』を監視するような方法です。英語ではalive monitoringと表記されます。
例えば、一定間隔で監視対象のシステムに対して（サーバ等に対してですね）信号を送信して、反応を見るといった方法を採ります。
システムが生きているのならば、反応を返すように設定しておけば、反応が返ってこない＝システムが生きていないという事ができるのです。
一昔前のゲーム風に言うならば、話しかけたにもかかわらず返事がないといったイメージで、「返事がない、ただのしかばねのようだ」みたいな感じです。
■なぜ死活監視なのか
さて、どうして継続的に監視をしないといけないのでしょうか？その理由は、トラブルの発生がいつになるかが読めないためです。
あらかじめトラブル発生がわかっていれば、予防保全などを行い、トラブルなど発生させにくくすると言った対応が可能ですが、何処まで対応してもトラブル発生の確率をゼロにすることはできません。
あらかじめトラブル発生がわかっていれば、予防保全などを行い、トラブルなど発生させにくくすると言った対応が可能ですが、何処まで対応してもトラブル発生の確率をゼロにすることはできません。
その為、常に監視を行っておき、トラブルの発生を迅速に把握するというニーズがあるのですね。
その結果、異常検知の初期段階でアラートを出せますし、サービスレベル維持が比較的容易で合うrと言った利点があります。
ただし、次のような 限界点があるため注意が必要です。
また、通信経路の問題で「誤検知」もありえます。「生きてるよ！」と返してきたけど、ネットワークが遅く、そのシグナルが届かないで落ちていると誤認してしまうケースもあるのです。
■ 死活監視が使われる具体的な場面
さて、上記のような死活監視ですが、以下のような状況で活躍します
- Webサーバやメールサーバなどの常時稼働が求められるシステム
- 社内ネットワーク機器（ルーター、スイッチなど）
- IoT機器やセンサーネットワークの健全性確認
- クラウド上のマイクロサービス群
これらのサービスは基本的に止まってはいけない類のサービスとなります。
そのため、ECサイト運営企業は、24時間の死活監視を行い、「サイトが落ちた瞬間」に担当者へアラートが飛ぶようにしておくのです。その結果、復旧までの時間が短時間となり売上の機会損失を最小限に抑えることができるのです。
（担当者が気の毒だと思った「感性の鋭い」あなたは、動いているのが当たり前ではなく、当たり前を守っているITエンジニアをぜひ尊重してあげてくださいね。）
そのため、ECサイト運営企業は、24時間の死活監視を行い、「サイトが落ちた瞬間」に担当者へアラートが飛ぶようにしておくのです。その結果、復旧までの時間が短時間となり売上の機会損失を最小限に抑えることができるのです。
（担当者が気の毒だと思った「感性の鋭い」あなたは、動いているのが当たり前ではなく、当たり前を守っているITエンジニアをぜひ尊重してあげてくださいね。）
■ 死活監視のメリットと限界
死活監視には明確なメリットがあります。それは、シンプルで導入が容易（Pingなどで対応可能）ということです。
※pingは標準機能ですから、特にコストを掛けずに実装可能です。（ping（ピン）とは、「そっちにいる？」とパソコンに声をかけて、返事があるかを確かめるしくみです。）
※pingは標準機能ですから、特にコストを掛けずに実装可能です。（ping（ピン）とは、「そっちにいる？」とパソコンに声をかけて、返事があるかを確かめるしくみです。）
その結果、異常検知の初期段階でアラートを出せますし、サービスレベル維持が比較的容易で合うrと言った利点があります。
ただし、次のような 限界点があるため注意が必要です。
■ゾンビなどに気をつけろ
死活監視では、表面上生きているように見えるが実際には処理不能というゾンビみたいなケースには弱いです。
例えば、アクセスが集中しているなどの理由で実際には使い物にならない程度に処理が遅延しているケースでも、「生きてるよ！」と返してきますので、検知が難しいです。
（この対応にはアプリケーションレベルでの監視が別途必要）
例えば、アクセスが集中しているなどの理由で実際には使い物にならない程度に処理が遅延しているケースでも、「生きてるよ！」と返してきますので、検知が難しいです。
（この対応にはアプリケーションレベルでの監視が別途必要）
また、通信経路の問題で「誤検知」もありえます。「生きてるよ！」と返してきたけど、ネットワークが遅く、そのシグナルが届かないで落ちていると誤認してしまうケースもあるのです。
■死活監視とその他の監視手法との違い
- 死活監視（alive monitoring） システムが生きているかを見る
- ハートビート監視 クラスタ構成での相互監視。タイムアウトで障害検知
- ポーリング監視 一定間隔で情報を取得して状態確認
- エージェント監視 端末に監視ツールをインストールし、内部情報もチェック
ざっくりとまとめるとこんな感じになります。
例えばネットショップが止まれば、担当者にメールなどで「サーバが応答していません」と通知が届いたりします。（担当者から刷ると最悪の瞬間ですよね）
この連絡を受けた担当者はすぐに原因究明を行い、再起動や復旧対応を行っていくのです。原因究明にはログの解析を行ったり、プロセスの再起動を実施し、復旧を図ります。
このように死活監視は、監視するだけではなく
監視→検知→通知→対応→再検証
という一連のサイクルの起点となるのです。
単なるPing応答の有無だけでなく、CPU使用率やレスポンスタイムの変化などから予兆を検出すると言ったアプローチが取られつつあるのです。（予兆が出たら嫌ですね。予兆の段階で何か作業をして障害発生を食い止められればいいのですが・・・）
いずれにしても、反応があるけど正常じゃないという状況を検出しやすくなってきたのは良いことですし、利便性や安定性はそれだけで大きな価値がありますからね。
■死活監視のアラートと対応プロセス
死活監視でシステムが反応しない時には、すぐにアラートを出すように作っていきます。例えばネットショップが止まれば、担当者にメールなどで「サーバが応答していません」と通知が届いたりします。（担当者から刷ると最悪の瞬間ですよね）
この連絡を受けた担当者はすぐに原因究明を行い、再起動や復旧対応を行っていくのです。原因究明にはログの解析を行ったり、プロセスの再起動を実施し、復旧を図ります。
このように死活監視は、監視するだけではなく
監視→検知→通知→対応→再検証
という一連のサイクルの起点となるのです。
■AI時代の死活監視（アラートの意味づけ）
近年ではAIを活用して異常検知と死活監視が統合しつつあります。単なるPing応答の有無だけでなく、CPU使用率やレスポンスタイムの変化などから予兆を検出すると言ったアプローチが取られつつあるのです。（予兆が出たら嫌ですね。予兆の段階で何か作業をして障害発生を食い止められればいいのですが・・・）
いずれにしても、反応があるけど正常じゃないという状況を検出しやすくなってきたのは良いことですし、利便性や安定性はそれだけで大きな価値がありますからね。
■まんがの解説
上記の漫画では、死活監視の本質を書いてみました。
「反応さえすれば監視を抜けられる」という仕組みは、まさに死活監視の弱点そのものです。
表面的な生存確認では、「ちゃんと働いているか」まではわからないという現場のジレンマを書いてみました。
表面的な生存確認では、「ちゃんと働いているか」まではわからないという現場のジレンマを書いてみました。
初出：2013/07/13
更新：2025/11/05
