Collector 架构是什么
OpenTelemetry Collector 统一收口应用侧遥测数据：receivers 负责接收（OTLP、Prometheus 抓取等），processors 负责加工（限流、攒批、增删字段、采样），exporters 负责输出到后端，service 段把三者组装成管道。部署上常分两层：靠近应用的 agent 与集中处理的 gateway。
基本信息
| 三段结构 | receivers / processors / exporters |
|---|---|
| 组装入口 | service.pipelines |
| 支持信号 | traces / metrics / logs |
| 常见 processor | memory_limiter、batch、attributes、tail_sampling |
| 常见 exporter | otlp、prometheus、loki |
| 校验方式 | validate 子命令或启动检查 |
典型使用场景
- 应用只对接一个 OTLP 端点，后端更换时应用无需改动
- 在 Collector 里统一做字段增删与脱敏，避免每种语言各写一遍
- 用 batch 攒批降低网络与后端写入压力
- 用 memory_limiter 保护自身不被流量突增打崩
- 集中做采样决策，既省存储又保关键样本
- 用 gateway 层统一做多租户路由与限流
处理流水线
处理流水线
应用（OTLP）→ receivers → processors → exporters → 后端
典型 processors：
memory_limiter 限流保护（放在最前）
batch 攒批提高网络效率（放在 exporter 前）
attributes 增删字段
tail_sampling 按策略保留
典型 exporters：otlp（到 Tempo/Jaeger）/ prometheus / loki
service:
pipelines:
traces:
receivers: [otlp]
processors: [memory_limiter, batch]
exporters: [otlp]组件职责
| 组件 | 职责 | 常见实现 |
|---|---|---|
| receiver | 接收数据 | otlp、prometheus、filelog |
| processor | 加工数据 | memory_limiter、batch、attributes |
| exporter | 输出数据 | otlp、prometheus、loki |
| connector | 管道互连 | 跨信号转换与桥接 |
| extension | 辅助能力 | 健康检查、pprof、zpages |
把加工逻辑放在 Collector 而不是各语言 SDK：一处配置、全局生效，换后端时应用无感，这是它最实际的价值。
processor 顺序有讲究：memory_limiter 放最前做保护，batch 放接近 exporters 的位置，采样通常放在批处理之前。
管道里引用未定义的组件会在启动时失败，配置改完先用校验手段检查，不要直接重启生产实例。
agent 与 gateway 分层能兼顾接入便利与集中治理：agent 做本地攒批与限流，gateway 做采样、路由与多租户控制。
同一种数据可以进多条管道（例如 traces 同时导出到 Tempo 与另一家后端），但每条管道都要单独声明组件，改动时注意别漏。
健康检查、zpages 与自身指标这几项扩展建议开启：Collector 出问题时，这些是确认「收没收到、发没发出去」的第一手依据。