验证事件摄取和架构

接受的 API 请求并不是仪器检查的结束。在将事件复制到更多路由、工作人员或服务之前，请验证结果表和行。

此页面假设您从 发送您的第一个结构化事件 发送了合成 api_request_completed 事件。

找到桌子

打开您的 Telemetry 团队，选择 表格，然后打开 api_request_completed。如果该表不存在：

1. 确认 API 请求返回成功响应。
2. 确认密钥属于目标团队并且具有可写范围。
3. 检查规范化后的确切表名。
4. 使用新的合成 request_id 重试一次。
5. 在更改架构之前遵循 事件摄取故障排除。

避免在没有新标识符的情况下重复发送同一事件；重试可能会使以后的计数变得不明确。

检查推断的架构

合成的 API 示例应公开类似于以下内容的字段：

如果某个重要字段的类型错误，请在发送产量之前停止并修复生产者。从数字更改为任意文本的字段可能会使保存的 SQL 和图表更难以推理。

检查确切的行

使用 Samples或Table 视图并找到 request_id = req_demo_001。确认：

• 该行属于预期的环境和版本。
• latency_ms 是 184，而不是 0.184 或 184000。
• 该路线不包含真实的报告或帐户标识符。
• 不包含授权标头、cookie、请求正文、秘密、提示或私人客户内容。
• 生成的时间与发送窗口匹配。

预期行是事件契约有效的证据。它不是性能基准或代表性的生产分布。

通过API验证

您还可以通过编程方式检查表和模式：

curl https://api.telemetry.sh/tables \
  -H "Authorization: Bearer $TELEMETRY_API_KEY"

然后请求表架构：

curl https://api.telemetry.sh/tables/api_request_completed/schema \
  -H "Authorization: Bearer $TELEMETRY_API_KEY"

使用可读密钥进行自动化验证。 表格 API 记录分页、规范化、保留和模式响应。

记录合同

在扩展仪器之前，写下：

• 事件名称和业务粒度。
• 必填和可选字段。
• 字段类型和单位。
• 允许的状态和错误类别。
• 同一性和相关性字段。
• 禁止的字段。
• 所有者和预期保留期限。

继续 编写您的第一个 SQL 查询。有关架构更改策略，请参阅 模式演化。