05｜遥测数据怎样走到后端？

《可观测性工程》学习讲义 · 第 05 讲

应用产生遥测数据后，还要可靠地送到存储和分析系统。OTLP 规定数据的编码、传输和交付方式，Collector 则负责接收、处理和导出。

它们都属于 OpenTelemetry 体系，但职责不同：SDK 在应用内产生数据，OTLP 负责传输，Collector 负责管道处理，真正的存储、查询和仪表盘则由观测后端提供。

一条典型数据链路

Agent SDK → OTLP → Receiver → Processor → Exporter → Backend

可以把这条链路理解成快递系统：SDK 负责打包，OTLP 规定包裹格式和运输方式，Collector 是中转站，Backend 是最终仓库和查询系统。

OTLP是什么

OTLP 是 OpenTelemetry Protocol。它定义 Trace、Metric 和 Log 如何编码并通过 gRPC 或 HTTP 传输。有了统一协议，应用不需要为每个后端实现一套专用发送逻辑。

Collector是什么

Collector 是独立运行的遥测管道。它由几类组件组成：

• Receiver 接收 OTLP、Prometheus 等数据；
• Processor 执行批处理、过滤、脱敏、资源补充和采样；
• Exporter 把数据发送到观测后端；
• Connector 可以把一条管道的输出连接到另一条管道。

Collector 因此成为应用和供应商之间的缓冲层，也让后端切换、统一治理和多目标路由更加容易。

一个简单案例

一个 Agent 同时需要把 Trace 发到链路后端，把 Metric 发到监控系统。应用只向本地 Collector 发送 OTLP，由 Collector 分流数据，并统一补充环境、服务版本和集群信息。更换后端时，不需要修改每个 Agent 服务。

现实挑战：Collector成了新的故障点

流量高峰时，Collector 可能出现队列积压、内存上涨和数据丢弃。如果只监控业务服务，却不监控遥测管道，就会在最需要数据时失去数据。

现象—假设—证据—判断

现象：业务错误率升高，但对应 Trace 数量反而减少。假设包括采样变化、SDK 导出失败、Collector 丢弃。证据显示应用导出成功，Collector 发送队列已满，后端持续限流。判断：问题发生在 Collector 到后端的出口，而不是应用没有生成 Trace。

应观察 Collector 的接收量、导出失败、队列长度、丢弃量、内存和后端响应状态，并设置重试、持久队列和容量保护。

数据处理要谨慎

Collector 可以删除敏感字段、统一属性和执行 Tail Sampling，但处理规则一旦错误，也可能把关键诊断信息过滤掉。每条规则都应版本化，并用样本 Trace 验证转换前后的数据。

小结

在 OTel 架构中，SDK 产生数据，OTLP 解决标准传输，Collector 解决集中处理和多后端路由，Backend 负责存储与分析。Collector 不是透明管道，而是需要容量规划、自我监控和变更验证的生产系统。

延伸阅读：OpenTelemetry Collector

---

可观测性工程系列：上一篇：04｜什么是 OpenTelemetry？ · 下一篇：06｜可观测性工程中的语义管理

原文：LandX