日志、指标、跟踪和结构化事件
可观测性信号重叠，但不可互换。选择能够回答问题的最小信号可以使仪器易于理解并控制成本。
每个信号的优点
文本日志 保留特定进程和时间的详细诊断上下文。它们对于异常、异常分支和人类可读的生命周期消息非常有用。
指标总结了一段时间内的数字测量。计数器、仪表和直方图对于服务范围的速率、饱和度和延迟趋势非常有效，但它们故意丢弃行级上下文。
跟踪跨请求路径连接。它们显示了哪些服务或依赖项消耗了时间，并且当一项操作跨多个系统时是有价值的。
结构化事件将已完成的业务或应用程序事实描述为可查询的行。它们非常适合工作成果、Webhook 交付、LLM 请求、激活里程碑以及影响客户的错误，其中 SQL 应按帐户、功能、模型、路线或版本进行分组。
从调查开始
对于“服务是否不健康？”，指标和告警可能就足够了。对于“这个请求在哪里花费了时间？”，使用跟踪。对于“此过程中到底发生了什么？”，请检查日志。对于“哪些帐户在发布后遇到同步失败？”，查询结构化事件。
您可以连接信号，而无需到处复制每个属性。将安全的 request_id 或 trace_id 放在结构化事件和诊断日志上。在指标中保持低基数服务的健康状况。在跟踪中存储跨度特定的时序。这在系统之间创建了路径，同时保留了每个系统的用途。
Telemetry 适合的地方
Telemetry 围绕结构化事件表和 SQL 进行设计。它补充而不是取代基础设施指标或分布式跟踪。在工作流具有有用结果的边界处发出事件，然后查询该表以获取比率、百分位数、群组和最近的示例。
例如，跟踪可以解释为什么一次结账需要四秒钟。 checkout_completed 事件可以显示版本 v2 是否增加了所有客户的 p95 延迟或支付失败。