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

比較表

タイプ別の詳細

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 含むすべての証明書

6. Ping 監視

ICMP でホストが応答するかを確認します。HTTP 監視が「サイトが見えるか」を見るのに対し、Ping は「サーバーが生きているか」を見ます。Web サーバーのプロセスだけが落ちている場合は Ping では検知できないので、公開サイトでは HTTP と併用してください。

• 推奨用途: Web を話さないサーバー・ネットワーク機器
• 注意: ICMP を遮断しているホストでは使えません

7. TCP 監視

指定したポートに TCP 接続できるかを確認します。MySQL の 3306、SMTP の 25、SSH の 22 のように、HTTP を話さないミドルウェアの停止を検知できます。ポートは開いているが応答内容が壊れている、という状態までは見られません。

• 推奨用途: DB / メールサーバー / SSH / 独自プロトコル
• 推奨間隔: 1〜5 分

8. WHOIS 監視（ドメイン期限）

RDAP（取得できない TLD では WHOIS）でドメインの有効期限を取得し、失効が近づいたら通知します。SSL と同じく、サーバーの管理権限がなくても外から確認できるのが利点で、クライアント自身が契約しているドメインの更新忘れを制作会社側から見張れます。

• 通知タイミング: 期限の 30 日前 / 14 日前 / 7 日前
• 期限は「期限ダッシュボード」で SSL と並べて一覧できます

9. robots.txt 監視

robots.txt の内容が意図どおりかを監視します。ステージングの「Disallow: /」を本番へ持ち込んだまま戻し忘れる事故は、検索流入が消えるまで誰も気づきません。HTTP 監視では 200 が返るので検知できない種類の障害です。

• 推奨用途: 公開直後・リニューアル直後のサイト
• meta robots による noindex は DOM Integrity 側で見ます

10. MX 監視

ドメインの MX レコードを監視します。MX が消える・誤って書き換わると、問い合わせフォームの通知も受注メールも届かなくなりますが、サイト自体は正常に見えるため発覚が遅れます。「メールが来ていない気がする」と言われて初めて気づくタイプの障害を、先回りして検知できます。

• 推奨用途: 問い合わせフォーム・受注メールを扱うすべてのサイト
• DNS 移管・サーバー移行の直後は特に有効

11. SPF 監視

SPF レコードの存在と文法（RFC 7208）を監視します。レコードの消失だけでなく、DNS ルックアップ 10 回の上限超過や文法エラーも検知します。SPF が壊れているとメールは「届かない」のではなく「迷惑メールに入る」ため、送信側からは正常に見えるのが厄介な点です。

• 検知: レコード消失 / 文法エラー / lookup 上限超過
• 外部配信サービスを追加した直後は必ず確認を

12. DMARC 監視

DMARC レコードとポリシー（RFC 7489）を監視します。p=none から p=quarantine / p=reject へ運用を進める過程で、レコードが意図せず戻っていないか、文法エラーで無効になっていないかを継続して確認できます。

• 検知: レコード未設定 / 文法エラー / ポリシーの変化
• なりすまし対策が要件の案件で提出資料に使えます

13. DKIM 監視

セレクタごとに DKIM 公開鍵（RFC 6376）を監視します。鍵のローテーション時にセレクタを消してしまう、あるいは新しい鍵を公開し忘れる、といった事故を検知します。監視したいセレクタは複数登録できます。

• 検知: セレクタ消失 / 鍵の文法エラー / 公開漏れ
• SendGrid・Amazon SES など外部配信を使う場合に有効

使い分けのコツ

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

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

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

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

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

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

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

案件ごとに HTTP + SSL + WHOIS の 3 点を必ず当て、SEO 重要案件のみ DOM Integrity を追加。SSL と WHOIS はサーバーの管理権限が無くても外から見えるので、クライアント自身が契約しているサーバー・ドメインにも当てられます。問い合わせフォームが売上に直結する案件では MX / SPF を足すと、サイトは生きているのにメールだけ届かない状態を拾えます。Workspace 機能で顧客別に整理し、通知を分担。

よくある質問

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

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

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

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

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

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