使用 SQL 進行 SLI、SLO 和錯誤預算監控
服務級別指標 (SLI) 衡量使用者體驗的結果。服務級別目標 (SLO) 在定義的視窗內設定該指標的目標。錯誤預算是目標隱含的允許失敗量。
從有限的應用程式結果開始，例如 API 請求、結帳、作業或 Webhook 交付。基礎設施可用性是有用的背景，但健康的主機並不能證明客戶工作流程成功。
定義事件契約
對於基於請求的可用性 SLI，請使用以下命令發出一個終端事件：
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)
除了百分比之外，還要進行計數。兩個請求的失敗率為 50%，一百萬個請求的失敗率為 2%，需要不同的解釋。
監控燃燒率
燃燒率將觀察到的不良事件分數與允許的不良事件分數進行比較。 1 的消耗率完全按照計劃的速度消耗預算。高於 1 的燃燒率會消耗掉它太快。
錯誤預算燃燒配方 計算時間段內的值。將一個短視窗與一個較長的視窗配對，該視窗可以檢測快速事件，該視窗可以防止一個嘈雜的桶對團隊進行尋呼。
除非查詢明確考慮部分資料，否則不要對最新的不完整時間段發出警示。觸發前需要最低合格交易量和持續評估點。
新增延遲和工作流程 SLI
可用性只是一種使用者可見的屬性。請求可能會在出現不可接受的延遲後成功。將延遲 SLI 定義為低於審查閾值的合格請求的比例，或使用 API 延遲百分位數配方 檢查 p95 和 p99。
對於後台作業和 Webhooks，請圍繞終端業務成果而不是個人嘗試來定義成功。恢復的重試可能會消耗延遲預算，而不算作終端故障。保持嘗試級診斷可用，而不會誇大 SLI 分母。
建置儀表板和警示路徑
將這些檢視放在一起：
- 合格的請求量和資料新鮮度。
- 完整滾動視窗的 SLO 合規性。
- 短窗和長窗燃燒率。
- 按路線、版本和錯誤型別劃分的故障細分。
- 用於客戶影響調查的近期事件資料表。
新增操作註釋，其中列出所有者、目標、分母、排除和回應操作。按照 警示指南 進行評估行為，按照 事件回應指南 進行調查流程。
分頁前驗證
重播包含已知成功、失敗、排除事件和不完整的最新儲存桶的賽程。確認確切的合格數量、允許的故障、合規性和燃燒率。然後在附加待命回應之前觀察沒有通知的警示。