死活監視とは？
仕組み・監視方式・
ツールの選び方

死活監視とは

死活監視（Alive Monitoring / Availability Monitoring）とは、サーバーやネットワーク機器、サービスが「生きているか・死んでいるか」を継続的に確認する監視のことです。代表例は Ping（ICMP）による応答確認で、「監視対象に信号を送り、応答が返ってくれば正常、返らなければ異常」というシンプルな原理で動きます。

シンプルであるがゆえに軽視されがちですが、サーバー監視の全体像の中で死活監視は最初に異常を知らせてくれる砦です。ECサイトが落ちていることに「お客様からの電話で気づいた」、社内システムの停止に「月曜の朝、出社した社員の報告で気づいた」——こうした事態を防ぐ最低ラインが死活監視であり、その上にリソース監視（CPU・メモリ）、ログ監視、外形監視が積み上がります。

テクノスフィアは受託でお客様のシステムを支えるかたわら、サーバー監視システム TechnoAlive を自社開発しています。社内には20年以上の開発・運用キャリアを持つエンジニアが在籍しており、以下、教科書的な定義ではなく「運用してみると何につまずくか」を軸に書きます。

アクティブ監視とパッシブ監視

死活監視の実現方法は、大きく2つに分類できます。

• アクティブ監視（能動監視）：監視サーバー側から定期的にPingやHTTPリクエストを送り、応答を確認する方式。「応答がない＝異常」と判断しやすく、本記事で扱う方式の大半がこちらです
• パッシブ監視（受動監視）：監視対象側から送られてくるハートビート・SNMPトラップ・ログを受け取って状態を判断する方式。「来るはずの信号が来ない」ことで異常を検知します

実務では両者を組み合わせます。アクティブ監視は導入が容易な反面「監視サーバーから見える範囲」しか確認できず、パッシブ監視はNAT越えやファイアウォール内の機器にも使える反面、「信号が来ない理由」が対象の障害なのか経路の問題なのか切り分けにくい、という補完関係にあるためです。

死活監視で「できること」と「できないこと」

死活監視を入れたのに障害に気づけなかった——というクレームの多くは、死活監視が本来検知できないものを検知できると思い込んでいたことが原因です。先に守備範囲の境界線を引いておきます。

できること

• サーバー・機器の停止検知：電源断、OSクラッシュ、インスタンス停止、ネットワーク断を数分以内に検知
• サービスポートの停止検知：Webサーバーやデータベースのプロセスダウンを、ポート応答の有無で検知
• 復旧の確認：障害対応後、応答が戻ったことを客観的に確認
• 稼働率（アップタイム）の記録：SLA報告や障害振り返りの根拠データを蓄積

できないこと（死活監視だけでは不十分なケース）

つまり死活監視は「止まった」ことは検知できても、「壊れかけている」「遅い」「間違った動きをしている」は検知できません。だからこそ現在の監視ツールの多くは、死活監視を入口にリソース監視・外形監視・ログ監視を組み合わせた統合監視へと発展しています。

監視方式の技術解説：Ping・TCP・HTTP(S)・エージェント型

「死活監視」と一口に言っても、どのレイヤーで生死を確認するかで検知できる障害はまったく異なります。主要4方式を、検知範囲と誤検知パターンまで含めて整理します。

1. ICMP Ping監視（L3：ネットワーク層）

ICMP Echo Request を送信し、Echo Reply が返るかを確認する最も古典的な方式です。OSのネットワークスタックが応答するため、「マシンとネットワーク経路が生きているか」だけを確認します。負荷が極めて軽く、大量のホストに対して高頻度で実行できるのが利点です。

注意すべきは、Pingの成否とサービスの生死は独立だという点です。Apacheが落ちていてもPingは返りますし、逆にクラウドのセキュリティグループやファイアウォールでICMPを許可していない環境では、サーバーが完全に正常でもPingは全滅します。AWSでは新規作成したセキュリティグループはインバウンドを一切許可しないため、ICMPも明示的な許可が必要です。「Ping監視を設定したら全台ダウン表示になった」は初心者が一度は踏む罠です。

2. TCPポート監視（L4：トランスポート層）

対象ポート（HTTP:80、HTTPS:443、SSH:22、MySQL:3306 など）へTCP接続を試み、3ウェイハンドシェイクが成立するかを確認します。「そのポートでプロセスがLISTENしているか」まで確認できるため、Pingより一段深い監視です。ICMPが遮断された環境でも、公開ポートさえあれば死活確認の代替になります。

限界もあります。TCP接続の受付はOSカーネルが行うため、アプリケーションがデッドロックやGC停止でハングしていても、接続自体は成立してしまうことがあります。「ポートは開いているのに全リクエストがタイムアウトする」という障害は、ポート監視では検知できません。

3. HTTP(S)エンドポイント監視（L7：アプリケーション層）

実際にHTTP(S)リクエストを送り、ステータスコード・応答時間・応答本文まで検証する方式です。「200 OKが返るか」に加えて「応答本文に特定の文字列が含まれるか」「応答が3秒以内か」まで確認でき、ユーザー体験に最も近い死活監視と言えます。外部拠点から本番URLに対して行う場合は「外形監視」と呼ばれます。

実務では、アプリケーション側にヘルスチェック専用エンドポイントを実装しておくのが定石です。トップページを監視対象にすると、CDNキャッシュが効いて「アプリが死んでいるのに200が返る」ことがあるためです。依存するDBやキャッシュへの疎通まで確認して返す実装にしておくと、1本のURLでシステムの本質的な健全性を確認できます。

# FastAPIでのヘルスチェックエンドポイント実装例
# DBへの疎通まで確認し、異常時は503を返す
# ※擬似コード（db/redis等の初期化は省略）
@app.get("/healthz")
async def healthz():
    try:
        await db.execute("SELECT 1")   # DB疎通確認
        await redis.ping()             # キャッシュ疎通確認
    except Exception as e:
        return JSONResponse(
            {"status": "ng", "detail": str(e)},
            status_code=503            # 監視ツールが異常と判定できるコードを返す
        )
    return {"status": "ok"}

4. エージェント型 vs エージェントレス

ここまでの3方式はすべて「外から確認する」エージェントレス監視です。これに対し、監視対象サーバーに常駐プログラム（エージェント）を入れて内部から情報を送るエージェント型監視があります。

重要なのは「エージェント型だけに寄せると、死活監視が弱くなる」という点です。サーバーが完全に停止するとエージェントもろとも沈黙するため、エージェント型監視での停止検知は「メトリクスの途絶」という間接的なシグナルに頼ることになります。死活の一次判定はエージェントレス、詳細情報はエージェント、という併用が堅実です。弊社のTechnoAliveがICMP Ping・SSH・HTTP/HTTPSの監視を死活判定の基本に据えているのも、この理由からです。

実務の落とし穴と誤検知パターン

死活監視の設計でつまずくポイントは、方式の選択よりむしろ「運用してから気づく落とし穴」に集中しています。弊社が受託運用で実際に遭遇してきた代表例を挙げます。

落とし穴1：監視サーバー自体の死活

最大の盲点です。監視サーバーが停止すると、アラートが一切飛ばなくなり「無音＝すべて正常」に見えます。オンプレのZabbixサーバーが週末に落ちていて、月曜に本番障害とまとめて発覚した——という事故は業界の定番ネタと言っていいほど頻出します。対策は3つです。

• 監視サーバーを監視対象と分離する：別ネットワーク・別リージョン・別クラウドに配置し、共倒れを防ぐ
• 相互監視：監視サーバー自身を外部SaaSなど別系統で監視する
• デッドマン方式：「監視システムから定期的にハートビートが届き続ける」ことを別システムで確認し、途絶したら警報を上げる

落とし穴2：単一拠点からの監視による経路誤検知

監視サーバーが1拠点しかないと、対象サーバーの障害と、監視サーバー〜対象間のネットワーク経路の障害を区別できません。実際には対象は正常なのに、途中の経路の瞬断で「ダウン」と誤検知するケースです。外形監視を複数拠点から行う、社内とクラウドの2系統から監視する、といった多視点化が対策になります。少なくとも「1回の失敗で即アラート」は避けてください。リトライ設計（後述）なしの死活監視は誤報製造機になります。

落とし穴3：プロセス生存とサービス応答の乖離

「プロセス監視でhttpdの生存は確認している」という現場ほど危険です。プロセスは存在するがリクエストを一切処理できない状態——コネクションプール枯渇、デッドロック、ディスクフルによる書き込み待ち——は普通に起こります。プロセスの存在確認とサービスの応答確認は別物であり、最終的な正常性判定はL7（HTTP監視・ヘルスチェックエンドポイント）で行うべきです。

落とし穴4：DNSと証明書という「周辺」の死角

IPアドレス直指定で監視していると、DNSレコードの設定ミスや期限切れで「監視は全緑なのにユーザーはアクセス不能」になります。逆にFQDNで監視していれば、DNS障害も含めてユーザー視点の到達性を確認できます。同様にTLS証明書の期限切れも、ポート監視では検知できない典型的な死角です。HTTPS監視には証明書の有効期限チェック（残り14日で警告など）を含めておきましょう。

誤検知パターン早見表

通知設計の実務：アラート疲れを防ぐ

監視の失敗は「検知できなかった」より「検知したのに誰も反応しなかった」ことで起こるほうが多い、というのが運用現場の実感です。1日に何十件も飛ぶ重要度不明のアラートは数週間で「読まれない通知」になり、その中に埋もれた本物の障害が見逃されます。いわゆるアラート疲れ（Alert Fatigue）です。

原則1：アラートは「行動が必要なもの」だけに絞る

通知設計の出発点は、すべてのイベントを重大度で分類し、即時通知するのは「人がいま行動すべきもの」だけに絞ることです。即時に人を起こすのは本番の死活NGとDB接続不能だけ。ディスク80%超えや証明書期限14日前はチャットに流して営業時間内に拾う。再起動完了やバッチ正常終了は通知せずダッシュボードに残す——この3段階に落とすだけで通知量は体感で1/10になります。

運用開始後も定期的に「先月鳴ったアラートのうち、実際に対応が必要だったのは何件か」を棚卸しし、対応不要だったものは閾値変更・Info降格・監視削除のいずれかで潰していきます。アラートの精度はチューニングし続けるもので、初期設定のまま放置された監視は必ず腐ります。

原則2：リトライとエスカレーションを設計する

誤検知対策の基本は「1分間隔で監視し、3回連続失敗で初めて障害と判定する」といった連続失敗回数による判定です。検知は数分遅くなりますが、瞬断由来のノイズが激減し、アラートの信頼性が上がります。逆に言えば、検知速度が最優先のシステムでは間隔を短くしてリトライ回数を確保する必要があり、監視間隔・リトライ回数・許容検知遅延の3つはセットで設計します。

あわせて、一次対応者が反応できない場合に備えたエスカレーションを決めておきます。「Criticalの通知後15分間、誰も対応表明しなければ二次担当と責任者へ再通知」というルールを、PagerDutyやOpsgenie、国産ならTechnoAliveやMackerelのアラート通知連携など、エスカレーションを持つツールで自動化しておくと、深夜の見逃しを仕組みで防げます。担当者の善意や気合いに頼る運用は必ず破綻します。

原則3：通知経路を冗長化する

通知先がSlackだけ、という構成は意外と危険です。Slack自体の障害、ワークスペースの認証切れ、Webhook URLの失効——通知経路の障害はアラートの完全な沈黙を意味します。Critical通知はチャットとメールなど2経路以上に送り、可能であれば依存するインフラが重ならない組み合わせ（例：Slack＋携帯キャリアメール）を選びます。通知のテスト送信を月次の定期作業に組み込み、「いざという時に届かない」を事前に検出するのも地味ながら効果の高い運用です。

ツールの選び方：OSS自前運用 vs SaaS

死活監視を実現するツールは、大きく「OSSを自前で運用する」「SaaSを利用する」「クラウド純正サービスを使う」の3系統に分かれます。

判断軸は「監視対象数 × 運用体制」

OSSはソフトウェアこそ無料ですが、実際には監視サーバーのインフラ費用＋構築工数＋継続的な保守工数がかかります。弊社の経験則では、Zabbix等の監視基盤をゼロから構築すると設計込みで数十時間規模、稼働後もバージョンアップ・監視設定の追加変更・監視サーバー自体の面倒見で月数時間の工数が発生します。エンジニアの時間単価で換算すると、これは決して「無料」ではありません。

一方SaaSはホスト数課金です。例えば10台をMackerelのスタンダードホストで監視すると月2万円強（2026年7月時点の税込単価2,180円×10台）。月数時間の保守工数より安いため、監視対象が数台〜数十台で専任担当を置けない組織では、SaaSが総コストで勝つことがほとんどです。逆に監視対象が数百台〜数千台になるとSaaS費用が月数十万〜数百万円に膨らみ、専任チームを抱えてOSSを運用する方が安くなる損益分岐を超えます。

• 〜数十台・専任なし：SaaS または監視込みの運用サービスが第一候補
• 数百台〜・専任あり：OSS自前運用のコストメリットが出始める
• 要件が特殊（閉域網・独自プロトコル・カスタム監視）：規模によらずOSSや個別開発が候補に

主要ツール比較

ライセンス・料金はすべて各公式サイトで確認したもので、2026年7月時点の情報です（料金は改定されることがあるため、導入時は必ず公式サイトをご確認ください）。

なお「まず無料で外形監視だけ」であれば、Uptime Kuma（セルフホストOSS）やUptimeRobotの無料枠でHTTP監視を始める手もあります。ただし通知の冗長化やエスカレーションはこの層のツールでは弱いため、本記事で述べた通知設計が必要になった時点が上位ツールへの乗り換えどきです。

クラウドサーバー監視の観点：CloudWatchとの住み分け

「クラウドを使っているなら純正の監視（AWSならCloudWatch、AzureならAzure Monitor）だけで足りるのでは？」という質問をよくいただきます。答えは「リソース監視は足りる。死活・外形監視の視点では足りないことが多い」です。

クラウド純正監視が得意なこと

CloudWatchはEC2のCPU使用率・ネットワークI/OなどをハイパーバイザーレベルでAPI一つ取得でき、オートスケーリングや自動復旧のトリガーとも直結しています。AWSリソース（RDS、ELB、Lambda等）の内部メトリクスはCloudWatchでしか取れないものも多く、AWS内のリソース監視については純正が第一選択です。

純正だけでは埋まらない3つの穴

1. OS内部のメトリクスは標準では取れない：メモリ使用率・ディスク使用率はハイパーバイザーから見えないため、CloudWatch Agentの導入（＝エージェント型監視の運用）が別途必要になります
2. 「外から見えるか」の視点がない：CloudWatchはAWSの内側からの監視です。DNS設定ミス・証明書失効・経路障害など「ユーザーからは繋がらないのにメトリクスは正常」という障害は、外部からの死活・外形監視（CloudWatch Syntheticsを別途構成するか、外部ツール）でしか捉えられません
3. マルチクラウドで監視が分裂する：AWSとOCI、Azureを併用すると、監視画面・アラート設定・課金がクラウドごとにバラバラになります。障害時に複数コンソールを行き来する運用は、対応速度を確実に落とします

実務的な整理としては、「クラウド純正＝そのクラウド内部のリソースメトリクスと自動復旧」「横断ツール＝死活監視・外形監視・複数環境の一元化」という住み分けが素直です。弊社でもOCIとAWSが混在するお客様環境では、各クラウドの純正メトリクスを残しつつ、死活監視と通知の一元化をTechnoAliveやSaaSツールで束ねる構成を採ることが多くあります。クラウド移行そのものを検討中の方は クラウド移行支援サービス も併せてご覧ください。

まとめ

監視は「入れて終わり」ではなく、アラートの棚卸しと閾値チューニングを続けてはじめて機能します。まずは自社の監視が「止まったことに最速で気づける状態か」「鳴ったアラートに人が反応しているか」の2点から点検してみてください。

よくある質問（FAQ）