活動合約
查詢期望的欄位
| 欄位 | 型別 | 為什麼存在 |
|---|---|---|
| timestamp_utc | Timestamp | 請求完成時間(UTC)。 |
| status_code | Int64 | HTTP 回應狀態程式碼。 |
| environment | Utf8 | 部署環境。 |
DataFusion SQL
複製查詢
sql
WITH hourly AS (
SELECT
date_trunc('hour', timestamp_utc) AS hour,
COUNT(*) AS requests,
SUM(CASE WHEN status_code >= 500 THEN 1 ELSE 0 END) AS bad_requests
FROM api_requests
WHERE timestamp_utc >= now() - INTERVAL '24 hours'
AND environment = 'production'
GROUP BY date_trunc('hour', timestamp_utc)
)
SELECT
hour,
requests,
bad_requests,
100.0 * bad_requests / NULLIF(requests, 0) AS error_rate_pct,
(1.0 * bad_requests / NULLIF(requests, 0)) / 0.001 AS burn_rate
FROM hourly
ORDER BY hour;此只讀查詢是針對空型別資料表計劃和執行的 阿帕奇 DataFusion 45.2.0。確定性樣本輸出是綜合的並單獨審查;根據您自己的資料驗證欄位型別、閾值和業務定義。 閱讀測試方法。
查詢結果
每小時誤差-預算消耗率
13:00 時段消耗的預算是可持續比率的 3.72 倍。
12:00
0.49×
13:00
3.72×
14:00
1.28×
| hour | requests | bad_requests | error_rate_pct | burn_rate |
|---|---|---|---|---|
| 12:00 | 18,420 | 9 | 0.05 | 0.49 |
| 13:00 | 19,110 | 71 | 0.37 | 3.72 |
| 14:00 | 18,780 | 24 | 0.13 | 1.28 |
綜合範例輸出。在將其用於操作決策之前,針對您自己的事件架構和閾值執行查詢。
SQL 是如何工作的
- 199.9% 的成功目標允許 0.1% 或 0.001 的不良請求率。
- 2將觀察到的比率除以 0.001 得出燃燒率:1× 完全是可持續的,而 3× 則消耗預算的速度太快了三倍。
- 3CTE 使請求分母保持可見,因此可以單獨處理小桶。
需要決定的邊緣情況
- 定義哪些狀態程式碼對於面向使用者的 SLI 來說是錯誤的;並非每個 5xx 都有相同的影響。
- 使用多視窗警示進行生產尋呼,而不是一個嘈雜的每小時閾值。
- 僅當 SLO 定義明確排除綜合檢查或內部流量時,才排除它們。
推薦儀表板
- 趨勢:burn_rate(按小時)
- 統計:每月剩餘錯誤預算
- 資料表:造成最壞請求的路由
讓查詢範例發揮作用
相關埋點和指南
繼續分析
在真實事件中執行它
建立資料表,調整欄位並儲存結果
免費開始,傳送結構化事件,並將查詢結果用作圖表、共享儀表板小工具或警示輸入。