SQL による SLI、SLO、およびエラー バジェットのモニタリング

サービス レベル インジケーター (SLI) は、ユーザー エクスペリエンスの結果を測定します。サービス レベル目標 (SLO) は、定義された期間にわたってその指標の目標を設定します。エラーバジェットは、目標によって暗示される許容される失敗の量です。

API リクエスト、チェックアウト、ジョブ、Webhook 配信などの、制限されたアプリケーションの結果から始めます。インフラストラクチャの可用性は有用なコンテキストですが、ホストが正常であっても、顧客のワークフローが成功したことを証明するものではありません。

イベントコントラクトを定義する

リクエストベースの可用性 SLI の場合、次のコマンドを使用して 1 つのターミナル イベントを発行します。

• event_id;
• timestamp_utc;
• service そして route_template;
• status そして status_code;
• latency_ms;
• environment そして release;
• 制御された error_type;
• オプションの金庫 account_id 影響分析用。

書類の資格。ヘルスチェック、合成トラフィック、キャンセルされたリクエスト、予期されるクライアントエラーは、分母に含まれる場合と含まれない場合があります。決定は、クエリ、ダッシュボード、アラート全体で一貫している必要があります。

可用性のコンプライアンスを計算する

の SLO 可用性 SQL レシピ 適格なリクエスト、良いリクエスト、悪いリクエスト、および準拠率を区別します。完全な観察ウィンドウとレビュー済みの良好なイベント定義とともに使用します。

99.9% の目標の場合、許容される不良率は次のとおりです。 0.001。リクエストで測定されるエラー バジェットは次のとおりです。

eligible_requests * (1 - objective)

パーセンテージの横にカウントを置きます。 2 つのリクエストによる 50% の失敗率と、100 万件のリクエストによる 2% の失敗率では、異なる解釈が必要です。

燃焼速度を監視する

バーン レートは、観察された不良イベントの割合と許容される不良の割合を比較します。燃焼速度 1 計画どおりに予算を消費します。以上の燃焼速度 1 消費するのが早すぎます。

の エラーバジェットバーンレシピ 時間経過に伴うバケットの値を計算します。迅速なインシデントを検出する短いウィンドウと、1 つのノイズの多いバケットがチームにページングするのを防ぐ長いウィンドウを組み合わせます。

クエリが部分データを明示的に考慮していない限り、最新の不完全なタイム バケットについてはアラートを発行しません。トリガーする前に、最小適格ボリュームと継続的な評価ポイントが必要です。

レイテンシとワークフロー SLI を追加する

可用性は、ユーザーに表示されるプロパティの 1 つにすぎません。許容できない遅延が発生しても、リクエストは成功する可能性があります。 レイテンシSLIは、レビュー済みしきい値を下回る対象リクエストの割合として定義するか、次を確認します: p95 and p99 with the API レイテンシ パーセンタイル レシピ.

バックグラウンド ジョブと Webhook については、個別の試みではなく、最終的なビジネスの結果に基づいて成功を定義します。回復された再試行は、端末障害としてカウントされずに遅延バジェットを消費する可能性があります。 SLI の分母を大きくすることなく、試行レベルの診断を利用可能な状態に保ちます。

ダッシュボードとアラート パスを構築する

これらのビューを一緒に配置します。

1. 対象となるリクエストの量とデータの鮮度。
2. 完全なローリング ウィンドウに対する SLO 準拠。
3. ショートウィンドウとロングウィンドウの燃焼速度。
4. ルート、リリース、エラー タイプごとの障害の内訳。
5. 顧客への影響を調査するための最近のイベント表。

所有者、目的、分母、除外、および対応アクションの名前を記載した運用メモを追加します。フォローしてください アラートガイド 評価行動と インシデント対応ガイド 調査の流れについて。

ページングの前に検証する

既知の成功、失敗、除外されたイベント、および不完全な最新のバケットを含むフィクスチャを再生します。正確な対象数、許容される失敗数、コンプライアンス、および書き込み速度を確認します。次に、オンコール応答を添付する前に、通知なしでアラートを観察します。