活動合約
查詢期望的欄位
| 欄位 | 型別 | 為什麼存在 |
|---|---|---|
| timestamp_utc | Timestamp | 處理完成時間。 |
| provider | Utf8 | Webhook 提供商。 |
| event_type | Utf8 | 提供商事件類別。 |
| idempotency_outcome | Utf8 | new_event 或重複。 |
| status | Utf8 | 成功或失敗。 |
| latency_ms | Float64 | 處理持續時間。 |
DataFusion SQL
複製查詢
sql
SELECT
provider,
event_type,
COUNT(*) AS deliveries,
SUM(CASE WHEN idempotency_outcome = 'duplicate' THEN 1 ELSE 0 END) AS duplicates,
SUM(CASE WHEN status = 'failed' THEN 1 ELSE 0 END) AS failures,
100.0 * SUM(CASE WHEN idempotency_outcome = 'duplicate' THEN 1 ELSE 0 END)
/ NULLIF(COUNT(*), 0) AS duplicate_rate_pct,
approx_percentile_cont(latency_ms, 0.95) AS p95_latency_ms
FROM webhook_deliveries
WHERE timestamp_utc >= now() - INTERVAL '7 days'
GROUP BY provider, event_type
ORDER BY duplicate_rate_pct DESC, failures DESC;此只讀查詢是針對空型別資料表計劃和執行的 阿帕奇 DataFusion 45.2.0。確定性樣本輸出是綜合的並單獨審查;根據您自己的資料驗證欄位型別、閾值和業務定義。 閱讀測試方法。
查詢結果
Webhook 傳送重複且失敗
Stripe支付失敗重複率最高,終端失敗較多。
invoice.payment_failed
34
9
push
42
3
| provider | event_type | deliveries | duplicates | failures | duplicate_rate_pct | p95_latency_ms |
|---|---|---|---|---|---|---|
| stripe | invoice.payment_failed | 480 | 34 | 9 | 7.08 | 1,180 |
| github | push | 2,940 | 42 | 3 | 1.43 | 420 |
綜合範例輸出。在將其用於操作決策之前,針對您自己的事件架構和閾值執行查詢。
SQL 是如何工作的
- 1CASE 表示式計算來自同一交付群體的重複和失敗計數。
- 2重複率是一個傳遞特性;它並不能證明重複的業務效果。
- 3尾部延遲顯示處理程式是否接近提供程式超時或重試邊界。
需要決定的邊緣情況
- 重複項可以成功地進行重複資料刪除,並且不應自動算作失敗。
- 提供程式重試策略和事件量不同,因此請保留提供程式和事件型別。
- 切勿在此資料表中儲存 Webhook 簽名或原始付款負載。
推薦儀表板
- 堆疊條:按事件型別劃分的重複和失敗
- 趨勢:p95 webhook 延遲
- 資料表:最近失敗的下游作業
讓查詢範例發揮作用
相關埋點和指南
繼續分析
在真實事件中執行它
建立資料表,調整欄位並儲存結果
免費開始,傳送結構化事件,並將查詢結果用作圖表、共享儀表板小工具或警示輸入。