Azure App ServiceにResponse Time（応答時間）の監視を入れた直後、Azureポータルを開いて設定を確認しただけでアラートが飛んだ。
サービスは普通に動いている。ユーザーからの問い合わせもない。でもアラートが来る。
最初は「しきい値が低すぎた」と思った。それは半分正解で、半分は違う。
混入していたもの
問題の本質はここだった。AzureポータルからApp Serviceの設定画面を開くと、ポータル自体がHTTPリクエストをサービスに投げる。そのリクエストが、実際のユーザートラフィックと区別されずにResponse Timeのメトリクスに計上される。
つまり、監視する行為がメトリクスを汚染していた。
これを「おかしくない？」と指摘されて初めて気づく人は多いと思う。私もそうだった。しきい値の話をする前に、そもそも何のリクエストがカウントされているかを見ないといけない。
誤検知の原因、2つに分かれる
整理するとこの2つどちらかが原因になっていることが多い。
1つ目は「メトリクスへの混入」。ポータルからのHTTPリクエスト、ヘルスチェック用のリクエスト、特定IPからの監視サービスのアクセスといった「本来の利用者ではないトラフィック」が応答時間の計算に入り込んでいるケース。
2つ目は「閾値と評価期間の設定が荒い」。評価期間が1分や2分だと、一瞬の負荷でも条件を満たしてしまう。集計粒度を細かくしすぎても同じ問題が起きる。
どちらを先に疑うかで、対応の順番が変わる。
切り分けの順番
まずメトリクスに何が混じっているかを確認する。
AIにこう頼んだ。
Azure App Serviceの応答時間メトリクスに、Azureポータルからのアクセスやヘルスチェック用リクエストが混入していないか調べたい。どのディメンションやフィルタ条件を見ればいいか、確認手順を教えて。
返ってきた内容をざっくりまとめると、メトリクスの設定画面でディメンション（URLやUser-Agent）を見ると、どの種別のリクエストが応答時間の計算に含まれているかが分かる。そこでポータル由来のリクエストが混じっていれば、それが誤検知の主因になっている。
フィルタの入れ方
混入しているリクエストを特定したら、メトリクスの条件からそれを除外する。
AIへの頼み方はこうだった。
Azure Monitorのメトリクスアラート設定で、特定のURLパスやUser-Agentが含まれるリクエストを除外したい。設定画面のどこでフィルタを入れるか、操作の流れを教えて。
ポータルのアラートルール画面でディメンションを追加して「含まない」条件を設定する、という流れになる。ヘルスチェック用のURLや、ポータル由来のUser-Agentを除外の対象に入れると、本来のユーザートラフィックだけが評価対象になる。
しきい値の調整はその後
混入を取り除いてから、改めて実際のトラフィックの応答時間の傾向を見る。ここで初めてしきい値の話になる。
具体的な設定の考え方として参考になったのはこのあたり。
- 集計粒度は1分より5分のほうが一時的な変動に振り回されにくい
- 評価期間は15分程度取る
- アラート条件を「1回でも超えたら」ではなく「3回連続で超えたら」にする
短い評価期間と低いしきい値の組み合わせは、正常な状態でも簡単に条件を満たしてしまう。そこでアラートを飛ばす意味はほとんどない。
監視設定の詰まり所
クラウドの監視設定は「とりあえず入れてみる」が通用しにくい。入れた直後から誤検知が続くと、担当者がアラートを無視するようになる。狼少年になるほうが、アラートがないより始末が悪い。
詰まりやすいのはこの順番で確認しないまま進めること。
- 何がメトリクスにカウントされているか（混入の確認）
- それをフィルタで除外するか、別ディメンションで分離する
- その上でしきい値と評価期間を決める
設定の見直しより先に「今の数値を信頼できるか」を問うのが最初の一歩になる。