# 死活監視とは？仕組み・監視方式・ツールの選び方を実務目線で解説｜株式会社テクノスフィア > 死活監視の定義から、ICMP Ping・TCPポート・HTTP(S)・エージェント型それぞれの検知範囲と誤検知パターン、アラート疲れを防ぐ通知設計、OSS（Zabbix・Nagios・Prometheus）とSaaS（Mackerel・Datadog）の損益分岐まで。サーバー監視システムを自社開発するテクノスフィアが実務目線で解説します。 URL: https://technosphere.co.jp/blog/server-monitoring-guide ** 目次 1. 死活監視とは 2. 死活監視で「できること」と「できないこと」 3. 監視方式の技術解説：Ping・TCP・HTTP(S)・エージェント型 4. 実務の落とし穴と誤検知パターン 5. 通知設計の実務：アラート疲れを防ぐ 6. ツールの選び方：OSS自前運用 vs SaaS 7. クラウドサーバー監視の観点：CloudWatchとの住み分け 8. まとめ ## 死活監視とは **死活監視（Alive Monitoring / Availability Monitoring）**とは、サーバーやネットワーク機器、サービスが「生きているか・死んでいるか」を継続的に確認する監視のことです。代表例は Ping（ICMP）による応答確認で、「監視対象に信号を送り、応答が返ってくれば正常、返らなければ異常」というシンプルな原理で動きます。 シンプルであるがゆえに軽視されがちですが、サーバー監視の全体像の中で死活監視は**最初に異常を知らせてくれる砦**です。ECサイトが落ちていることに「お客様からの電話で気づいた」、社内システムの停止に「月曜の朝、出社した社員の報告で気づいた」——こうした事態を防ぐ最低ラインが死活監視であり、その上にリソース監視（CPU・メモリ）、ログ監視、外形監視が積み上がります。 テクノスフィアは受託でお客様のシステムを支えるかたわら、サーバー監視システム [TechnoAlive](https://technosphere.co.jp/technoalive) を自社開発しています。社内には20年以上の開発・運用キャリアを持つエンジニアが在籍しており、以下、教科書的な定義ではなく「運用してみると何につまずくか」を軸に書きます。 ### アクティブ監視とパッシブ監視 死活監視の実現方法は、大きく2つに分類できます。 - **アクティブ監視（能動監視）：**監視サーバー側から定期的にPingやHTTPリクエストを送り、応答を確認する方式。「応答がない＝異常」と判断しやすく、本記事で扱う方式の大半がこちらです - **パッシブ監視（受動監視）：**監視対象側から送られてくるハートビート・SNMPトラップ・ログを受け取って状態を判断する方式。「来るはずの信号が来ない」ことで異常を検知します 実務では両者を組み合わせます。アクティブ監視は導入が容易な反面「監視サーバーから見える範囲」しか確認できず、パッシブ監視はNAT越えやファイアウォール内の機器にも使える反面、「信号が来ない理由」が対象の障害なのか経路の問題なのか切り分けにくい、という補完関係にあるためです。 ## 死活監視で「できること」と「できないこと」 死活監視を入れたのに障害に気づけなかった——というクレームの多くは、死活監視が本来検知できないものを検知できると思い込んでいたことが原因です。先に守備範囲の境界線を引いておきます。 ### できること - **サーバー・機器の停止検知：**電源断、OSクラッシュ、インスタンス停止、ネットワーク断を数分以内に検知 - **サービスポートの停止検知：**Webサーバーやデータベースのプロセスダウンを、ポート応答の有無で検知 - **復旧の確認：**障害対応後、応答が戻ったことを客観的に確認 - **稼働率（アップタイム）の記録：**SLA報告や障害振り返りの根拠データを蓄積 ### できないこと（死活監視だけでは不十分なケース） | 死活監視で見逃す障害 | 実際に起きること | 必要な監視 | | 性能劣化・応答遅延 | ページ表示に30秒かかるが「応答はある」ため正常扱い | 応答時間の閾値監視、リソース監視 | | アプリケーションの論理エラー | プロセスは生きているが決済処理だけ失敗し続ける | 外形監視（シナリオ監視）、ログ監視 | | リソース枯渇の予兆 | ディスク使用率98%。翌朝ログ書き込み失敗で全面停止 | CPU・メモリ・ディスクの閾値監視 | | セキュリティ侵害 | SSHへのブルートフォース攻撃。サーバーは「正常稼働」のまま | 認証ログ監視、セキュリティ監視 | | 証明書・ドメインの期限切れ | TLS証明書が失効しブラウザで警告。ポート443自体は応答 | 証明書有効期限の監視 | つまり死活監視は「止まった」ことは検知できても、「壊れかけている」「遅い」「間違った動きをしている」は検知できません。だからこそ現在の監視ツールの多くは、死活監視を入口に**リソース監視・外形監視・ログ監視を組み合わせた統合監視**へと発展しています。 ** 実務での順序 弊社が運用設計をお手伝いする際は、①死活監視（全サーバー）→ ②ディスク・メモリの閾値監視 → ③本番URLの外形監視 → ④ログ・セキュリティ監視、の順で導入することを推奨しています。①と②だけで、運用現場で「痛い思いをする障害」の大半は事前検知できるようになります。 ## 監視方式の技術解説：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方式はすべて「外から確認する」**エージェントレス監視**です。これに対し、監視対象サーバーに常駐プログラム（エージェント）を入れて内部から情報を送る**エージェント型監視**があります。 | | エージェントレス | エージェント型 | | **取得できる情報** | 外から見える範囲（応答有無・応答時間・ポート状態） | 内部情報全般（CPU・メモリ・ディスク・プロセス一覧・ログ） | | **導入の手間** | 監視側の設定のみ。対象サーバーに変更不要 | 全対象へのインストール・バージョン管理が必要 | | **ネットワーク要件** | 監視サーバー→対象への到達性が必要（FW穴あけ） | 対象→監視サーバー方向の通信が多く、NAT内でも使いやすい | | **対象が完全停止した時** | 確実に検知できる（応答が消えるため） | 「データが来ない」ことからの間接検知になる | | **向いている用途** | 死活監視・外形監視 | リソース監視・プロセス監視・ログ監視 | 重要なのは**「エージェント型だけに寄せると、死活監視が弱くなる」**という点です。サーバーが完全に停止するとエージェントもろとも沈黙するため、エージェント型監視での停止検知は「メトリクスの途絶」という間接的なシグナルに頼ることになります。死活の一次判定はエージェントレス、詳細情報はエージェント、という併用が堅実です。弊社の[TechnoAlive](https://technosphere.co.jp/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日で警告など）を含めておきましょう。 ### 誤検知パターン早見表 | 症状 | よくある原因 | 対策 | | 正常なのに「ダウン」判定（偽陽性） | ICMP遮断／FWのレート制限／経路の瞬断／監視元IPのブロック | ICMP許可設定の確認、N回連続失敗での判定、複数拠点監視、監視元IPの許可リスト登録 | | ダウンしているのに「正常」判定（偽陰性） | CDN・LBのキャッシュが200を返す／プロセスはあるがハング | キャッシュを通らないヘルスチェックURLの監視、応答本文のキーワード検証 | | 夜間だけ大量のアラート | バックアップ・バッチによる高負荷で応答遅延 | メンテナンスウィンドウの設定、時間帯別の閾値、タイムアウト値の見直し | | アラートが復旧・再発を繰り返す（フラッピング） | 閾値ぎりぎりの状態が継続、不安定な回線 | ヒステリシス（障害判定と復旧判定の閾値を分ける）、連続成功N回で復旧判定 | ## 通知設計の実務：アラート疲れを防ぐ 監視の失敗は「検知できなかった」より**「検知したのに誰も反応しなかった」**ことで起こるほうが多い、というのが運用現場の実感です。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＋携帯キャリアメール）を選びます。通知のテスト送信を月次の定期作業に組み込み、「いざという時に届かない」を事前に検出するのも地味ながら効果の高い運用です。 ** ツール選定時のチェックポイント 通知まわりは製品差が出やすい部分です。「重大度別に通知先を変えられるか」「エスカレーションを自動化できるか」「メンテナンスウィンドウを設定できるか」「テスト通知機能があるか」の4点は、比較検討時に確認しておくことをおすすめします。 ## ツールの選び方：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月時点**の情報です（料金は改定されることがあるため、導入時は必ず公式サイトをご確認ください）。 | ツール | 形態・ライセンス | 死活監視の方式 | 料金の目安（2026年7月時点） | 向いているケース | | **Zabbix** | OSS（7.0以降AGPLv3、6.4以前GPLv2） | ICMP／TCP／HTTP＋エージェント。統合監視の定番 | ソフトウェア無料。監視サーバーの構築・保守コストは自己負担 | 数百台規模を専任チームで一元監視。オンプレ・閉域網 | | **Nagios Core** | OSS（GPLv2） | プラグイン実行型。NRPE/NCPA等のエージェント併用可 | ソフトウェア無料。同上 | 歴史が長く情報豊富。既存Nagios資産のある環境 | | **Prometheus + Grafana** | OSS（Apache 2.0／Grafana OSSはAGPLv3）。PrometheusはCNCFプロジェクト | Pull型メトリクス収集。死活・外形は blackbox_exporter（HTTP/TCP/ICMP/DNS/gRPC対応） | ソフトウェア無料。同上 | Kubernetes・コンテナ環境。メトリクス中心の監視文化 | | **Mackerel** | SaaS（はてな） | エージェント型＋外形監視（URL監視） | 無料枠はホスト5台まで。スタンダードホスト2,180円/月（税込）、マイクロホスト660円/月。外形監視20件までは最低利用料金（2,180円）に含まれる | 国産・日本語サポート重視。数台〜数十台の中小規模 | | **Datadog** | SaaS（米Datadog） | エージェント型中心。外形監視（Synthetic）は別課金 | 無料枠は5ホストまで。Infrastructure Proが$15/ホスト/月、Enterpriseが$23/ホスト/月（年払い） | APM・ログまで含めた大規模統合オブザーバビリティ | | **Amazon CloudWatch** | クラウド純正（AWS） | メトリクス＋アラーム。外形はSynthetics Canaryで別構成 | 従量課金。標準解像度アラーム0.10 USD/月、カスタムメトリクス0.30 USD/月〜、Canary実行0.0012 USD/回（リージョンで変動、無料枠あり） | 監視対象がAWSに閉じている環境のリソース監視 | | **TechnoAlive** | 自社開発の監視システム（テクノスフィア） | エージェント不要のPing・SSH・HTTP(S)監視＋リソース・セキュリティ監視 | 要問い合わせ | OCI・AWS・Azure・GCP・オンプレ混在環境を1画面で。デモ・導入相談が可能 | なお「まず無料で外形監視だけ」であれば、Uptime Kuma（セルフホストOSS）やUptimeRobotの無料枠でHTTP監視を始める手もあります。ただし通知の冗長化やエスカレーションはこの層のツールでは弱いため、本記事で述べた通知設計が必要になった時点が上位ツールへの乗り換えどきです。 ** 公平のための補足 上記はどれも実績のある選択肢で、優劣ではなく「規模と体制への適合」で選ぶものです。弊社製品のTechnoAliveも万能ではなく、APMやログ分析まで必要な大規模環境ならDatadog、Kubernetes中心ならPrometheusが適しています。TechnoAliveが向くのは、複数クラウドにまたがる数台〜数十台のサーバー群の死活・リソース・セキュリティ監視を、作り込みなしでまとめたいケースです。 ## クラウドサーバー監視の観点：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ツールで束ねる構成を採ることが多くあります。クラウド移行そのものを検討中の方は [クラウド移行支援サービス](https://technosphere.co.jp/cloud-migration) も併せてご覧ください。 ## まとめ ### この記事のまとめ - 死活監視は「止まったことを最速で知る」ための監視。性能劣化・論理エラー・リソース枯渇は守備範囲外で、リソース監視・外形監視との併用が前提 - Ping（L3）→ TCPポート（L4）→ HTTP(S)（L7）の順に検知範囲が深くなる。最終的な正常性判定はヘルスチェックエンドポイントへのL7監視で行う - ICMP遮断環境・プロセス生存とサービス応答の乖離・監視サーバー自身の死活・DNSと証明書、が実務4大落とし穴 - アラートは「行動が必要なものだけ」に絞り、リトライ判定・エスカレーション・通知経路の冗長化を仕組みで担保する - ツールは監視対象数×運用体制で選ぶ。数十台までならSaaS優位、数百台規模からOSS自前運用の損益分岐。クラウド純正はリソース監視、横断ツールは死活・外形監視と住み分ける 監視は「入れて終わり」ではなく、アラートの棚卸しと閾値チューニングを続けてはじめて機能します。まずは自社の監視が「止まったことに最速で気づける状態か」「鳴ったアラートに人が反応しているか」の2点から点検してみてください。 ／サーバー監視・運用のご相談はこちら＼ ### 監視設計から運用まで、まとめて任せられます 死活監視・リソース監視・セキュリティ監視を一元化するTechnoAliveの導入から、既存Zabbix環境の見直し、通知設計のチューニングまで。マルチクラウド対応のサーバー監視を実務経験ベースでご提案します。 [TechnoAliveの詳細を見る](https://technosphere.co.jp/technoalive) [監視・運用の相談をする](https://technosphere.co.jp/contact) ## よくある質問（FAQ） ** 死活監視と外形監視の違いは何ですか？ 見る場所が違います。死活監視は「サーバーやプロセスが生きているか」をPing応答やポートの開閉で確認し、外形監視は「ユーザーから見てサービスが使えるか」を外部からのHTTPリクエストで確認します。プロセスは生きているのにアプリはエラーを返す、というズレは珍しくないので、本番サービスでは両方の併用が基本です。 ** Pingに応答があればサーバーは正常と考えてよいですか？ 言えません。PingにはOSが応答するため、WebサーバーやDBが落ちていてもPingは返ります。逆にファイアウォールでICMPが遮断されていれば、正常なサーバーでもPingは失敗します。Pingは「ネットワークに届くか」の確認と割り切り、サービスの生死はポート監視やHTTP(S)監視で見てください。 ** 監視間隔はどのくらいが適切ですか？ まず1分間隔・3回連続失敗で判定、から始めるのが無難です。これで拾えない障害が出たら間隔を詰める、誤報が多ければリトライ回数を増やす、という順で調整します。SaaSの場合は監視間隔が料金に直結する点も忘れずに。 ** OSSとSaaSはどちらを選ぶべきですか？ 専任担当を置けないなら、まずSaaSです。OSSはソフトウェアこそ無料ですが、監視サーバーの構築・保守という工数が継続的にかかります。対象が数台〜数十台ならSaaS、数百台規模でSaaS費用が保守工数を上回ってきたらOSS自前運用、という順で検討すれば大きく外しません。詳しくは本文のツールの選び方をご覧ください。 ** 監視サーバー自体が落ちたら障害に気づけないのでは？ 気づけません。これが自前監視の最大の盲点で、監視サーバーが落ちると「アラートが来ない＝正常」に見えます。監視サーバーを対象と別の場所に置く、監視サーバー自身を外部サービスで監視する（相互監視）、ハートビートの途絶で警報を上げるデッドマン方式、のいずれかを入れてください。 ** AWSを使っているならCloudWatchだけで十分ですか？ リソース監視なら十分です。ただしメモリ・ディスク使用率の取得にはCloudWatch Agentの導入が必要で、「AWSの外から到達できるか」はSynthetics等を足さない限り見えません。複数クラウド併用なら監視画面も分裂するため、死活・外形監視は横断ツールに寄せるのが現実的です。 # 死活監視 # サーバー監視 # 外形監視 # Zabbix # Prometheus # Mackerel # CloudWatch # アラート設計 ## 次に読む｜サーバー運用・クラウド関連 - [製品紹介 TechnoAlive｜クラウドサーバー死活監視システム 死活・パフォーマンス・セキュリティ監視を1つのダッシュボードで](https://technosphere.co.jp/technoalive) - [サービス クラウド移行支援サービス オンプレからAWS・OCIへの移行設計と運用体制づくり](https://technosphere.co.jp/cloud-migration) - [技術コラム Raspberry Piでセンサーデータ取得＆クラウド連携 完全ガイド MQTT経由でAWS IoT Coreへ送信するIoT監視の実装例](https://technosphere.co.jp/blog/raspberry-pi-sensor-iot) - [技術コラム OpenClaw 入門｜社内Kubernetesで動かす環境構築ガイド k3sクラスタの構築・運用ノウハウ](https://technosphere.co.jp/blog/openclaw-getting-started) [技術コラム一覧に戻る](https://technosphere.co.jp/blog/)