结构化事件摄取和分析

它是如何运作的

从信号到决策的可审查工作流程

选择一个已完成的工作流程

从用户、工作人员、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;