「サイトが
死活監視と外形監視の違い
ひとくちに
| 種類 | 見ている | 検知できる |
|---|---|---|
| 死活監視 | サーバーが | サーバー停止・ネットワーク断 |
| 外形監視 | 実際の | Webサーバーの |
| リソース監視 | CPU・メモリ・ | ディスク枯渇・負荷上昇の |
見落としが
ダウンに気づけないと何を失うか
- 機会損失 — 問い合わせフォームや
ECが 止まっている 間の 売上・リードは 戻ってきません。 深夜や 休日の ダウンは、 監視が なければ 翌営業日まで 気づけない こともあります - 信用 —
「電話で 指摘されて 気づいた」と いう 事実 その ものが、 取引先からの 信頼を 削ります。 障害は 起きる ものですが、 検知の 遅さは 体制の 問題と 受け取られます - 検索評価への
影響 — 長時間・頻繁なダウンが 続くと、 検索エンジンからの クロールに 失敗し続ける ことになり、 良い ことは 何も ありません - 原因調査の
手が — いつからかり いつまで 落ちていたかが 分からないと、 原因の 特定も 難しくなります。 監視記録は 障害対応の 出発点です
導入の実務｜監視設計で決めること
- 監視対象の
URL — トップページだけでなく、事業上止まると 困る ページ （問い合わせフォーム・ログインページ・決済導線）を 対象にします。 DBに 接続する ページを 1つ 入れておくと、 DB障害も 間接的に 検知できます - 監視間隔 — 1〜5分間隔が
一般的です。 間隔が 長いほど 検知が 遅れます。 コーポレートサイトなら 5分、 ECや 業務システムなら 1分を 目安にします - 判定条件 — HTTPステータスだけでなく、
応答時間の しきい 値 （例：10秒超で 異常）や、 ページ内の 特定文字列の 有無まで 見ると 精度が 上がります。 1回の 失敗で 即通知ではなく 「2〜3回連続失敗で 通知」に すると 誤報を 減らせます - 通知先と
時間帯 — メールだけでは深夜に 気づけません。 Slackや Chatwork、 必要なら 電話・SMSへの 通知を 組み合わせ、 誰が 一次対応するかまで 決めて おきます
SSL証明書の期限監視も忘れずに
サイトダウンと
無料ツールでどこまでできるか
UptimeRobotなどの
- 監視間隔が
長め （無料枠では 5分間隔など）に 制限される - 通知手段や
監視項目 （文字列チェック・SSL期限など）が 有料機能に なっている ことがある - 通知が
来た —後に 対応する 人が いなければ 意味が ない これが 最大の 限界です。 深夜の 通知を 誰が 受けて、 誰が サーバーを 調査するのかと いう 体制は、 ツールでは 解決できません
監視代行を検討すべきタイミング
次の
- サイト停止が
売上や 業務に 直結する （EC・予約・業務システム） - 社内に、
通知を 受けて サーバーを 調査できる 人が いない、または 1人しかいない - 夜間・
休日の 障害に 対応する 体制が 組めない
監視代行は
費用の目安と運用のコツ
費用感の
運用面では、
- 誤報を
放置しない — 誤報が続くと 通知が 「オオカミ少年」化し、 本物の 障害を 見逃します。 誤報が 出たら 判定条件 （連続失敗回数・タイムアウト値）を その 都度 調整します - 月次で
稼働率を — 監視サービスの振り返る 多くは 稼働率レポートを 出せます。 「先月は 99.9%だったか」 「短い 断続的な ダウンが 増えていないか」を 月次で 見ると、 サーバー移転や 増強の 判断材料に なります
まとめ｜まず1本のURL監視から
死活監視は、