ステートレスアラートにあたるログ検索アラートのベストプラクティスについて

こんにちは 12G-4164,

潜在的なロジックの重複を特定されたことを理解しています. KQL クエリ内で TimeGenerated > ago(30m) のような時間範囲を定義し、さらにアラートルールの UI で集計粒度（参照期間）を設定すると、冗長なフィルタリングや評価ウィンドウの不一致が発生する可能性があります.アラートエンジンは、ルールで構成されたクエリ期間と集計を使用してクエリを評価しますが、KQL 内の手動時間フィルターは実際の評価ウィンドウと集計を変更し、重複アラートや誤ったカウントを生じさせることがあります.

• KQL のベストプラクティス: クエリはフィルタリングロジック（エラー、特定の ID、閾値）に集中させ、時間ベースのフィルターは除外してください.
• アラートルール UI を使用: Azure ポータルでクエリ期間と集計粒度の設定で時間ウィンドウを定義してください.
• 特殊な場合のみ: KQL の時間フィルターは特殊なクエリ（例えば、マルチウィンドウ結合）の場合に適しています. 標準的なステートレスアラートでは避けてください.

技術的には、システムを破壊するような意味で「競合」しているわけではありませんが、アラートルールのUI設定が最終的なフィルターとして機能します.

もしあなたのKQLクエリで where TimeGenerated > ago(1d) と指定していても、アラートルールが「過去5分」を対象に設定されている場合、アラートは最後の5分間のデータのみを評価します. スクリプト内の24時間の範囲は、実質的に無視されるか、アラートのポーリングウィンドウによって上書きされます

もしクエリで summarize count() by bin(TimeGenerated, 1h) を使用していても、アラートルールがデータを5分ごとに集計するよう設定されている場合、バケットが一致しないため、「データ不一致」エラーが発生したり、アラートが一度も発火しない可能性があります.

Microsoftがこの上書きを導入した主な理由は、エラーを防ぐためです. ユーザーがワークブックからクエリをコピーして、| where TimeGenerated > ago(24h) のように固定値が入っている場合、アラートルールを「過去5分」に設定すると、アラートが失敗したり、結果が一貫しなくなる可能性があります. この上書きにより、エンジンはKQLの内部時計を無視し、代わりにUIの時計に従うよう強制されます.

クエリが過去30分を参照している場合でも、ルールが5分ごとに実行されると、同じエラーログが複数回アラートされる可能性があります. 検索内容（KQL）と検索頻度（ルール設定）を分けることで、Azureはバックエンドスキャンを最適化でき、これらの最適化を回避することを防げます. ステートレスアラートを正しく構成するには、次の手順に従ってください：

1. TimeGeneratedフィルターなしでクエリを作成します. 例：Syslog | where SeverityLevel == "Error"
2. MeasurementまたはRule設定で、集計の粒度を希望のウィンドウに設定します（例：5分）.
3. 評価頻度を設定します（例：5分ごと）
4. リガー条件を定義します（例：Count > 0）. 標準アラートでは、Override query period rangeを使用する必要はありません. 時間に関連するロジックはAlert Ruleの設定で管理し、KQLは時間に依存しないようにしてください. 同じ時間ウィンドウでログ内のクエリを実行し、アラート結果をプレビューして検証してください.

Azure Monitor の警告の概要 - Azure Monitor | Microsoft Learn

お役に立てれば幸いです. さらにご質問があれば、どうぞお気軽にご連絡ください. ありがとうございます