共同事件契約
使這些查詢可重用的欄位
- timestamp_utc、route_template、方法和 status_code
- latency_ms、request_id、版本、環境和依賴項
- 當客戶影響分析獲得批准時為 team_id 或 account_id
SQL 之前的定義
查詢無法為您做出的決定
- 1在計算比率之前定義哪些回應算作失敗。
- 2設定最小請求量，以便安靜的路由不會占主導地位。
- 3保持路線範本和版本足夠穩定，以便隨著時間的推移進行比較。
推薦順序
先建立檢測，然後診斷
分析模式
讓結果解釋決定
按請求量標準化
配對失敗會根據速率和最小流量閾值進行計數，因此安靜的路由無法超越真正有風險的端點。
比較穩定的尺寸
按路由範本、版本、依賴項或環境而不是原始 URL 和其他無界值進行分組。
將檢測與影響聯絡起來
從服務級別更改開始，然後確定促成此更改的客戶、版本和依賴項。
完整的查詢範例
複製查詢，然後驗證假設
按路由計算API錯誤率
使用 SQL 按 5xx 錯誤率對 API 路由進行排名，同時保護結果免受低音量噪音的影響。
哪些 API 路由具有最高的有意義 5xx 錯誤率？
檢視 SQL 和結果計算 p50、p95 和 p99 API 延遲
使用 DataFusion 相容的百分位數 SQL 按端點比較中值和尾部延遲。
哪些端點的尾部延遲最差？
檢視 SQL 和結果計算 API 錯誤預算消耗率
將每小時的請求失敗轉化為 SLO 消耗率系列，顯示允許的錯誤預算消耗的速度。
API 消耗其 99.9% 可用性預算的速度有多快？
檢視 SQL 和結果按版本比較 API 可靠性
比較跨應用程式版本的流量、5xx 速率和 p95 延遲，無需將每個部署後更改都歸因於部署。
哪些版本會出現更嚴重的 API 錯誤或尾部延遲？
檢視 SQL 和結果按客戶影響對錯誤指紋進行排名
按發生次數和受影響的帳戶對標準化應用程式錯誤進行排名，而不是讓一個重試迴圈主導事件檢視。
哪些錯誤組影響最多的客戶帳戶？
檢視 SQL 和結果按路由計算API超時率
按超時率對路由進行排名，同時保留請求量和設定的超時邊界。
哪些 API 路由超時的頻率足以影響使用者？
檢視 SQL 和結果比較依賴性 p95 延遲
查詢對請求造成最大尾部延遲的資料庫、API、快取和佇列。
哪些下游依賴項的尾部延遲和故障率最差？
檢視 SQL 和結果根據 SLO 衡量 API 可用性
計算每日可用性並顯示服務是否達到其明確的目標。
每項服務是否達到其每日可用性目標？
檢視 SQL 和結果按路由計算 API 請求吞吐量
透過穩定的 API 路由計算觀察到的每分鐘請求數，並在吞吐量旁邊保留錯誤量。
哪些 API 路由每分鐘處理的請求最多？
檢視 SQL 和結果測量 API 429 速率限制恢復
測量速率限制請求在稍後嘗試中恢復的頻率，而不將每次重試都視為新請求。
收到 HTTP 429 的請求重試後能否成功恢復？
檢視 SQL 和結果比較功能推出錯誤率
比較一個版本的功能標記部署和控制組之間的請求錯誤和平均延遲。
功能標誌的推出是否不如其對照群體可靠？
檢視 SQL 和結果按計劃衡量事件對客戶的影響
按計劃計算受影響的帳戶和平均影響持續時間，而無需暴露客戶名稱或原始請求資料。
每個計劃中有多少個帳戶受到該事件的影響？
檢視 SQL 和結果