活動合約
查詢期望的欄位
| 欄位 | 型別 | 為什麼存在 |
|---|---|---|
| timestamp_utc | Timestamp | 執行完成時間。 |
| job_name | Utf8 | 穩定的邏輯作業名稱。 |
| queue_wait_ms | Float64 | 從計劃到開始的毫秒數。 |
| duration_ms | Float64 | 啟動後的執行持續時間。 |
DataFusion SQL
複製查詢
sql
SELECT
job_name,
COUNT(*) AS runs,
approx_percentile_cont(queue_wait_ms, 0.50) AS p50_wait_ms,
approx_percentile_cont(queue_wait_ms, 0.95) AS p95_wait_ms,
approx_percentile_cont(duration_ms, 0.95) AS p95_run_ms
FROM job_runs
WHERE timestamp_utc >= now() - INTERVAL '24 hours'
GROUP BY job_name
HAVING COUNT(*) >= 20
ORDER BY p95_wait_ms DESC;此只讀查詢是針對空型別資料表計劃和執行的 阿帕奇 DataFusion 45.2.0。確定性樣本輸出是綜合的並單獨審查；根據您自己的資料驗證欄位型別、閾值和業務定義。 閱讀測試方法。
查詢結果
p95 按作業排隊等待
報告生成的等待時間大約是 p95 執行時間的兩倍。
generate_report
44,200 ms
comparison 21,800 ms
sync_subscription
7,200 ms
comparison 8,400 ms
send_email
460 ms
comparison 930 ms
| job_name | runs | p50_wait_ms | p95_wait_ms | p95_run_ms |
|---|---|---|---|---|
| generate_report | 340 | 1,800 | 44,200 | 21,800 |
| sync_subscription | 980 | 420 | 7,200 | 8,400 |
| send_email | 12,400 | 80 | 460 | 930 |
綜合範例輸出。在將其用於操作決策之前，針對您自己的事件架構和閾值執行查詢。
SQL 是如何工作的
- 1佇列等待在工作安排時開始，在執行開始時結束。
- 2p50 到 p95 的差距將持續緩慢的佇列與間歇性的積壓區分開來。
- 3將 p95 等待時間與 p95 執行時間進行比較可以看出容量或作業程式碼是否是更大的貢獻者。
需要決定的邊緣情況
- 使用一個時鐘或 UTC 時間戳作為計劃時間和開始時間。
- 計劃的 cron 延遲和佇列延遲可能需要單獨的欄位。
- 重試應保留嘗試次數，以便可以隔離重複的工作。
推薦儀表板
- 酒吧：p50和p95按工作等待
- 趨勢：p95 排隊等候
- 資料表：當前排隊的最舊專案
讓查詢範例發揮作用
相關埋點和指南
定義源資料
此分析的事件模式
繼續分析
在真實事件中執行它
建立資料表，調整欄位並儲存結果
免費開始，傳送結構化事件，並將查詢結果用作圖表、共享儀表板小工具或警示輸入。