共同事件契約
使這些查詢可重用的欄位
- timestamp_utc、提供商、event_type、delivery_id 和狀態
- 嘗試，latency_ms、status_code 和 idempotency_outcome
- downstream_job_count、error_type和環境
SQL 之前的定義
查詢無法為您做出的決定
- 1儲存提供者識別符號，而不是原始 Webhook 有效負載或簽名。
- 2區分一個 Webhook 的交付嘗試和最終結果。
- 3定義已確認的重複是成功還是單獨的結果。
推薦順序
先建立檢測，然後診斷
分析模式
讓結果解釋決定
全程追蹤一次交付
使用穩定的交付識別符號來連線接收、驗證、確認、重試、處理和下游效果。
區分嘗試和結果
嘗試級錯誤與永久失敗的 Webhook 不同。保留兩者，以便恢復率保持可解釋性。
驗證冪等性
追蹤重複識別和下游副作用，以確認重試不會重複業務操作。
完整的查詢範例
複製查詢，然後驗證假設
中級webhook_deliveries
測量 Webhook 重試恢復
將永久性 Webhook 故障與稍後嘗試恢復的傳輸分開。
Webhook 重試是恢復失敗還是創造更多工作？
檢視 SQL 和結果中級webhook_deliveries
測量 Webhook 延遲和重複率
按 Webhook 提供程式和事件型別比較處理延遲、重複傳遞和失敗。
哪些 Webhook 源速度慢、重複或不可靠？
檢視 SQL 和結果高階webhook_lifecycle_events
衡量 Webhook 端到端完成情況
追蹤每個 Webhook 從接收到下游完成的整個過程，並衡量在操作目標內完成的份額。
哪些 Webhook 型別會在五分鐘內完成下游工作？
檢視 SQL 和結果