OpenTelemetry Collector 是 OpenTelemetry 的可执行采集与处理组件，用来接收、处理并导出 日志、指标、链路追踪 等遥测数据。
核心问题
如果每个应用都直接连接每个可观测性后端，应用代码就要承担导出协议、鉴权、批处理、重试、采样、脱敏和多后端转发逻辑。OpenTelemetry Collector 把这些横切逻辑从应用中剥离出来，让应用只需要把遥测发到本地或附近的 Collector，再由 Collector 统一处理和转发。
核心对象
| 对象 | 作用 | 工程关注点 |
|---|---|---|
| Receiver | 接收或抓取遥测数据 | 监听端口、协议、鉴权 |
| Processor | 在管道中修改、过滤、批处理或采样数据 | 顺序、内存、drop 策略 |
| Exporter | 把处理后的数据发送到外部目标 | endpoint、重试、队列、TLS |
| Pipeline | 一条从接收到导出的数据路径 | signal 类型、组件顺序 |
| Extension | 非数据流组件 | health check、auth、pprof、zpages |
| Connector | 连接两条 pipeline 的组件 | 从一种信号派生另一种信号 |
核心机制
Collector 的核心模型是 pipeline：
receiver -> processor(s) -> exporter(s)一个最小配置可以写成：
receivers:
otlp:
protocols:
grpc:
endpoint: 0.0.0.0:4317
http:
endpoint: 0.0.0.0:4318
processors:
batch:
exporters:
otlp:
endpoint: otlp-gateway:4317
service:
pipelines:
traces:
receivers: [otlp]
processors: [batch]
exporters: [otlp]这段配置的含义是：
otlpreceiver 同时打开 gRPC 和 HTTP 入口，接收 OTLP 数据。batchprocessor 把收到的数据按批次合并，减少出口请求次数。otlpexporter 把处理后的 traces 发送到后端。service.pipelines.traces把这些组件串成一条 trace pipeline。
Collector 可以同时有 traces、metrics、logs 等 pipeline。每条 pipeline 的数据类型是配置的一部分；组件必须支持该信号类型，否则启动加载配置时会报错。
工程用途
- 在主机、容器或边缘设备上作为本地 Agent，缓冲和转发应用遥测。
- 在集群内作为 Gateway，统一鉴权、采样、脱敏和多后端 fan-out。
- 把非 OTLP 输入转换成 OTLP 或后端协议，例如从 Prometheus scrape、文件日志或其他协议接入。
- 在迁移可观测性后端时，让应用保持 OTLP 出口不变，只改 Collector 出口。
观察 Collector 时，重点看 receiver 接收量、processor drop 数、exporter 队列长度、发送失败率、内存使用、批量大小、重试次数和自身健康检查。
边界与常见坑
- Collector 不会自动给应用埋点：应用仍需要 SDK、自动 instrumentation、Agent 或日志采集器产生数据。
- Collector 不是存储后端：它主要负责接收、处理和转发；长期存储、查询和看板仍由后端负责。
- receiver 和 exporter 方向容易搞反：receiver 是入口，exporter 是出口；同名
otlp可以同时出现在两边，但语义相反。 - pipeline 漏配会导致“收到了但没发出”：组件配置存在不代表被使用，必须挂到
service.pipelines。 - 同一 receiver fan-out 会共享入口压力：某条下游 pipeline 阻塞时，可能影响挂在同一 receiver 上的其他 pipeline。
- 生产环境要显式处理安全：远程 Collector 入口应配置 TLS、mTLS 或认证扩展；不要默认暴露未鉴权的 OTLP 端口。