コモンイベント契約書
これらのクエリを再利用可能に保つフィールド
- timestamp_utc、received_at、event_id、event_name、および schema_version
- ソース、環境、producer_version、および必要なビジネス フィールド
- ingestion_status、validation_error、および重複した結果
SQL より前の定義
クエリでは決定できないこと
- 1予想されるイベントの量と鮮度をソースごとに個別に定義します。
- 2重複排除を試行する前に、安定したイベント識別子を選択してください。
- 3フィールドが本当に必要な場合にのみフィールドの完全性を測定します。
推奨される順序
最初にビルド検出、次に診断
分析パターン
結果で決定を説明する
テレメトリ自体を監視する
新しさ、完全性、独自性、スキーマの採用を、サポートされる製品の指標とは別に、第一級のシグナルとして扱います。
イベント時間を受信時間から分離する
作業がいつ発生したのか、いつ到着したのかを比較して、遅延したクライアント、バックフィル、ブロックされた取り込みを明らかにします。
生産者ごとにセグメント化する
回帰をソース、環境、スキーマ バージョン、リリースごとに分類して、所有者とロールアウトの境界を明確にします。
完全なレシピ
クエリをコピーし、仮定を検証します
イベント取り込みの鮮度を測定する
データの配信を停止したか、発生より大幅に遅れて到着しているイベント ソースを見つけます。
現在、どの本番イベント ソースが古いか遅れていますか?
SQL と結果を参照してください。重複するイベント ID を検索する
複数回配信されたイベント識別子を特定し、重複処理が機能しているかどうかを測定します。
複数回受信されたイベント ID はどれですか?
SQL と結果を参照してください。必須フィールドのヌル率を測定する
必要なアカウント、ステータス、または相関フィールドが表示されなくなっているイベント コントラクトを検索します。
アカウント識別子の欠落率が許容できないほど高いイベント名はどれですか?
SQL と結果を参照してください。遅れて到着するイベントを測定する
ソースごとにイベント配信遅延を測定し、古いデータまたは順序が正しくないデータを送信するプロデューサーを特定します。
分析を歪めるほど遅くデータを配信するイベント プロデューサーはどれですか?
SQL と結果を参照してください。イベントスキーマバージョンの導入を追跡する
プロデューサごとにスキーマ バージョンのロールアウトを測定し、デプロイメント後にアクティブなままになっている古いイベント コントラクトを見つけます。
重要なイベントの古いバージョンを依然として出力しているプロデューサーはどれですか?
SQL と結果を参照してください。イベント名によるTelemetryボリュームの測定
保存ポリシーや収集ポリシーを変更する前に、ペイロード バイト、平均イベント サイズ、拒否率に基づいてイベント タイプをランク付けします。
どのイベント コントラクトが最も多くの取り込み量を生み出しますか?
SQL と結果を参照してください。しきい値の前にイベント コントラクトを適応させる
分析パターンを維持しますが、テーブル名、フィールド タイプ、ビジネス定義、時間枠、および最小ボリューム ルールを独自のイベントに対して検証します。パブリッシュされたすべてのクエリも計画され、ピン留めされたエンジンを使用して空の型付きテーブルに対して実行されます。