死活監視の種類と使い分け

比較表

タイプ別の詳細

1. HTTP 監視

指定 URL にリクエストを送り、ステータスコードと応答時間を記録します。Miterl では複数拠点（東京 / シンガポール）から同時にチェックすることで、特定地域の障害も検知可能です。

• 推奨間隔: 1〜3 分（Pro プランは 30 秒）
• 推奨用途: 公開サイト全般・API エンドポイント
• よくある誤検知: 一時的なネットワーク輻輳 → リトライ閾値の調整で対応

2. Keyword 監視

レスポンス本文に「必須文字列があるか」「禁止文字列が出ていないか」をチェックします。HTTP 200 が返っていてもエラー画面が表示されているケース（DB ダウン時の Laravel エラー画面など）を検知できます。

• 必須キーワード例: ログイン後の「マイページ」、購入完了画面の「ご注文ありがとうございます」
• 禁止キーワード例: 「Whoops, looks like something went wrong」「Database connection failed」

3. DOM Integrity 監視

HTML をパースして、title / canonical / og:image / noindex / robots などの SEO タグの整合性をチェックします。デプロイ時に「気づかぬうちに noindex が残っていた」「OGP 画像が消えてシェア時にサムネが出ない」といった事故を防ぎます。

• チェック項目: title / description / canonical / og:title / og:image / robots / noindex
• 推奨用途: メディアサイト・LP・コーポレートサイト・ブログ

4. Heartbeat 監視

バッチ処理が完了したタイミングで Miterl 側の URL に ping を打ち、「期待した間隔で ping が来ているか」を逆方向に監視します。サイトの外形監視では検知できない「夜間バッチが落ちた」「cron が止まった」といったジョブ系の障害をカバーします。

• 間隔設定例: 5 分 / 1 時間 / 1 日 / 1 週間
• 猶予時間 (grace period) で誤検知を抑制可能

5. SSL 監視

TLS 証明書の有効期限と中間証明書チェーンを定期的にチェックします。Let's Encrypt の自動更新が止まっていることに気づかず、ある朝突然サイトに鍵マークが出ない——という事故を防ぎます。期限の 30 日前 / 7 日前に通知を出すのが定番設定です。

• 通知タイミング: 期限の 30 日前 / 7 日前 / 期限切れ後
• 対象: ワイルドカード・SAN 含むすべての証明書

使い分けのコツ

パターン A：基本セット（コーポレート / LP / ブログ）

HTTP + DOM Integrity + SSL の 3 段構え。「落ちる」「中身が崩れる」「証明書が切れる」をすべてカバー。

パターン B：EC / 購入導線あり

パターン A に Keyword 監視を追加。決済完了画面に必須キーワード（「ご注文ありがとうございます」など）を仕込み、サイト全体ではなく「お金が動く画面」が壊れたかを検知。

パターン C：SaaS / API バックエンド

HTTP（複数エンドポイント）+ Heartbeat（夜間バッチ / 集計ジョブ）+ SSL の組み合わせ。DOM Integrity は不要。

パターン D：制作会社の保守案件 50〜200 件

案件ごとに HTTP + SSL の 2 点を必ず当て、SEO 重要案件のみ DOM Integrity を追加。Workspace 機能で顧客別に整理し、通知を分担。

よくある質問

Q. 1 つの URL に複数のタイプを当てられる？

可能です。HTTP + DOM Integrity + SSL を同じ URL に当てるのが最も一般的な設定です。

Q. 内部システム（社内ツール）の監視はどれを使う？

外部から到達できない場合は Heartbeat が最適です。サーバーから定期 ping を打つ形なので、ネットワーク制限の影響を受けません。

Q. 通知の重複を防ぐには？

Miterl は同一 URL 上の同時インシデントを 1 件に集約します。通知抑制ルールも設定可能です。