本文へ移動
Telemetry
ドキュメントを見る
概念とSQLパターン更新日: 2026年7月25日Telemetry 編集チームと製品チームによるレビュー1 最小読み取り時間

ワークフローから外部への AI エージェント テレメトリの計測

エージェントの実行、ツールの呼び出し、待ち時間、コスト、失敗、および受け入れられた結果から始めて、それらを SQL 対応のテーブルに変換します。

このページの内容
  1. データの取り込みとバッファ
  2. リアルタイムクエリ
  3. スキーマの変更
  4. 障害への対応とバッファ管理
  5. ファイルの結合
  6. クエリ対象ファイルの選択
  7. ディスクキャッシュとクエリの振り分け
  8. クエリの実行

Telemetry のアーキテクチャ

Telemetry は受信した JSON を検証し、受け付けたイベントをバッファに入れ、Parquet ファイルとして S3 に保存します。SQL クエリはバッファと保存済みデータを合わせて読むため、次のアップロード前でも新しいイベントを確認できます。

JSON 取り込み、スキーマ検証、ライブバッファと Parquet 保存から DataFusion のクエリ結果までの Telemetry の構成

クエリはライブバッファと保存済みの Parquet ファイルを合わせて読みます。

データの取り込みとバッファ

Rust サービスが受信した各 JSON イベントをテーブルのスキーマと照合します。互換性のあるイベントはバッファに追加します。バッファは 15 分経過するか 10,000 行に達すると S3 にアップロードします。

リアルタイムクエリ

クエリはバッファ内のイベントと、S3 またはディスクキャッシュのデータを読みます。イベントはバッファの書き出しを待たずに結果に表示されます。

スキーマの変更

Telemetry はイベントの到着に合わせて新しいフィールドをテーブルのスキーマに追加します。既存の行には、そのフィールドの値がありません。フィールドの追加と型の変更は別の操作です。移行の規則と例はスキーマの変更を参照してください。

障害への対応とバッファ管理

サービスは正常な終了時にバッファを書き出します。処理や書き出しができなかったデータは、復旧用のデッドレターキューに保存します。これらの復旧手段でも、すべての障害でデータ損失を防げるわけではありません。失ってはいけないイベントについては、アプリケーション側でも再試行を定義し、配信を確認してください。

ファイルの結合

小さい Parquet ファイルを大きいファイルにまとめます。クエリが開くファイル数を減らし、より多くの行をまとめて圧縮できます。

クエリ対象ファイルの選択

Telemetry は SQL を抽象構文木に解析して、テーブル、時間範囲、フィルターを特定します。ファイルのメタデータから必要なファイルを選び、S3 から取得します。

ディスクキャッシュとクエリの振り分け

Telemetry は内容に基づいてファイルをディスクにキャッシュし、各テナントのクエリを必要なファイルがありそうなサーバーへ振り分けます。キャッシュにあれば S3 からのダウンロードは不要です。待ち時間は読み取るデータ量、クエリ、必要なファイルがキャッシュにあるかどうかによって変わります。

クエリの実行

Apache DataFusion が選択したファイルに対して SQL を実行し、結果を返します。対応するクエリの書き方は DataFusion SQL リファレンスを参照してください。

自分のイベントで試す

初めての実際のエージェント実行に接続する

設定プロンプトを Claude Code、Codex、Cursor、または独自のエージェントに貼り付けます。ワークフローを実行し、Telemetry で結果を確認してください。

クレジットカードは必要ありません。明確にマークされたサンプル イベントとすぐに実行できるクエリが自動的に作成されるため、ワークフローを評価するために運用データは必要ありません。

  1. 1. 明確にマークされたサンプル イベントを 1 つ作成します
  2. 2. すぐに実行できるクエリを開く
  3. 3. 結果をダッシュボードに保存します

関連機能

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

ページの著者と参考資料

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

ドキュメントのレビュー方法