応答時間監視

なぜ応答時間に専用のアラートが必要なのか

標準の稼働時間アラートはバイナリ信号（稼働中／ダウン）に基づいています。しかし、「稼働中だが遅い」というグレーゾーンこそが、現代の多くの障害が本当に発生している場所です。例えば、誤ったデータベースクエリの設定により、50msだった処理が4秒かかるようになることも。メモリリークによるガーベジコレクションの増加、バックエンドが呼び出す外部APIの動作不安定。これらの事象はサイトを完全に壊すわけではありませんが、使い物にならなくし、1～2時間後の障害の初期兆候となります。

応答時間モニタリングによって、障害に至る前の遅延をキャッチできます。モニターごとに閾値を設定し、応答時間が数回連続で閾値を超えるとアラートが送信されます。アラートが届くまで余裕があるので、その間に調査、スケールアップ、問題となっている呼び出しのスロットリング、あるいは引き金となったデプロイのロールバック対応が可能です。

DiagnoSEO Uptime Monitoring での閾値の仕組み

各モニターは2つのパラメーターで設定できます：rt_threshold_ms と rt_threshold_breaches。前者は許容可能と考える応答時間（ミリ秒単位）、後者は何回連続で閾値を超えたらアラートを発報するか。デフォルトでは閾値機能はオフ、超過回数は3回です。

2パラメーター設計により誤検知を防ぎます。ネットワークのジッタやガーベジコレクションによる一時的な遅延はよく発生します。ベースが200msのときにたまの1秒超えは、深夜3時のページャーを鳴らすほどのことではありません。でも3回連続なら、それは一時的ではなく恒常的な遅延です。パラメーターは日頃の通常値と安全マージンをもとに選定しましょう：p95が通常400ms なら1000ms、p95が50ms（内部API）なら200msなど。

どんな組み合わせが効果的か

応答時間アラートは、他のモニタリング信号と組み合わせて使うことで最大限の効果を発揮します。全体像として、応答時間の閾値超過は「システムが劣化し始めている」サイン、HTTPステータスコードは「完全に壊れた」瞬間、SSL/ドメイン警告は「期限切れ」等の障害、DNS変更アラートは「設定ドリフト」をそれぞれ示します。4つのシグナルを1つのモニターでまとめることで、「動作しているかどうか」を超えた真のオブザーバビリティが得られます。

ダッシュボードも役立ちます。各モニタ毎に最新の応答時間をスパークラインで表示し、劣化傾向を素早く視覚化できます。展開ビューでは24h、7d、30dの平均応答時間もチェック可能。もし週ごとに平均値が上昇していれば、閾値アラート発報前の早期警告として対応の検討が必要です。

サイトタイプ別の実用的な閾値

• マーケティング向けランディングページ：1500ms程度が妥当。画像やトラッカー系スクリプトが重めなので、絶対的な速さよりも安定性重視。
• 商品ページ／ECカテゴリー：800～1200ms。ECサイトの遅さはコンバージョン率に悪影響なので、厳しめの閾値設定が望ましい。
• アプリケーションダッシュボード：500～800ms。ユーザーは俊敏な反応を期待。遅いダッシュボードは製品の品質低下の印象に直結。
• 公開API：簡易エンドポイントは200～400ms、計算量の多いものは上限緩和。階層分け推奨。
• 内部マイクロサービスのヘルスチェック：50～100ms。ほぼ即時応答が求められ、遅れはほとんど本物の問題。

どんな値を選ぶにしても「一度設定したら忘れる」のはNG。実際のトレンドをもとに四半期ごとに見直しましょう。意味のないアラートが頻発するなら閾値が厳しすぎですし、アラートなしで障害が発生したなら緩すぎです。

アラートのルーティング

閾値超過アラートは、ダウン／復旧アラートと同じチャンネルで通知されます：Email、Telegram、Slack、Discord、SMS。すべて同じサイレンス設定が適用され、同一のアラート履歴テーブルに記録されます。違いはイベントタイプ（"threshold" vs "down"）と通知テキストだけです。通知本文には実際の応答時間と設定閾値が記載されるので、どれくらい超過したか一目で分かります。

設定方法

任意のモニターを編集します。フォームで「応答時間閾値（ms）」を希望する値に設定してください。デフォルト（3回）が許容できなければ「連続超過回数」も調整可能です。保存後、次サイクル以降の各チェックで応答時間が閾値を上回った場合、設定回数分連続で超過すれば通知が届きます。

よくある質問

• どの応答時間メトリクスが記録されますか？

  Time To First Byte (TTFB) — リクエスト送信から最初のバイト受信までのミリ秒、および全応答取得までの合計時間。TTFBはサーバーヘルスを測る最も有用な単一メトリクスです。

• 「良い」応答時間とは？

  ロケーションやコンテンツによって異なります。CDN付き静的サイトなら100ms未満が理想、300ms未満なら問題なし。動的アプリなら500ms未満が良好、1000ms未満が許容範囲、2000ms超は遅く感じられます。絶対値ではなく、自サービスの過去データを基準に比較しましょう。

• 応答時間が閾値を超えた際にアラートを受け取れますか？

  はい。すべてのモニターで応答時間の閾値をオプション設定できます。3回連続で超過すると「slow response」アラートが送信されます。ネットワークの一時的不安定による誤検知防止のため、3回連続超過を要件としています。

• 応答時間はどこで計測されますか？

  当社の地理的に分散された13か所のチェックポイント（ヨーロッパ、北米、アジア、南米、オセアニア）から計測されます。シングルリージョンモニターは最寄り地域の値、マルチリージョンモニターは各地域ごとに独立して計測され、CDNの地域偏在トラブル検知に役立ちます。

• ダッシュボードでは応答時間のトレンドが確認できますか？

  はい。30日間の移動平均、日別の最大・最小、パーセンタイル（p50、p95）などを可視化。キャパシティプランニングにも有用で、たとえばp95が1か月で800msから1500msに増加すれば、稼働率が100%のままでもサーバー過負荷の兆候と言えます。