Telemetry が SQL アラートを評価する方法
有用なアラートは、チャートに関連付けられたしきい値を超えるものです。評価者は、クエリの期限、どの SQL を実行するか、どの行をカウントするか、それらの行を 1 つの値に減らす方法、状態が変化したかどうか、いつ通知するかを決定する必要があります。
このガイドでは、Telemetry によって実装される評価パスについて説明します。これは検査可能な動作の説明であり、稼働時間、遅延、配信の保証ではありません。
アラート入力モデル: 1 つの時系列信号
Telemetry のアラート作成ワークフローは、意図的に 1 行から開始します。つまり、順序付けされた時間軸、1 つの数値軸であり、グループ化や分割ディメンションはありません。 Explore には折れ線グラフが必要です。 分割。 SQL の結果には、明示的な時間の X 軸、数値の Y 軸、および グループ化 に設定 なし.
この制約により、評価者の入力が理解しやすくなります。各結果行は 1 つの時点であり、選択されたメトリックには 1 つの意味と単位があり、構成されたしきい値によって 1 つのアラート状態が生成されます。複数シリーズの結果には、追加のポリシーが必要になります。つまり、一部またはすべてのシリーズが状態を制御するかどうか、各シリーズが独立した履歴を所有するかどうか、通知がどのようにグループ化されるか、欠落しているシリーズまたは新しく表示されるシリーズが何を意味するかなどです。 Telemetry は、それらのセマンティクスを暗黙的に発明することを回避します。
信号を計算する SQL は依然として複雑になる可能性があります。テーブルを結合したり、特定のサービスまたはルートにフィルタリングしたり、比率を計算したり、最小サンプル サイズを強制したりできます。アラートに公開される最終結果は、行ごとに 1 つのタイム バケットと 1 つの数値シグナルという単純なものである必要があります。ダッシュボード上でグループ化された比較を維持することも、各グループに独自のしきい値、所有者、応答がある場合は個別のアラートを作成することもできます。
評価シーケンス
評価者は、連鎖した 1 分間のスケジューリング ループを使用します。各パスは、有効なアラートをロードし、分離された障害処理と同時にそれらを評価し、パスの結果を記録し、現在のパスの終了後に次のパスをスケジュールします。 1 分間のループはポーリング周期です。各アラートには依然として独自に設定された間隔があります。
有効になっているすべてのアラートについて:
- 最後の評価時刻と構成された間隔から、アラートの期限が切れているかどうかを確認します。
- 別の評価者が同じバージョンを同時に要求できないように、現在のバージョンを使用してアラートを要求します。
- クエリを解決します。保存されている正確な SQL をクエリに基づくアラートに使用するか、保存されている Explore 構成から SQL を再生成します。
- 書き込みステートメントを含むクエリベースの SQL を拒否します。
- クエリを実行し、結果の列と行を検査します。
- 必要に応じて、不完全なタイム バケットを表す最新の行を削除します。
- 構成された最近のポイント数を取得し、それらを 1 つの観測値に集約します。
- その値をしきい値および演算子と比較します。
- 新しい状態、観測値、評価時間、および制御されたエラーを保存します。
- 履歴を追加し、状態が遷移した場合にのみ電子メールの配信を試みます。
この順序はトラブルシューティングの際に重要です。有効なクエリが依然として使用可能な値を生成しない可能性があり、使用可能な値がしきい値を下回ったままになる可能性があり、アラートがすでに発生しているときにしきい値に違反しても沈黙したままになる可能性があります。
保存されたクエリと探索ソース
クエリベースのアラートは、アラートとともに保存された SQL を実行します。エバリュエーターは、それを新しいクエリ リビジョンにサイレントに置き換えることはありません。ダッシュボードとアラートが一致しないように見える場合は、アラートに添付されている SQL を確認してください。
Explore ベースのアラートは、Explore 構成を保存し、Explore で使用されるのと同じクエリ構築境界を通じて SQL を再生成します。したがって、スキーマ、フィルター、グループ化、または集計への変更は、保存された構成が引き続き解決されるかどうかに影響を与える可能性があります。
書き込み指向のステートメントは、クエリベースのアラートでは拒否されます。アラートは結果を観察することを目的としており、テーブルや管理状態を変更するものではありません。 SQL が読み取り専用の場合でも、時間と結果のサイズによって制限されたアラート SQL を維持します。
最新点除外
時間バケットのクエリでは、未完了の現在バケットが先頭に返されることがよくあります.その部分的な分または時間と完全な履歴バケットを比較すると、誤った回復または誤った侵害シグナルが作成される可能性があります。
いつ exclude latest incomplete point が有効な場合、エバリュエーターは、構成されたポイント数を選択する前に、行を最も新しいものから順にソートし、最も新しい結果行を削除します。この設定が正しいのは、各行が実際にタイム バケットを表し、最新の行が不完全である場合に限られます。
次のような単一行の集計に対しては有効にしないでください。
SELECT
100.0 * SUM(CASE WHEN status = 'failed' THEN 1 ELSE 0 END) / COUNT(*) AS failure_rate
FROM background_job_completed
WHERE completed_at >= now() - INTERVAL '15 minutes';
唯一の行を削除すると、評価する値が残りません。時系列の場合は、明示的なバケット列と 1 つの数値列を返します。
SELECT
date_bin(INTERVAL '5 minutes', completed_at, TIMESTAMP '1970-01-01') AS bucket,
100.0 * SUM(CASE WHEN status = 'failed' THEN 1 ELSE 0 END) / COUNT(*) AS failure_rate
FROM background_job_completed
WHERE completed_at >= now() - INTERVAL '35 minutes'
GROUP BY bucket
ORDER BY bucket DESC;
ポイントの選択と集計
最新ポイントの処理後、エバリュエーターは構成された数の最近の行を取得します。選択された数値を抽出し、アラート集計設定を使用してそれらのポイントを削減します。
SQL がすでに完全な決定ウィンドウを計算している場合は、単一ポイントを使用します。 複数のバケットにわたる継続を意図したアラートでは、複数のデータポイントを使用してください.集計は運用上の質問と一致する必要があります。
maximum選択したポイントが違反したかどうかを尋ねます。minimum選択したすべての点が床の上にあったかどうかを尋ねます。average短いバリエーションを滑らかにしますが、重大な点が 1 つ隠れてしまう可能性があります。sum重複しないバケット全体で累積されたカウントを適合させます。latest残っている最新の完全なポイントを使用します。
この選択を応答手順に文書化します。 「5 を超える故障率」という表現は、それが最新の 5 分間のバケットを意味するのか、3 つのバケットの平均を意味するのか、あるいはそれらのバケットの最大値を意味するのかをチームが認識しない限り、あいまいです。
状態遷移と通知
Telemetry は、単一の評価とは別にアラート状態を保存します。評価が成功すると、次のような成果が得られます。 ok または firing;実行、抽出、または構成の問題によりエラー結果が生成されます。
履歴と通知は移行指向です。からの動き ok に firing トリガートランジションを作成します。からの動き firing に ok 解像度の遷移を作成します。同じ状態で評価を繰り返すと、ポーリング パスごとに同じ移行電子メールを送信しなくても、評価レコードが更新されます。
この評価者に対する現在の通知配信は電子メールです。状態遷移が保存された後に配信が試行されます。配信の失敗によって、アラートが移行したという事実が消去されてはなりません。そのため、アラートの履歴と電子メールの配信を個別に調査する必要があります。
同時実行性とクレームの動作
各アラートは、現在のバージョンを使用してオプティミスティック同時実行で要求されます。バージョンが変更されている場合、または別の評価者がそのバージョンをすでに主張している場合、その主張は成功しません。これにより、2 人の評価者が故意に同じアラート バージョンを同時に処理することが防止されます。
スケジューラは、解決済みの Promise を使用して有効なアラート セットを評価するため、1 つのアラートが拒否されても、そのパス内の残りのアラートの完了が妨げられることはありません。このループは、現在のパスが安定した後にのみ次のパスをスケジュールし、1 つのプロセス内でパスが重複することを回避します。
これらのコントロールは、評価者の動作を説明します。これらは分散サービスの可用性を主張するものではありません。導入トポロジ、プロセスの再起動、電子メールプロバイダーの動作、および将来の実装変更は引き続き運用レビューに含まれます。
トラブルシューティングのチェックリスト
アラートが期待どおりに動作しない場合:
- 添付されているとおりの SQL を実行し、読み取り専用であることを確認します。
- 選択した値列が数値であり、関連するすべての行に存在することを確認します。
- 結果の順序を検査します。最新ポイントのロジックは、どの行が最新であるかを知ることに依存します。
- クエリが 1 つの集計行を返すか、複数の時間バケットを返すかを確認します。
- レビュー
exclude latest incomplete point、ポイント数、および集計を一緒に行います。 - 演算子としきい値が選択した値と同じ単位を使用していることを確認します。
- 最新の状態遷移と制御されたエラーについては、アラート履歴を確認してください。
- クエリ/評価の失敗を電子メール配信の失敗から分離します。
- アラートが有効になっていること、および設定された間隔に十分な時間が経過していることを確認します。
- しきい値の両側で合成イベント フィクスチャを使用してテストします。
配送固有の調査については、次の手順に進みます。 アラート配信のトラブルシューティング。イベントとクエリの設計には、次を使用します。 アラート そして 最初のダッシュボードとアラートを作成する.
解釈境界
評価者は、設定された決定を一貫して実行できますが、ビジネス定義が正しいかどうかを判断することはできません。イベント粒度、分母、時間枠、しきい値、欠損データ ポリシー、および応答所有者は、アラート コントラクトの一部のままです。
スキーマの変更、クエリの編集、リリースの変更、トラフィックの変化、インシデントの振り返りの後にアラートを再確認します。古いしきい値または分母を持つ技術的に機能するアラートは、依然として信頼性の低いアラートです。