将 Telemetry 与 OpenTelemetry 配合使用
Telemetry 和 OpenTelemetry 解决可观测系统的相关但不同的部分。 OpenTelemetry 提供供应商中立的 API、SDK、语义约定以及跟踪、指标和日志的收集器。 Telemetry 为专用 JSON 应用程序结果、类型表、DataFusion SQL、仪表板和告警提供托管路径。
Telemetry 目前不提供 OTLP 摄取端点，不应被描述为 OpenTelemetry 收集器后端。将 OpenTelemetry 采集器 与 OTLP 兼容的可观测性后端结合使用，以获取跟踪、指标和日志。当应用程序达到受益于 SQL 的业务或运营结果时，发出单独的 Telemetry 事件。
为每个信号分配一份工作
| 信号 | 最佳起始问题 |
|---|---|
| 公制 | 总体服务或基础设施健康状况是否正在发生变化？ |
| 踪迹 | 这个分布式请求的时间都去哪儿了？ |
| 诊断日志 | 哪些本地详细信息解释了此代码路径？ |
| Telemetry事件 | 哪些已完成的结果会影响用户、帐户、工作流程或成本中心？ |
结帐跟踪可以显示数据库和提供商范围。 checkout_completed 事件可以保存收入影响 SQL 所需的终端状态、安全账户 ID、计划、金额类别、重试计数、释放和延迟。两者都不需要复制对方。
与批准的标识符关联
读取应用程序结果边界处的活动 OpenTelemetry 跨度上下文：
import { trace } from "@opentelemetry/api";
const spanContext = trace.getActiveSpan()?.spanContext();
await telemetry.log("checkout_completed", {
checkout_id: checkoutId,
status: "success",
latency_ms: 684,
trace_id: spanContext?.traceId,
span_id: spanContext?.spanId,
checkout_version: "v2",
release: process.env.APP_RELEASE,
});
将跟踪和跨度 ID 视为查找字段，而不是图表维度。在将跨系统关联作为事件工作流程的一部分之前，请确认跟踪系统和 Telemetry 具有兼容的访问和保留边界。
不要批量复制跨度事件、资源属性、包袱、提示、请求正文或堆栈跟踪。使用允许名单。 OpenTelemetry 行李尤其可以跨服务边界传播，不应假定分析是安全的。
独立操作管道
OpenTelemetry 收集器可以批处理、重试、过滤和导出其支持的信号。 Telemetry SDK 或 Log API 有其自己的传递行为。监视两个管道并避免耦合它们的故障模式：
- 失败的结果事件传递不应结束原本成功的请求
- 失败的跟踪导出不应触发递归事件日志记录
- 关键审计或计费结果应使用明确持久的应用程序路径
- 采样决策应针对特定信号
- 部署验证应确认相关性和独立可用性
OpenTelemetry测井规范 解释了跟踪和日志上下文之间的相关性。使用 OpenTelemetry集成指南、日志、指标、跟踪和事件 和 规范广泛事件 选择最小的可靠信号组。