OpenTelemetry Collector 管道部署的难点，不在于把 OTLP 端口暴露出来，而在于当 traces、metrics、logs 大量涌入时，Collector 如何接住数据、按策略采样和脱敏、路由到不同后端，并在后端异常时保护自身和应用。
可观测性 官方文档将 Collector 定义为接收、处理和导出遥测数据的组件，使用 receivers、processors、exporters 和 service pipelines 组成数据管道[1]。本文聚焦采样、路由与故障降级，避免把 Collector 写成简单转发器。
如果你还在规划微服务可观测性整体架构，可以先阅读 微服务可观测性怎么规划；追踪接入细节可结合 可观测性链路追踪实践 一起看。
图1：OpenTelemetry Collector 整体架构
图型选择说明：本文主题是 Collector 部署拓扑与管道边界，优先用整体架构图说明数据进入、处理和导出责任，而不是按最佳实践清单展开。
拓扑先行：Agent 和 Gateway 分别承担什么风险
Collector 常见部署形态有 Agent、Gateway 和 Agent + Gateway。选择拓扑时，不应只看“部署简单”，还要看故障影响半径、出口权限、采样位置和升级节奏。
| 拓扑 | 适合承担 | 主要风险 |
|---|---|---|
| Agent | 节点级采集、本地预处理、靠近应用 | 配置分散，资源争抢影响节点 |
| Gateway | 集中采样、路由、认证、统一导出 | 容量不足会影响大范围数据 |
| Agent + Gateway | 本地采集加集中治理 | 链路更长，排障要分段 |
不要让所有应用直连所有后端
如果应用 SDK 同时对接多个可观测后端，后端迁移、字段脱敏、采样比例和出口权限都会散落在业务服务里。Collector 的价值是把这些策略集中到管道层，而不是把复杂度推给每个应用。
Pipeline 设计：processor 顺序会影响数据语义
Collector 配置通常由 receivers、processors、exporters 和 service.pipelines 组成，不同信号类型可以分别配置 traces、metrics、logs pipeline[1]。processor 的顺序不是装饰，先过滤、先脱敏、先 batch 还是先限流，会影响最终数据和资源消耗。
receivers:
otlp:
protocols:
grpc:
http:
processors:
memory_limiter:
check_interval: 1s
limit_mib: 512
batch:
timeout: 5s
exporters:
otlp:
endpoint: tempo.observability.svc:4317
service:
pipelines:
traces:
receivers: [otlp]
processors: [memory_limiter, batch]
exporters: [otlp]上面配置只展示最小 traces pipeline。memory_limiter、batch、retry 和 queue 等能力需要结合官方配置文档、版本和容量测试调整[2]。
图2：Collector Pipeline 中 receive
采样和路由要按排障问题设计
采样不是单纯为了省成本。采样过度会让故障链路消失，不采样又可能让后端写入和查询成本失控。更稳妥的方式是按问题类型设计数据保留优先级。
建议优先保留：
- 错误请求和异常状态码对应链路。
- 慢请求和超时链路。
- 核心业务路径，例如登录、支付、下单、任务提交。
- 新版本、新命名空间或高风险变更窗口的数据。
- 与告警事件同时间段的上下文数据。
路由策略则要回答：不同环境、团队、租户和信号是否进入不同后端。多租户场景下，字段脱敏、租户标签和出口权限应在 Collector 层明确，不要依赖后端临时过滤。
故障降级：后端不可用时先保护谁
可观测后端不可用时，Collector 可能出现 exporter 失败、队列堆积、内存上涨甚至重启。OpenTelemetry Collector 提供内部 telemetry，可观察接收、处理、导出和失败指标[3]。但降级策略需要团队提前决定。
后端异常时通常有三种选择：
- 短时重试：适合后端瞬时抖动，但要限制队列和内存。
- 有条件丢弃：优先保留错误和关键链路，丢弃低价值高频数据。
- 限流或降采样：保护 Collector 和应用，牺牲一部分完整性。
图3：Collector 在后端异常和数据突增时的重试、限流与
降级策略不能等故障当天再决定
如果没有预案，后端不可用时团队往往会临时扩大 Collector 资源或关闭采集。更好的做法是提前定义不同信号的保留优先级：traces 可按错误优先，metrics 保留关键 SLI，logs 保留错误和审计类日志。
丢数诊断：沿着接收量、处理量、导出量对账
当 traces 缺失、metrics 延迟或 logs 不完整时，不要直接怀疑后端。Collector 自身指标能帮助判断数据丢在哪一段。
排查顺序建议：
- 应用 SDK 是否成功发送到 Agent 或 Gateway。
- receiver 接收量是否符合预期。
- processor 是否过滤、采样或脱敏了字段。
- exporter 是否有失败、重试或队列满。
- 后端是否写入、索引和查询成功。
最关键的对账思路是：应用发送量 ≈ receiver 接收量 ≥ processor 输出量 ≥ exporter 成功量。若某一段突然下降，就优先查该段配置和日志。
上线检查：把 Collector 当成生产组件管理
Collector 不是旁路小工具。它承载观测数据后，一旦配置错误，可能造成告警缺失、排障失明、敏感字段泄露或后端成本失控。
上线前至少确认：
- Collector 自身 CPU、内存、队列和 exporter 失败有告警。
- 采样策略能保留错误、慢请求和关键路径。
- 脱敏规则覆盖 Token、Cookie、用户标识和敏感参数。
- 后端不可用时不会拖垮应用或节点。
- 配置变更可以灰度、回滚和审计。
小结
OpenTelemetry Collector管道部署不是简单安装一个采集器，而是设计一条可治理的 Telemetry Pipeline。拓扑决定影响范围，processor 顺序决定数据语义，采样和路由决定排障价值，降级策略决定故障时能否保护系统。
好的 Collector 管道应在后端异常时可降级，在数据突增时可限流，在排障时能解释每一段数据去了哪里。
参考资料
- [1] OpenTelemetry Collector
- [2] OpenTelemetry Collector Configuration
- [3] OpenTelemetry Collector Internal Telemetry
常见问题
1. OpenTelemetry Collector 一定要部署 Agent + Gateway 吗？
不一定。小规模或单后端场景可以先用 Gateway；需要节点级日志、主机指标或本地预处理时再引入 Agent。规模增大后，Agent + Gateway 更利于分层治理，但排障也更复杂。
2. 采样应该放在应用 SDK 还是 Collector？
两者都可以参与，但职责不同。SDK 侧采样能减少上报量，Collector 侧采样更便于统一策略和按租户治理。关键是避免多层采样互相叠加，导致关键错误链路被丢弃。
3. Collector 后端不可用会影响应用吗？
取决于 SDK、网络和 Collector 配置。异步发送通常影响可控，但队列堆积、重试过重或资源限制不当仍可能放大开销。建议限制队列、内存和重试，并监控应用发送失败率。
4. 如何判断 Collector 是否丢数据？
对比应用发送量、receiver 接收量、processor 输出量、exporter 成功量和后端写入量。若 exporter 失败、队列满或 memory_limiter 触发，就需要结合 Collector 内部指标和日志确认丢弃位置。
5. traces、metrics、logs 是否应该共用同一套处理器？
通常不建议完全共用。不同信号的数据量、保留策略、脱敏字段和后端不同，最好分 pipeline 管理，只复用明确通用的组件和配置片段。
