24時間監視でも翌朝に気づく理由と通知設定の見直し方

「監視してるはずなのに障害に気づいたのは翌朝だった」。その原因は通知設定の落とし穴にあります。実案件をもとに、確実に届くアラート設定の実践手順を解説します。

「監視してるのに、なぜ朝まで気づかなかったのか」

こんな経験はありませんか？

• サーバー監視ツールを導入しているのに、障害を報告してきたのはユーザーだった
• 夜中の2時にサイトがダウンしていたのに、気づいたのは出社してから
• 監視ダッシュボードを見ると「エラー多数」と記録されているのに、通知メールが1件も来ていない

「24時間監視」という言葉には、重大な落とし穴が潜んでいます。 サーバーを監視しているのと、障害を確実に検知して人間に届けているのは、まったく別の話です。ツールが動いていることと、チームが正しく動けることの間には、意外と深い溝があります。

この記事では、あるECサイト運営企業での実案件をベースに、「監視しているのに気づかない」という状況が起きる本当の理由と、それを解消するための通知設定の見直し手順を具体的に解説します。

なぜ「監視済み」なのに翌朝まで気づかないのか

原因1：通知の到達経路が壊れている

最もよくあるケースが、通知メール自体はサーバーから送られているが、受信できていないという状況です。具体的には以下のような理由が重なります。

• 監視ツールからのメールがスパムフォルダに振り分けられている
• 送信元サーバーのSPF/DKIMが未設定で、受信サーバーに拒否されている
• 通知先メールアドレスが個人の携帯キャリアメールで、深夜は受信しない設定になっている
• Slackや社内チャットへのWebhook連携は設定したが、チャンネルをミュートにしたまま

原因2：アラートが「多すぎる」ために無視されている

逆説的ですが、通知が多すぎると人間は反応しなくなります。これを**アラート疲れ（Alert Fatigue）**と呼びます。CPU使用率が70%を超えるたびにメールが届くような設定にしてしまうと、深夜帯に数十件の通知が積み上がり、本当に致命的な障害の通知が埋もれてしまうのです。

原因3：「監視対象」と「通知条件」がズレている

サーバーのPingは通っているのにWebアプリが落ちている、というケースも頻繁に起きます。サーバー自体は生きていてもNginxやPHP-FPMのプロセスがクラッシュしていれば、ユーザーには503エラーが返ります。監視対象がOS層だけで止まっており、アプリケーション層やデータベース接続を見ていないことが原因です。

flowchart TD
    A[障害発生] --> B{サーバーPingは通る？}
    B -->|Yes| C{Webサーバーは応答する？}
    B -->|No| G[サーバーダウン通知 ✅]
    C -->|Yes| D{アプリは正常？}
    C -->|No| H[Nginx/Apache障害 ⚠️ 未検知になりがち]
    D -->|Yes| E{DBは接続できる？}
    D -->|No| I[アプリ障害 ⚠️ 未検知になりがち]
    E -->|No| J[DB接続障害 ⚠️ 未検知になりがち]
    E -->|Yes| F[正常]

実案件：EC事業者で起きた「翌朝発覚」の事例

あるEC事業者のクライアントから相談を受けたのは、「土曜の深夜にカート機能が停止していたが、気づいたのは日曜の午前10時だった」というケースでした。損失は機会損失ベースで数十万円。Mackerelで監視設定はしてあったにもかかわらず、なぜ通知が来なかったのかを調査しました。

結果、原因は3つ重なっていました。

1. Mackerelの通知先がプロジェクト担当者の個人メールのみで、Slackへの連携がなかった
2. MySQLの接続エラーは監視対象外で、Webサーバーの死活監視しか設定していなかった
3. アラートのしきい値が緩すぎて、HTTPステータスコードの確認もしていなかった

この事例を受けて、以下の設定を段階的に整備した結果、その後の同様のインシデントは発生から5分以内に担当者のスマートフォンへSlack通知が届くようになりました。

通知設定の見直し手順：実践ガイド

ステップ1：監視対象を「層」ごとに整理する

まず、何を監視するかをレイヤー別に整理します。

ステップ2：HTTPエンドポイント監視を追加する

UptimeRobotのような外形監視ツールは、外部からHTTPリクエストを送って200が返るかどうかを確認します。サーバー内部の監視では検知できない「ユーザー視点の障害」を捉えられる点が最大のメリットです。

無料プランでも5分間隔の監視が可能で、SMS・Slack・メール通知に対応しています。設定に専用のコードは不要ですが、ヘルスチェック用のエンドポイントをLaravelで用意しておくと精度が上がります。

// routes/web.php
Route::get('/health', function () {
    try {
        // DBへの接続確認
        DB::connection()->getPdo();
        
        // キャッシュの読み書き確認
        Cache::put('health_check', true, 10);
        
        return response()->json([
            'status' => 'ok',
            'db'     => 'connected',
            'cache'  => 'ok',
            'time'   => now()->toIso8601String(),
        ], 200);
    } catch (\Exception $e) {
        // 503を返すことで外形監視ツールが障害と判定する
        return response()->json([
            'status'  => 'error',
            'message' => $e->getMessage(),
        ], 503);
    }
});

// wp-content/mu-plugins/health-check.php
add_action('rest_api_init', function () {
    register_rest_route('custom/v1', '/health', [
        'methods'             => 'GET',
        'callback'            => function () {
            global $wpdb;
            $result = $wpdb->get_var('SELECT 1');
            if ($result !== '1') {
                return new WP_REST_Response(
                    ['status' => 'error', 'db' => 'failed'], 503
                );
            }
            return new WP_REST_Response(
                ['status' => 'ok', 'db' => 'connected'], 200
            );
        },
        'permission_callback' => '__return_true',
    ]);
});

このエンドポイント（例：https://example.com/health）をUptimeRobotに登録し、HTTPステータス200以外の場合に通知するよう設定します。

ステップ3：Slack通知を多段階に設定する

メールだけでは深夜に気づけません。Slackへのインテグレーションを設定し、さらに重大度に応じてチャンネルを分けることがポイントです。

# Mackerelのアラートをcurlでテストする例
curl -X POST https://hooks.slack.com/services/YOUR/WEBHOOK/URL \
  -H 'Content-type: application/json' \
  -d '{
    "channel": "#alerts-critical",
    "username": "監視Bot",
    "icon_emoji": ":rotating_light:",
    "text": "*[CRITICAL]* example.com のヘルスチェックが失敗しました\n確認してください: https://example.com/health"
  }'

通知チャンネルの設計例はこのようになります。

• #alerts-info：CPU 80%超など、注視が必要な軽微な通知
• #alerts-warning：レスポンス遅延、ディスク残量低下など
• #alerts-critical：サービスダウン、DB接続不可など。メンション必須（@channelまたは担当者指定）

ステップ4：エスカレーション設定で「見逃し」をなくす

Slackの通知を見逃した場合のフォールバックとして、PagerDutyやOpsGenieのようなオンコールツールを導入するのが理想的です。一定時間応答がなければSMSや音声電話で担当者を叩き起こす仕組みが作れます。

コストをかけたくない場合は、Slackの「リマインダー」機能をBotで組み合わせるか、UptimeRobotのSMS通知（有料プラン）を活用する方法もあります。

よくある失敗パターンと対処法

まとめと次のステップ

「24時間監視」は、正しく設定されて初めて機能します。ツールを入れただけでは、障害はサーバーのログに残るだけで、人間には届きません。今回解説した内容を整理すると、監視対象の多層化・通知到達の確認・アラートの重大度分類という3点が核心です。

現在の監視設定に少しでも不安があれば、まず以下のチェックリストで現状を棚卸ししてみてください。

監視設定の見直しは、一度しっかり整備すれば長く効きます。しかし「どこから手をつけていいかわからない」「今の設定が正しいかどうか判断できない」という場合は、ぜひFivenine Designへご相談ください。現状の監視設定を診断し、運用フローも含めた改善提案をいたします。