活動合約
查詢期望的欄位
| 欄位 | 型別 | 為什麼存在 |
|---|---|---|
| timestamp_utc | Timestamp | 當訊息來源稱事件發生時。 |
| received_at | Timestamp | 當Telemetry收到事件時。 |
| source | Utf8 | 生產者或攝取路徑。 |
| event_name | Utf8 | 穩定事件合約名稱。 |
DataFusion SQL
複製查詢
sql
SELECT
source,
event_name,
COUNT(*) AS events,
AVG(date_part('second', received_at - timestamp_utc)) / 60.0
AS average_delay_minutes,
approx_percentile_cont(
date_part('second', received_at - timestamp_utc) / 60.0,
0.95
) AS p95_delay_minutes,
SUM(CASE
WHEN received_at - timestamp_utc > INTERVAL '15 minutes' THEN 1
ELSE 0
END) AS events_over_15_minutes
FROM ingestion_events
WHERE received_at >= now() - INTERVAL '24 hours'
AND received_at >= timestamp_utc
GROUP BY source, event_name
HAVING COUNT(*) >= 20
ORDER BY p95_delay_minutes DESC;此只讀查詢是針對空型別資料表計劃和執行的 阿帕奇 DataFusion 45.2.0。確定性樣本輸出是綜合的並單獨審查;根據您自己的資料驗證欄位型別、閾值和業務定義。 閱讀測試方法。
查詢結果
p95 事件傳遞延遲
離線移動同步是即時的,但會定期傳送舊事件,這些事件可能會更改最近的產品組。
mobile_offline_sync
96.2 min
billing_webhook
4.8 min
| source | event_name | events | average_delay_minutes | p95_delay_minutes | events_over_15_minutes |
|---|---|---|---|---|---|
| mobile_offline_sync | feature_used | 4,260 | 18.4 | 96.2 | 1,088 |
| billing_webhook | invoice_updated | 1,380 | 1.2 | 4.8 | 11 |
綜合範例輸出。在將其用於操作決策之前,針對您自己的事件架構和閾值執行查詢。
SQL 是如何工作的
- 1接收時間限制了操作視窗,而事件時間則衡量每個交付記錄的陳舊程度。
- 2平均延遲和 p95 延遲將普遍延遲的生產者與長尾問題區分開來。
- 3明確的後期事件計數使影響清晰可見,而無需僅依賴百分位。
需要決定的邊緣情況
- 時鐘偏差會產生負延遲或過大的延遲;分別監控和糾正生產者時鐘。
- 離線客戶端可能需要傳遞較晚的資料,並且需要與伺服器事件不同的閾值。
- 決定儀表板是否在遲到事件到達時重述最近的儲存桶。
推薦儀表板
- 條形圖:p95_delay_minutes(按來源)
- 趨勢:按接收小時劃分的延遲事件計數
- 資料表:最新的延遲事件以及源和事件時間
讓查詢範例發揮作用
相關埋點和指南
繼續分析
在真實事件中執行它
建立資料表,調整欄位並儲存結果
免費開始,傳送結構化事件,並將查詢結果用作圖表、共享儀表板小工具或警示輸入。