独立サイト監視の設計：可用性・性能・エラー・証明書のアラートしきい値

独立サイト監視の設計：可用性・性能・エラー・証明書のアラートしきい値

1. 可用性監視：5分間隔で検知し、連続失敗のみをカウントする

可用性監視は最も基本の層で、サイトが開けるかどうかを見ます。多くの人は1回の検知でアラートを出し、ネットワークの揺らぎ1回で人を起こしてしまい、1週間後には全員がアラートを切ってしまいます。正しいやり方は連続検知失敗のみを問題とみなすこと。連続2回失敗で黄色のメッセージをグループへ、連続3回失敗でSMSと電話を送ります。検知間隔は5分、世界に最低3つの検知ポイント（例えば米国東部、欧州、アジア太平洋）を置き、単一ポイントによる誤報を避けます。

監視するURLはトップページだけにしないこと。トップページはキャッシュで生きていても、製品ページや問い合わせフォームが落ちていることがあります。最低3つのURLを監視します。トップページ、製品詳細ページ1つ、問い合わせフォームの送信エンドポイントです。どれか1つでも落ちれば可用性障害とみなします。ツールはUptimeRobotの無料版で十分で、50の監視枠、5分間隔、世界の複数検知ポイントが使えます。

シナリオ例：ある越境サイトがUptimeRobotでトップページを監視し、連続3回失敗でアラートを出す設定にしていました。ある夜、シンガポールの検知ポイントが連続3回失敗しましたが、米国東部と欧州の検知ポイントは正常でした。これはシンガポール現地のネットワーク問題で、サイトが落ちたわけではありません。1回の検知でアラートを出す設定なら、当番の人が深夜2時に起こされ、起きてみたらサイトは正常、次からは信じなくなります。複数の検知ポイントと連続失敗の組み合わせで、誤報率を最小限に抑えられます。

可用性と災害復旧のRTO/RPOはセットです。可用性アラートが発火したら、復旧手順に沿って進めます。CDNノード障害時の判断方法は次を参照：CDNグローバル高速化。

2. パフォーマンス監視：総合スコアではなくLCPを追う

パフォーマンス監視で最もありがちな失敗は、総合スコアを追いかけることです。Google PageSpeedのスコアは変動が大きく、同じページでも午前は85点、午後は65点ということが起こります。こうした変動でアラートを出しても意味がありません。本当に見るべきはCore Web Vitalsの3つの指標、とくにLCP（最大コンテンツの描画）です。これはユーザーの体感とSEO順位に直結します。

パフォーマンスのアラートは単一のしきい値ではなく、継続時間で判断します。LCPがたまたま2.5秒を超えるのは、回線が遅いユーザーがいただけかもしれません。10分以上続いて初めて本当の問題です。黄色のしきい値はLCPが2.5秒超を10分継続、赤はLCPが4秒超を15分継続とします。ツールはBrowserStack SpeedCurveかChrome User Experience Reportの公開データを使い、月単位で傾向を見ます。

シナリオ例：あるサイトで午前中、LCPが1.8秒から3.5秒に上がり、20分続いたあと自然に戻りました。ログを調べるとデータベースのスロークエリが原因で、あるプラグインの定期処理が全表スキャンを走らせていました。こうした問題をアラートで検知しなければ、この20分の間に問い合わせを送ったユーザーはタイムアウトし、そのまま失注します。パフォーマンス監視の価値は、こうした一時的な劣化を捉えることにあります。Core Web Vitalsの改善方法はこちらCore Web Vitalsのしきい値と改善の優先順位。

3. エラー率とログ：5xxと4xxは分けて見る

エラー率の監視は2種類に分けます。5xxはサーバーエラーで、必ずアラートを出します。4xxはクライアントエラーで、ほとんどは放置して構いません。2つを混ぜて集計すると、アラートが多すぎるか、本当の問題が埋もれるかのどちらかになります。5xx率が1%超を5分継続で黄色、5%超を10分継続で赤を出します。4xxは404の急増だけを監視します。404が増えるのは、外部リンクの切れか、リニューアル時の301設定漏れのサインです。

エラー追跡にはSentryのようなツールを使います。フロントエンドのJSエラーとバックエンドの例外を自動で収集し、エラーごとにグループ化してくれます。独立したサイトではすべてのエラーを追う必要はありませんが、上位3件のエラーの発生頻度は追いましょう。あるエラーが週1回から毎時10回に急増したら、リリースでバグが入った証拠です。ログ分析のやり方はこちらAIクローラーログ分析。

例：あるサイトが新バージョンを公開した後、SentryでJSエラーが1日3回から1日200回に急増。コードを調べると、とある広告枠のスクリプトがSafariで例外を投げ、フォーム送信に影響していた。こうしたバグをアラートにしないと、Safariユーザーの問い合わせをそのまま失う。Sentryのエラー頻度監視なら、リリース後24時間以内にこうした回帰を検知できる。

四、証明書とバックアップの監視：最も忘れられやすい2つ

証明書の期限切れは、独立サイトで最もよくある「初歩的な事故」。期限切れの90%は技術的な問題ではなく、更新を忘れただけ。監視は2段階で設定する。残り30日でメール通知、残り15日で企業WeChatアラート。残り3日まで待ってはいけない。その頃にはドメイン登録業者のメールも迷惑メールフォルダに入っているかもしれないし、DNS解決に問題が起きても間に合わない。ツールはUptimeRobotの証明書監視か、自作スクリプトで毎日チェックする。

バックアップタスク自体も監視が必要。バックアップスクリプトが失敗しても気づかず、いざという時に直近のバックアップが2週間前だと分かる。アラートルールは3つ。バックアップタスクの終了コードが0以外ならアラート。バックアップファイルのサイズが前日より30%急減したらアラート（データベースに接続できない可能性）。最新バックアップの経過時間が24時間を超えたらアラート。バックアップ戦略の詳細はサイトのバックアップと復元演習。

直感に反する注意点：アラートチャネルは1つにしない。メールは迷惑メールフォルダに入りやすく、企業WeChatは休暇中で誰も見ていないかもしれず、SMSと電話が最後の砦。重要なアラート（サイトダウン、証明書の期限切れ間近）は必ずSMSと電話、一般アラートは企業WeChatグループへ。同時にエスカレーションも設定する。赤アラートが15分間対応されなければ、自動で技術責任者にエスカレーション。日常点検チェックリストは公式サイト保守で毎月やる6つのこと。

監視体制を構築したら、毎月アラートを振り返る。過去1か月に黄色が何件、赤が何件、誤報が何件あったか。誤報率が30%を超える閾値は厳しくするか調整する。監視の目的はすべての可能性をカバーすることではなく、本当に問題が起きた時に真っ先に人を起こすこと。そのためには、毎日誤報を出すルールを自分から削っていく必要がある。

FAQ よくある質問

最後に

監視体制で最もよくある失敗は、監視していないことではなく、監視が多すぎて誰も見なくなることです。組み上げた直後は何もかも追いたくなります。CPU、メモリ、ディスク、ネットワーク、すべてのURL、すべてのエラー。1週間もするとアラートが多すぎてチームが麻痺し、本当の障害の赤いアラートが黄色いノイズに埋もれてしまいます。監視の価値は「肝心なときに人を起こすこと」にあり、網羅性にはありません。

実践は3ステップ。第一に、4つの軸（可用性、性能、エラー、証明書）ごとに黄と赤の2段階のしきい値を設定します。黄色はグループ通知のみで起こさない、赤だけがSMSと電話です。第二に、無料ツールの組み合わせで動かします。UptimeRobotとSentryと証明書スクリプトで、月額コストは0円。第三に、毎月1回アラートを見直し、誤報率が30%を超えるルールは削除します。監視は生きているシステムで、組み上げて終わりではありません。手入れを続ける必要があります。

覚えておきたい一言。監視の目的はすべての可能性を網羅することではなく、本当の障害が起きたときに真っ先に人を起こすことです。アラートが多すぎてチームがミュートしてしまったら、監視がないより危険です。