Collector 与生态采用：数据代理、后端关系与 CNCF 毕业
基于 OpenTelemetry 1.x（2026-05 CNCF 毕业） · 核于 2026-08
速查
- Collector 是数据代理：OpenTelemetry Collector 是一个独立部署的代理服务，pipeline 是「接收（receivers）→ 处理（processors）→ 导出（exporters）」三段式。解耦应用与后端：应用只发 OTLP 给 Collector，Collector 负责扇出、采样、重标记、转码。
- Collector 三大组件：①Receivers——接收数据（OTLP 是主要的，也兼容 Jaeger/Prometheus/Zipkin/Statsd 等格式）；②Processors——处理数据（batch 批处理、memory_limiter 限内存、attributes 加属性、sampling 采样、filter 过滤）；③Exporters——导出到后端（Prometheus/Jaeger/Tempo/Loki/Datadog/OTLP 等）。
- 部署模式四种：①Agent 模式——Collector 作为 sidecar/daemonset 跟应用同机部署，本地接收；②Gateway 模式——集中部署集群级 Collector，多应用发给它；③Agent + Gateway 两级——本机 Agent 收，转发到集群 Gateway 再扇出；④无 Collector——应用直接发后端（简单但耦合）。
- OTel 与 Prometheus 的关系：OTel 是数据源（生产者），Prometheus 是存储/查询（消费者）。OTel SDK 在应用里生产 metric，通过 Collector 的 prometheus exporter 暴露
/metrics端点（或 remote_write）给 Prometheus 拉/推。Grafana 2025 调查：71% 组织同时用 Prometheus + OTel——两者互补，不是替代。 - OTel 与 Jaeger/Tempo 的关系：Jaeger（CNCF 毕业，追踪存储/UI）、Tempo（Grafana Labs，追踪存储）是追踪后端，OTel 是追踪数据生产者。OTel SDK 生产 trace span → OTLP 发给 Collector → Collector 的 jaeger/tempo exporter 导出 → Jaeger/Tempo 存储 + UI 展示。
- OTel 不做存储/可视化：这是理解 OTel 定位的关键——OTel 只负责生产与传输遥测数据，不存数据、不画图。存储用 Prometheus（metric）、Loki（log）、Tempo（trace）；可视化用 Grafana；告警用 Alertmanager。OTel 是流水线的「上游」，后端是「下游」。
- 2026-05 CNCF 毕业：继 Kubernetes（2018）、Prometheus（2018）、Envoy（2018）之后，OTel 成为 CNCF 第 N 个毕业项目（最高成熟度）。毕业要求：广泛采用、文档完善、治理成熟、发布流程规范、社区活跃。OTel 毕业 = 正式确立「可观测性事实标准」。
- 采用现状：①过去 12 个月下载量超 26 亿次；②Grafana 2025 调查 79% 组织使用 OTel（采用率约 76%~79%）；③71% 同时用 Prometheus + OTel；④从 OpenTracing + OpenCensus 合并而来（2019），结束两套标准分裂。
- 迁移路径：从厂商 SDK / Prometheus client / Jaeger client 迁移到 OTel SDK 是渐进的——OTel Collector 兼容多种输入格式（Jaeger/Zipkin/Prometheus），可先部署 Collector 收老格式数据，再逐步把应用切到 OTel SDK。
一、Collector：接收-处理-导出三段式
Collector 是 OTel 的数据中转枢纽，核心是 pipeline 模型：
应用 A（OTel SDK）──┐
应用 B（OTel SDK）──┤
应用 C（老 Jaeger）─┤ Receivers（接收）
├─→ [otlp / jaeger / zipkin / prometheus / statsd]
│
│ Processors（处理）
├─→ [batch / memory_limiter / attributes /
│ sampling / filter / resource]
│
│ Exporters（导出）
└─→ [prometheus / jaeger / tempo / loki /
datadog / otlp / elasticsearch]
│
┌─────────┴─────────┐
▼ ▼
Prometheus（metric） Jaeger（trace）
Loki（log） Datadog（全栈）Receivers（接收）
| Receiver | 接收什么 |
|---|---|
otlp | OTel 标准格式（gRPC 4317 / HTTP 4318）—— 主要的 |
jaeger | 兼容老 Jaeger client 格式 |
zipkin | 兼容 Zipkin 格式 |
prometheus | 拉取 Prometheus exposition 格式 |
statsd | 兼容 StatsD 协议 |
Processors（处理）
| Processor | 作用 |
|---|---|
batch | 批处理（攒一批再发，减少请求次数） |
memory_limiter | 限制内存使用（防 OOM） |
attributes | 增删改属性（如加 cluster 标签） |
resource | 加 Resource 属性（如云信息） |
filter | 过滤数据（如丢弃某服务的 trace） |
sampling | 尾端采样（如只保留 10% trace） |
Exporters（导出）
| Exporter | 导出到 |
|---|---|
otlp | 另一个 Collector（级联）或支持 OTLP 的后端 |
prometheus | 暴露 /metrics 给 Prometheus 拉（或 remote_write） |
jaeger / tempo | 追踪后端 |
loki / elasticsearch | 日志后端 |
datadog / newrelic / honeycomb | 商业 SaaS |
二、部署模式：四种取舍
模式 1：无 Collector（应用直连后端）
应用 ──OTLP──→ 后端（如 Datadog / Tempo）- 优点：简单，无中间组件。
- 缺点：应用绑死后端，换后端要改应用配置；无采样/批处理集中管理。
- 适合：小规模、单一后端、快速验证。
模式 2：Agent 模式（本机 Collector）
应用 ──OTLP──→ 本机 Collector（DaemonSet/Sidecar）──→ 后端- 优点：本地接收（低延迟）、本机采样、应用只发本地不用管后端。
- 缺点：每台机器一个 Collector，资源开销分散。
- 适合：K8s 节点级（DaemonSet）、大规模集群。
模式 3：Gateway 模式（集中 Collector）
多应用 ──OTLP──→ 集群级 Collector（Deployment）──→ 多后端- 优点：集中管理配置、集中采样/批处理、易扩容。
- 缺点：Collector 是单点（要多副本+负载均衡）、跨网络一跳延迟。
- 适合：中等规模、需要集中管控。
模式 4：Agent + Gateway 两级（生产推荐）
应用 → 本机 Agent → 集群 Gateway → 多后端- 优点：本机 Agent 快速接收+初步处理，集群 Gateway 集中扇出+采样，兼顾低延迟与集中管控。
- 缺点：架构复杂（两级）、运维成本高。
- 适合：大规模生产集群（推荐）。
三、OTel 与 Prometheus 的关系：生产者 vs 消费者
最常见的误解是「OTel 替代 Prometheus」——错。两者是互补的生产者-消费者关系：
| 维度 | OpenTelemetry | Prometheus |
|---|---|---|
| 角色 | 数据生产者（在应用里埋点生产 metric） | 数据存储+查询（TSDB + PromQL） |
| 做的事 | 定义 metric API/SDK/数据模型/传输 | 拉/存 metric，PromQL 查询，告警 |
| 不做的事 | 不存数据、不查询 | 不在应用里埋点（要 client 库） |
| 关系 | OTel SDK 生产 → Collector 导出 → Prometheus 存 | Prometheus 拉 Collector 暴露的 /metrics |
- 协同方式：应用用 OTel SDK 生产 metric → Collector 的 prometheus exporter 暴露
/metrics端点 → Prometheus 拉取存储 → Grafana 查询展示。 - Grafana 2025 数据：71% 组织同时用 Prometheus + OTel——印证两者互补共生，不是替代。
- 唯一重叠：OTel 也提供 metric client（替代 Prometheus client 库），但存储/查询仍是 Prometheus 的活。
四、OTel 与 Jaeger/Tempo 的关系：追踪同理
| 维度 | OpenTelemetry | Jaeger / Tempo |
|---|---|---|
| 角色 | 追踪数据生产者 | 追踪存储 + UI |
| 做的事 | 在应用里埋点生产 span，OTLP 传输 | 存 trace，提供查询/可视化 UI |
| 关系 | OTel 生产 → Collector 导出 → Jaeger/Tempo 存+展示 | 消费 OTel 数据 |
- Jaeger（CNCF 毕业）：最早的分布式追踪系统（Uber 开源），存储 trace + 提供 UI 查询链路。
- Tempo（Grafana Labs）：专注追踪存储，与 Grafana/Loki/Prometheus 深度集成。
- OTel 替代的是：老 Jaeger client / Zipkin client（各厂商追踪 SDK），不是 Jaeger/Tempo 后端。
五、OTel 不做存储/可视化：定位要清楚
理解 OTel 的关键：它只负责遥测数据的「生产与传输」，不存数据、不画图、不告警：
[生产] [传输] [存储] [可视化/告警]
OTel SDK → OTLP/Collector → 后端 → Grafana/Alertmanager
（埋点） （协议/代理） （DB） （展示/告警）- 存储：Prometheus（metric）、Loki（log）、Tempo（trace）、Elasticsearch（log）。
- 可视化：Grafana（统一面板）、Jaeger UI（trace）、Kibana（log）。
- 告警：Alertmanager（基于 Prometheus）。
- OTel 的边界：到 Collector 导出给后端就结束了。选什么后端、怎么查、怎么画图，是后端生态的事。
六、2026-05 CNCF 毕业：可观测性事实标准
OpenTelemetry 于 2026 年 5 月正式从 CNCF 毕业——成为继 Kubernetes、Prometheus、Envoy 之后最高成熟度的项目。
- 毕业的意义：CNCF 毕业要求项目「广泛采用、文档完善、治理成熟、发布流程规范、社区多元活跃」——毕业 = 确认 OTel 已是「可观测性事实标准」，可放心在生产大规模采用。
- 采用数据：①过去 12 个月下载量超 26 亿次；②Grafana 2025 调查 79% 组织使用 OTel；③71% 同时用 Prometheus + OTel；④毕业公告在 2026-05-21 Observability Summit（Minneapolis）发布。
- 历史脉络：2019-05 加入 CNCF（Sandbox）→ 2021-08 进入孵化（Incubating）→ 2026-05 毕业（Graduated）。由 OpenTracing + OpenCensus 合并而来，结束了追踪标准的分裂。
- 毕业不是终点：OTel 仍在持续完善——Logs 信号在各语言陆续 GA、Profiling 信号（第四支柱，开发中）、eBPF 集成等新方向。
七、迁移路径：从存量到 OTel
存量系统迁移到 OTel 是渐进的，Collector 兼容多格式是关键：
- 先部署 Collector：Collector 兼容 Jaeger/Zipkin/Prometheus/StatsD 输入——先把它架起来收老格式数据，统一出口。
- 逐步切应用 SDK：把应用从厂商 SDK / Prometheus client / Jaeger client 切到 OTel SDK。每次切一个服务，验证数据一致。
- 后端不动：Prometheus/Jaeger 等后端照常工作（Collector 导出给它们）——迁移对后端透明。
- 享受统一：全部切完后，三支柱用一套 OTel SDK/OTLP，换后端只改 Collector 配置。
下一步
掌握了 Collector 架构与生态关系后，可回到参考查三支柱速查、Collector 组件清单、API/SDK 对比与易错点。