結構化事件攝取和分析

它是如何運作的

從訊號到決策的可審查工作流程

選擇一個已完成的工作流程

從使用者、工作人員、API、Webhook 或代理產生有意義的結果開始。邊界上的小事件比巨大的有效載荷更容易信任。

記錄未來問題需要的欄位

包括穩定識別符號、狀態、持續時間、環境、功能和分類錯誤上下文。保密秘密和原始私人內容。

擴充套件之前驗證資料表

傳送綜合測試事件，檢查推斷的架構，並執行第一個查詢。僅在事件合約有用後才新增更多覆蓋範圍。

Telemetry 中的結構化事件資料表
實際的 Telemetry 工作區顯示攝取的事件資料表以及用於驗證它們的查詢介面。

邊界

這不能取代什麼

Telemetry 不決定您的組織被允許收集哪些個人或受監管的資料；活動合約仍然需要所有者和保留政策。
自動模式演化無法修復不明確的事件名稱、不一致的單位或在生產者之間改變含義的識別符號。
結構化事件補充了追蹤和資料庫本機診斷；它們不能替代每個低階除錯訊號。

可檢查的證明路徑

從事件契約到可見的答案

此範例使用宣告的架構、只讀 SQL 和確定性合成結果。它示範了工作流程，但沒有提供範例資料作為客戶基準。

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

哪些人工智慧工具和參數與失敗次數最多的呼叫相關？

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;