活動合約
查詢期望的欄位
| 欄位 | 型別 | 為什麼存在 |
|---|---|---|
| timestamp_utc | Timestamp | 作業生命週期事件時間。 |
| job_id | Utf8 | 穩定的邏輯作業識別符號。 |
| queue_name | Utf8 | 擁有該作業的佇列。 |
| event_name | Utf8 | dead_letter_created 或 dead_letter_resolved。 |
| error_type | Utf8 | 分類終端故障。 |
DataFusion SQL
複製查詢
sql
SELECT
date_trunc('day', timestamp_utc) AS day,
queue_name,
SUM(CASE
WHEN event_name = 'dead_letter_created' THEN 1 ELSE 0
END) AS created_jobs,
SUM(CASE
WHEN event_name = 'dead_letter_resolved' THEN 1 ELSE 0
END) AS resolved_jobs,
SUM(CASE
WHEN event_name = 'dead_letter_created' THEN 1
WHEN event_name = 'dead_letter_resolved' THEN -1
ELSE 0
END) AS net_queue_change
FROM job_events
WHERE timestamp_utc >= now() - INTERVAL '30 days'
AND event_name IN ('dead_letter_created', 'dead_letter_resolved')
GROUP BY date_trunc('day', timestamp_utc), queue_name
ORDER BY day, queue_name;此只讀查詢是針對空型別資料表計劃和執行的 阿帕奇 DataFusion 45.2.0。確定性樣本輸出是綜合的並單獨審查;根據您自己的資料驗證欄位型別、閾值和業務定義。 閱讀測試方法。
查詢結果
建立和解決死信作業
7 月 26 日,Billing 累計增加了 22 個死信職位,而進口則減少了排隊人數。
2026-07-25
18
16
2026-07-26
31
9
2026-07-27
12
14
| day | queue_name | created_jobs | resolved_jobs | net_queue_change |
|---|---|---|---|---|
| 2026-07-25 | billing | 18 | 16 | 2 |
| 2026-07-26 | billing | 31 | 9 | 22 |
| 2026-07-27 | imports | 12 | 14 | -2 |
綜合範例輸出。在將其用於操作決策之前,針對您自己的事件架構和閾值執行查詢。
SQL 是如何工作的
- 1建立的事件和已解決的事件保持獨立,因此相同的淨變化無法隱藏截然不同的操作工作負載。
- 2簽署的淨變化暴露了未解決工作累積的天數。
- 3按佇列分組可以保持所有權和升級路徑清晰。
需要決定的邊緣情況
- 在邏輯作業達到記錄的最終成功或放棄結果之前,重試並不是解決方案。
- 回填的生命週期事件可以改變歷史網路移動。
- 單獨追蹤當前佇列庫存或根據已知的期初餘額計算累計總和。
推薦儀表板
- 堆疊條:按佇列排列的 created_jobs 和 resolved_jobs
- 趨勢:累積死信庫存
- 資料表:error_type 最早的未解決作業
讓查詢範例發揮作用
相關埋點和指南
繼續分析
在真實事件中執行它
建立資料表,調整欄位並儲存結果
免費開始,傳送結構化事件,並將查詢結果用作圖表、共享儀表板小工具或警示輸入。