活動合約
查詢期望的欄位
| 欄位 | 型別 | 為什麼存在 |
|---|---|---|
| timestamp_utc | Timestamp | 嘗試完成時間。 |
| job_id | Utf8 | 穩定的邏輯作業識別符號。 |
| job_name | Utf8 | 工作型別穩定。 |
| attempt | Int64 | 基於一的嘗試次數。 |
| status | Utf8 | 已完成、重試或失敗。 |
DataFusion SQL
複製查詢
sql
SELECT
date_trunc('hour', timestamp_utc) AS hour,
job_name,
COUNT(*) AS attempts,
COUNT(DISTINCT job_id) AS logical_jobs,
SUM(CASE WHEN attempt > 1 THEN 1 ELSE 0 END) AS retry_attempts,
100.0 * SUM(CASE WHEN attempt > 1 THEN 1 ELSE 0 END)
/ NULLIF(COUNT(*), 0) AS retry_attempt_rate_pct,
100.0 * SUM(CASE WHEN status = 'failed' THEN 1 ELSE 0 END)
/ NULLIF(COUNT(*), 0) AS failed_attempt_rate_pct
FROM job_attempts
WHERE timestamp_utc >= now() - INTERVAL '24 hours'
GROUP BY date_trunc('hour', timestamp_utc), job_name
HAVING COUNT(*) >= 20
ORDER BY retry_attempt_rate_pct DESC, attempts DESC;此只讀查詢是針對空型別資料表計劃和執行的 阿帕奇 DataFusion 45.2.0。確定性樣本輸出是綜合的並單獨審查;根據您自己的資料驗證欄位型別、閾值和業務定義。 閱讀測試方法。
查詢結果
按作業重試嘗試率
CRM 同步產生的嘗試遠多於邏輯作業,並且重複工作會消耗工作人員的能力。
sync_crm_accounts
60.76%
send_receipt_email
3.74%
| hour | job_name | attempts | logical_jobs | retry_attempts | retry_attempt_rate_pct | failed_attempt_rate_pct |
|---|---|---|---|---|---|---|
| 2026-07-27 14:00 | sync_crm_accounts | 1,840 | 492 | 1,118 | 60.76 | 22.34 |
| 2026-07-27 14:00 | send_receipt_email | 3,180 | 3,061 | 119 | 3.74 | 0.44 |
綜合範例輸出。在將其用於操作決策之前,針對您自己的事件架構和閾值執行查詢。
SQL 是如何工作的
- 1不同的作業 ID 估計有用的邏輯工作,而原始計數則衡量工人的嘗試。
- 2一次以上的嘗試會孤立重複的工作,而不會將最終的成功視為第一次嘗試。
- 3失敗率與重試共享保持一致,因此故意重試的瞬態依賴性可以與最終失敗區分開來。
需要決定的邊緣情況
- 扇出作業可以合法地建立多個子 ID;在比較計數之前定義邏輯工作識別符號。
- 立即重試和計劃退避具有不同的容量影響,並且可能需要單獨的欄位。
- 重試風暴可以在每小時的時段之間移動;當回應時間很重要時,新增較短的操作查詢。
推薦儀表板
- 酒吧:retry_attempt_rate_pct(按工作)
- 趨勢:嘗試和logical_jobs
- 資料表:嘗試次數最多和錯誤型別最新的作業
讓查詢範例發揮作用
相關埋點和指南
繼續分析
在真實事件中執行它
建立資料表,調整欄位並儲存結果
免費開始,傳送結構化事件,並將查詢結果用作圖表、共享儀表板小工具或警示輸入。