共同事件契约
使这些查询可重用的字段
- 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 和结果