構造化イベントの取り込みと分析

仕組み

シグナルから意思決定までのレビュー可能なワークフロー

完了したワークフローを 1 つ選択してください

ユーザー、ワーカー、API、Webhook、またはエージェントが意味のある結果を生み出すところから開始します。境界での小さなイベントは、巨大なペイロードよりも信頼しやすいです。

今後の質問に必要なフィールドをログに記録します

安定した識別子、ステータス、期間、環境、機能、および分類されたエラーコンテキストが含まれます。秘密や生のプライベートコンテンツを外部に漏らさないようにします。

展開する前にテーブルを確認してください

合成テストイベントを送信し、推論されたスキーマを検査し、最初のクエリを実行します。イベント契約が有効になった後でのみ、補償範囲を追加してください。

Telemetry の構造化イベントテーブル
取り込まれたイベントテーブルとそれらを検証するために使用されるクエリサーフェスを示す実際の Telemetry ワークスペース。

境界線

これが置き換えられないもの

Telemetry は、組織がどの個人データまたは規制データの収集を許可するかを決定するものではありません。イベントコントラクトには引き続き所有者と保持ポリシーが必要です。
自動スキーマ進化では、曖昧なイベント名、一貫性のないユニット、プロデューサ間で意味が変わる識別子を修復できません。
構造化イベントはトレースとデータベースネイティブの診断を補完します。これらは、あらゆる低レベルのデバッグ信号の代替となるものではありません。

検査可能な証明パス

イベント契約から目に見える答えまで

この例では、宣言されたスキーマ、読み取り専用の SQL、および決定論的な合成結果を使用します。顧客のベンチマークとしてサンプルデータを提示せずにワークフローを示します。

1. イベント契約

1行 agent_events、クエリで使用される型が明示的に示されています。

timestamp_utc: Timestamp
event_name: Utf8
data.tool_name: Utf8
data.status: Utf8
data.args.operation: Utf8
data.latency_ms: Float64

イベント契約書を閲覧する

2. 読み取り専用 SQL

最も失敗した呼び出しに関連する AI ツールと引数はどれですか?

SELECT
  "data.tool_name" AS tool_name,
  "data.args.operation" AS operation,
  COUNT(*) AS calls,
  SUM(CASE
    WHEN "data.status" = 'failed' THEN 1 ELSE 0
  END) AS failures,
  100.0 * SUM(CASE
    WHEN "data.status" = 'failed' THEN 1 ELSE 0
  END) / NULLIF(COUNT(*), 0) AS failure_rate_pct,
  approx_percentile_cont("data.latency_ms", 0.95) AS p95_latency_ms
FROM agent_events
WHERE event_name = 'agent_tool_called'
  AND timestamp_utc >= now() - INTERVAL '7 days'
GROUP BY "data.tool_name", "data.args.operation"
HAVING COUNT(*) >= 20
ORDER BY failure_rate_pct DESC, calls DESC;