OpenTelemetry Collector 怎样选择接收器和导出器

OpenTelemetry Collector 选错组件时，问题通常不是“Collector 不会收数据”，而是输入协议、遥测信号和后端能力没有对齐。最稳妥的判断顺序是：先看数据从哪里来，再看它属于 traces、metrics 还是 logs，最后确认后端接受什么格式。接收器负责把数据带进 Collector，导出器负责把数据送到目标系统，中间再由 pipeline 组织处理器。

官方地址：https://opentelemetry.io/docs/collector/

规模背景：先把输入域和输出域分开

在小型开发环境里，应用可以直接把遥测数据发到后端；当服务数量增加，直接连接会把重试、批处理、加密和敏感数据过滤分散到每个服务。Collector 的价值就是把这些共性能力放到一层独立的接收、处理和导出管道中。

因此不要先从“哪个导出器最流行”开始，而要先写出两句话：数据的生产者是谁，目标后端的输入契约是什么。应用 SDK 产生的 OTLP 数据和 Prometheus 暴露的抓取数据，输入方式不同；同一个 Collector 也可以为不同信号配置不同 pipeline。

原架构瓶颈：把接收器当成“万能入口”会怎样

接收器不是任意协议的转换器。它通常对应一种或多种输入协议，并且支持的信号类型有限。比如 OTLP 接收器适合接收应用 SDK 发送的 OTLP traces、metrics 或 logs；Prometheus 接收器则更适合从暴露指标的目标执行抓取。两者都写成“接收器”并不代表可以互换。

导出器也有同样的边界：它不是把任意对象“发出去”的通用出口。先确认后端接受 OTLP、Prometheus exposition，还是只需要调试输出；再决定导出器实例。配置了一个组件但没有把它放进对应 pipeline，它仍然不会参与数据处理。

新架构：用一条 pipeline 显式绑定接收器和导出器

下面是一份缩小后的配置示例。它把 OTLP 输入连接到 OTLP 后端，并保留一个 debug 导出器作为排查时的第二出口。示例中的地址是占位值，使用时需要替换为自己的后端端点和认证配置。

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317 # 接收应用 SDK 发送的 OTLP/gRPC 数据
      http:
        endpoint: 0.0.0.0:4318 # 需要 OTLP/HTTP 时再开放这个协议

processors:
  batch:
    timeout: 5s # 把小批量数据合并后再交给出口，降低请求碎片

exporters:
  otlp/backend:
    endpoint: observability.example:4317 # 目标后端地址，仅作配置示例
    tls:
      insecure: false # 生产环境不要用明文连接
  debug:
    verbosity: basic # 排障时输出摘要，不把它当作长期业务出口

service:
  pipelines:
    traces:
      receivers: [otlp] # 只有被 pipeline 引用，接收器才会启用
      processors: [batch] # 处理器顺序就是数据处理顺序
      exporters: [otlp/backend, debug] # 每个出口收到该 pipeline 的一份数据

这份配置表达了三个关键关系：otlp 是输入组件，batch 负责处理中间数据，otlp/backend 与 debug 是两个输出实例。若要收 metrics 或 logs，不能只把名称改成 metrics 或 logs 就结束，还要确认接收器、处理器和导出器都支持对应信号。

关键取舍：按四个问题选组件

1. 谁在产生数据？ SDK 主动推送通常从 OTLP 接收器开始；已有 Prometheus 指标目标则优先看抓取能力。
2. 数据是什么信号？ traces、metrics、logs 是 pipeline 的类型，组件支持范围必须匹配。
3. 后端接受什么？ 如果后端原生理解 OTLP，优先使用 OTLP 导出器；若目标是 Prometheus 兼容抓取面，再考虑 Prometheus 导出器。
4. 是否需要临时观察？ debug 导出器适合确认 Collector 是否收到数据，但不应在生产中无边界地输出敏感内容。

官方组件文档还提醒，配置同一个 exporter 实例可以被多个 pipeline 使用；同一个 processor 名称被多个 pipeline 引用时，每条 pipeline 会得到自己的处理器实例。这个差异很重要：共享的是配置引用，不是所有运行时状态。

上线结果：从错误信号反推选择是否合理

上线后的判断不要只看 Collector 进程是否启动。可以按下面的信号反推：

当组件越来越多时，先删除不需要的 receiver、exporter 和 extension，再考虑扩展功能。组件越少，配置越容易审阅，暴露的网络入口和维护面也越小。不要用“把所有组件都装上”来回避选择问题。

常见问题

接收器和导出器能不能使用同一个组件名？

可以在不同组件段落中出现同类型名称，但它们承担的角色不同。真正决定数据路径的是 service.pipelines 中的引用关系，建议使用清晰的实例名区分不同端点。

配置了 OTLP 接收器，为什么 Prometheus 指标仍然进不来？

OTLP 接收器只处理它支持的 OTLP 输入。若数据源是 Prometheus 抓取模型，需要根据 Collector 发行版和组件支持情况配置对应的 Prometheus 接收器，并把它放入 metrics pipeline。

debug 导出器能替代生产后端吗？

不建议。debug 导出器更适合观察 Collector 是否收到了数据；生产出口仍应按目标后端的协议、认证、TLS 和可靠性要求选择。