本文へ移動
Telemetry
ドキュメントを見る
ガイド更新日: 2026年7月29日Telemetry 編集チームと製品チームによるレビュー2 最小読み取り時間

コーディング エージェントでこのドキュメントを使用してください

Claude Code、Codex、Cursor、または別のコーディング エージェント用の集中プロンプト パックを開き、それをここで説明するワークフローに適応させます。

このページの内容
  1. イベントコントラクトをテストする
  2. すべてのターミナル パスを実行する
  3. プライバシー境界を強制する
  4. テスト配信の失敗
  5. 決定論的フィクスチャを使用して SQL を検証する
  6. デプロイメント検証を追加

CI での Telemetry インストルメンテーションのテスト

Telemetry インストルメンテーションはアプリケーションの動作であり、他の統合境界と同様にテストする必要があります。有用な CI スイートは、適切なターミナル結果が適切なイベントを作成し、禁止されたコンテンツが排除され、配信の失敗によってアプリケーションの結果が損なわれず、動作中の SQL が期待どおりの結果を返すことを証明します。

CI を本番環境 Telemetry API に依存させないでください。イベント シンクまたは HTTP トランスポートを挿入し、メモリ内のペイロードをキャプチャします。

イベントコントラクトをテストする

スキーマ ルールを確認できるように、1 つの関数でイベントを構築します。

type CheckoutInput = {
  checkoutId: string;
  status: "success" | "failed";
  durationMs: number;
  errorType?: "payment_declined" | "provider_timeout";
};

export function checkoutEvent(input: CheckoutInput) {
  return {
    event_name: "checkout_completed",
    schema_version: 1,
    checkout_id: input.checkoutId,
    status: input.status,
    duration_ms: input.durationMs,
    ...(input.errorType ? { error_type: input.errorType } : {}),
  };
}

単体テストでは、正確なフィールド名とタイプ、制御されたカテゴリ値、明示的な単位、および条件付き要件をアサートする必要があります。レビュー担当者がセマンティックな変更に気づかずに更新する可能性があるスナップショットよりも、正確なオブジェクトのアサーションを優先します。

すべてのターミナル パスを実行する

所有ワークフローについては、以下をカバーします。

  • 成功
  • 予想される事業失敗
  • 依存関係のタイムアウト
  • 再試行後に成功
  • 再試行が完了しました
  • 該当する場合、キャンセルまたは人的引き継ぎ
  • 重複配信
  • オプションのコンテキストがありません

木目を主張します。実装が内部的に再試行する場合でも、論理リクエスト イベントは 1 回発行される必要があります。試行イベントには、試行番号と安定した論理操作 ID が含まれている必要があります。

プライバシー境界を強制する

認可ヘッダー、Cookie、電子メール、生の URL クエリ、リクエスト本文、プロンプト、ツール引数、および例外メッセージを含む敵対的なフィクスチャを作成します。キャプチャされたイベントに誰も到達できないことをアサートします。

ホワイトリストは、増加する拒否リストよりもテストが簡単です。リダクションがフォールバック レイヤーである場合は、それを個別にテストし、未知のネストされたフィールドがそれをバイパスできないことを確認します。

テスト配信の失敗

偽のシンクを拒否し、タイムアウトさせ、レート制限応答を返します。アプリケーションが文書化されたポリシーに従っていることを確認します。

  • ベストエフォート型分析では、成功した顧客操作がエラーに変わることはありません
  • 重要な監査または請求イベントは、承認された永続的なパスを使用します
  • 再試行は制限されており、必要に応じて冪等性を使用します
  • シャットダウンフラッシュは期限を遵守します
  • テレメトリの失敗は、失敗したペイロードを再帰的にログに記録しなくても観察可能です

参照 イベント配信とべき等性 そして バッチ処理、バックプレッシャー、シャットダウン.

決定論的フィクスチャを使用して SQL を検証する

小さな合成データセットと重要な SQL に予期される行を保存します。成功、失敗、重複、ヌル、遅延、および境界タイムスタンプのケースが含まれます。クエリ テストでは、カウント ルールを可視化する必要があります。

SQL レシピ ライブラリ には確定的な入力行と予想される出力が含まれますが、 SQL 遊び場 サポートされているフィクスチャをローカルで実行できます。これらのパターンは、アプリケーション所有のダッシュボードとアラートに使用します。

デプロイメント検証を追加

CI は、実行時の構成ではなく、コードの動作を証明します。非実稼働環境への展開後:

  1. 一意に識別された合成イベントを送信します。
  2. HTTP 応答と格納されたテーブルを確認します。
  3. フィールドのタイプとスキーマのバージョンを確認します。
  4. イベントを検索する最小のクエリを実行します。
  5. ポリシーに従ってフィクスチャを削除または期限切れにします。

新しく導入された分析変数が存在しないという理由だけでアプリケーションの起動に失敗しないようにしてください。最初に構成をロールアウトし、既存の動作をフォールバックとして保持し、デプロイされたすべての環境が検証された後にのみ適用します。

契約書を文書化する イベント追跡計画、に従ってください 生産計測チェックリスト、使用します イベント取り込みのトラブルシューティング デプロイメントの検証が失敗した場合。

関連製品の機能

安定したイベント名、型指定されたフィールド、プライバシーがレビューされたコンテキストをキャプチャします。

所有権と技術リファレンス

Telemetry 編集チームがこの説明を所有しています。製品チームは動作、例、境界をレビューします。

編集基準を見直す