コモンイベント契約書
これらのクエリを再利用可能に保つフィールド
- timestamp_utc、プロバイダー、event_type、delivery_id、およびステータス
- 試行、latency_ms、status_code、および idempotency_outcome
- downstream_job_count、error_type、および環境
SQL より前の定義
クエリでは決定できないこと
- 1生の Webhook ペイロードや署名ではなく、プロバイダー ID を保存します。
- 2配信試行と 1 つの Webhook の最終結果を区別します。
- 3承認された重複が成功なのか、それとも別の結果なのかを定義します。
推奨される順序
最初にビルド検出、次に診断
分析パターン
結果で決定を説明する
1 つの配信をエンドツーエンドで追跡する
安定した配信識別子を使用して、受信、検証、確認応答、再試行、処理、およびダウンストリーム効果を接続します。
試みと結果を区別する
試行レベルのエラーは、永続的に失敗した Webhook とは異なります。回収率を解釈可能な状態に保つために、両方を維持してください。
冪等性を検証する
重複認識とダウンストリームの副作用を追跡して、再試行によってビジネス操作が繰り返されないことを確認します。
完全なレシピ
クエリをコピーし、仮定を検証します
中級者webhook_deliveries
Webhook の再試行回復を測定する
永続的な Webhook エラーを、後の試行で回復した配信から分離します。
Webhook の再試行により失敗が回復するのでしょうか、それとも追加の作業が発生しますか?
SQL と結果を参照してください。中級者webhook_deliveries
Webhook のレイテンシーと重複率を測定する
Webhook プロバイダーとイベント タイプごとに、処理遅延、重複配信、失敗を比較します。
どの Webhook ソースが遅い、重複している、または信頼性が低いですか?
SQL と結果を参照してください。上級者向けwebhook_lifecycle_events
Webhook のエンドツーエンドの完了を測定する
受信からダウンストリームの完了まで各 Webhook を追跡し、運用目標内で終了するシェアを測定します。
どの Webhook タイプがダウンストリーム作業を 5 分以内に完了しますか?
SQL と結果を参照してください。しきい値の前にイベント コントラクトを適応させる
分析パターンを維持しますが、テーブル名、フィールド タイプ、ビジネス定義、時間枠、および最小ボリューム ルールを独自のイベントに対して検証します。パブリッシュされたすべてのクエリも計画され、ピン留めされたエンジンを使用して空の型付きテーブルに対して実行されます。