活動合約
查詢期望的欄位
| 欄位 | 型別 | 為什麼存在 |
|---|---|---|
| timestamp_utc | Timestamp | 請求完成時間(UTC)。 |
| route_template | Utf8 | 穩定的路線範本。 |
| latency_ms | Float64 | 請求持續時間(以毫秒為單位)。 |
| status_code | Int64 | HTTP 回應狀態程式碼。 |
DataFusion SQL
複製查詢
sql
SELECT
route_template,
COUNT(*) AS requests,
approx_percentile_cont(latency_ms, 0.50) AS p50_ms,
approx_percentile_cont(latency_ms, 0.95) AS p95_ms,
approx_percentile_cont(latency_ms, 0.99) AS p99_ms
FROM api_requests
WHERE timestamp_utc >= now() - INTERVAL '24 hours'
AND status_code < 500
GROUP BY route_template
HAVING COUNT(*) >= 50
ORDER BY p95_ms DESC
LIMIT 10;此只讀查詢是針對空型別資料表計劃和執行的 阿帕奇 DataFusion 45.2.0。確定性樣本輸出是綜合的並單獨審查;根據您自己的資料驗證欄位型別、閾值和業務定義。 閱讀測試方法。
查詢結果
按路線劃分的 p95 延遲
匯出請求的尾部最慢,典型情況和最壞情況效能之間的差距最大。
/api/reports/export
800 ms
comparison 800 ms
/api/projects/:id/sync
320 ms
comparison 320 ms
/api/search
120 ms
comparison 120 ms
| route_template | requests | p50_ms | p95_ms | p99_ms |
|---|---|---|---|---|
| /api/reports/export | 50 | 800 | 800 | 800 |
| /api/projects/:id/sync | 50 | 320 | 320 | 320 |
| /api/search | 50 | 120 | 120 | 120 |
綜合範例輸出。在將其用於操作決策之前,針對您自己的事件架構和閾值執行查詢。
SQL 是如何工作的
- 1approx_percentile_cont 使用 DataFusion 的 t-digest 實現,這對於大型事件資料表非常有效。
- 2過濾掉 5xx 回應使其成為成功請求延遲檢視。當失敗持續時間很重要時,建立單獨的失敗請求檢視。
- 3p50 和 p95 之間的差異通常比單獨的任何一個數字更有用:較大的差距表明間歇性的慢速路徑。
需要決定的邊緣情況
- 在不保留路由上下文的情況下,不要將端點與根本不同的工作進行比較。
- 流媒體路由和長期執行的匯出可能需要單獨的服務級別目標。
- 將延遲保持在一致的單位並使用數字欄位。
推薦儀表板
- 分組條:p50_ms 和 p95_ms by route_template
- 折線圖:最慢路線隨時間變化的 p95_ms
- 資料表:路線 p99 以上的個人請求
讓查詢範例發揮作用
相關埋點和指南
定義源資料
此分析的事件模式
繼續分析
在真實事件中執行它
建立資料表,調整欄位並儲存結果
免費開始,傳送結構化事件,並將查詢結果用作圖表、共享儀表板小工具或警示輸入。