活動合約
查詢期望的欄位
| 欄位 | 型別 | 為什麼存在 |
|---|---|---|
| timestamp_utc | Timestamp | 當事件發生在生產者中時。 |
| received_at | Timestamp | 當攝取服務接受事件時。 |
| source | Utf8 | 穩定的生產者或工作流程名稱。 |
| environment | Utf8 | 部署環境。 |
DataFusion SQL
複製查詢
sql
SELECT
source,
MAX(timestamp_utc) AS latest_event_at,
MAX(received_at) AS latest_received_at,
date_part('second', now() - MAX(received_at)) / 60.0
AS minutes_since_receive,
AVG(date_part('second', received_at - timestamp_utc)) / 60.0
AS average_delivery_delay_minutes
FROM telemetry_events
WHERE received_at >= now() - INTERVAL '24 hours'
AND environment = 'production'
GROUP BY source
ORDER BY minutes_since_receive DESC;此只讀查詢是針對空型別資料表計劃和執行的 阿帕奇 DataFusion 45.2.0。確定性樣本輸出是綜合的並單獨審查;根據您自己的資料驗證欄位型別、閾值和業務定義。 閱讀測試方法。
查詢結果
自最新收到事件以來的分鐘數
儘管正常的交付延遲很小,但計費同步已過時。
billing_sync
48 min
comparison 1.4 min
api_gateway
1 min
comparison 0.1 min
queue_workers
1 min
comparison 0.8 min
| source | latest_event_at | latest_received_at | minutes_since_receive | average_delivery_delay_minutes |
|---|---|---|---|---|
| billing_sync | 2026-07-27 12:11 | 2026-07-27 12:12 | 48 | 1.4 |
| api_gateway | 2026-07-27 12:59 | 2026-07-27 12:59 | 1 | 0.1 |
| queue_workers | 2026-07-27 12:58 | 2026-07-27 12:59 | 1 | 0.8 |
綜合範例輸出。在將其用於操作決策之前,針對您自己的事件架構和閾值執行查詢。
SQL 是如何工作的
- 1MAX(received_at) 測量每個源是否仍在傳送資料。
- 2received_at 和 timestamp_utc 之間的平均差異測量傳輸延遲與源靜默分開。
- 3生產過濾器可防止開發流量使已停止的生產源看起來正常。
需要決定的邊緣情況
- 每天僅發出一次的源需要與 API 源不同的新鮮度閾值。
- 生產者時鐘偏差會使交付延遲為負值;監視並糾正時鐘同步。
- 24 小時回溯無法返回靜默時間超過視窗時間的源。保留預期來源登錄檔以進行缺勤監控。
推薦儀表板
- 條形圖:minutes_since_receive(按來源)
- 趨勢:按來源劃分的平均交付延遲
- 資料表:當前視窗中缺少的預期來源
讓查詢範例發揮作用
相關埋點和指南
定義源資料
此分析的事件模式
繼續分析
在真實事件中執行它
建立資料表,調整欄位並儲存結果
免費開始,傳送結構化事件,並將查詢結果用作圖表、共享儀表板小工具或警示輸入。