遥测数据怎样走到后端？
05｜OTLP与Collector：遥测数据怎样走到后端
应用产生遥测数据后，还要可靠地送到存储和分析系统。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 不是透明管道，而是需要容量规划、自我监控和变更验证的生产系统。