参考：OTel 三支柱、Collector 与生态速查
基于 OpenTelemetry 1.x（2026-05 CNCF 毕业） · 核于 2026-08
速查
- OpenTelemetry：CNCF 毕业项目（2026-05），统一 Metrics/Logs/Traces 三支柱的可观测性开放标准，埋点一次发任意后端。
- 三支柱：Metrics（时序数值）、Logs（结构化日志）、Traces（span 树），共享 trace_id 联动。
- OTLP：统一传输协议（gRPC 4317 / HTTP 4318），protobuf 数据模型，后端无关的根基。
- 埋点：自动（instrumentation library 零代码改动）+ 手动（OTel API 自定义业务 span/metric）。
- Collector：接收-处理-导出三段式数据代理，解耦应用与后端。
- 关系：OTel 是数据生产者，Prometheus/Jaeger/Grafana 是存储/可视化消费者——互补不替代。
- 采用率：~76%~79%（Grafana 2025），过去 12 个月下载量 26 亿次，71% 同时用 Prometheus + OTel。
- 历史：OpenTracing + OpenCensus 于 2019 合并成立 OTel，2026-05 毕业。
一、三支柱速查
| 支柱 | API | 数据形态 | 仪器/字段 | 成熟度 |
|---|---|---|---|---|
| Metrics | Meter | 时序数值 | Counter/UpDownCounter/Histogram/Gauge | GA |
| Logs | Logger | 结构化事件 | severity/body/attributes/trace_id | 趋于 GA（2024-2025） |
| Traces | Tracer | span 树 | trace_id/span_id/parent_span_id/name/attributes | GA |
Metrics 仪器
| 仪器 | 行为 | 用途 |
|---|---|---|
| Counter | 只增不减 | 请求总数、错误总数 |
| UpDownCounter | 可增可减 | 队列长度、连接数 |
| Histogram | 分布（桶） | 延迟 P99、响应大小 |
| Gauge | 瞬时值 | CPU、温度、内存 |
Trace span 关键字段
| 字段 | 含义 |
|---|---|
trace_id | 整条链路 ID（贯穿三支柱） |
span_id | 本段操作 ID |
parent_span_id | 父段 ID（构成 span 树） |
name | 操作名（如 process_order） |
start_time/end_time | 起止时间（算耗时） |
attributes | 结构化属性（如 orderId） |
status | OK / ERROR |
events | span 内离散事件 |
二、OTLP 速查
| 维度 | 说明 |
|---|---|
| 数据模型 | protobuf 定义 Metrics/Logs/Traces 规范结构 |
| 传输 | OTLP/gRPC（默认）/ OTLP/HTTP（protobuf 或 JSON） |
| 默认端口 | gRPC: 4317 / HTTP: 4318 |
| 后端接入 | 实现接收端 或 用 Collector 转码 |
三、Collector 组件清单
Receivers（接收）
| Receiver | 接收格式 |
|---|---|
otlp | OTel 标准（主要） |
jaeger | Jaeger 兼容 |
zipkin | Zipkin 兼容 |
prometheus | Prometheus exposition（拉取） |
statsd | StatsD 协议 |
Processors（处理）
| Processor | 作用 |
|---|---|
batch | 批处理（攒批减少请求） |
memory_limiter | 限制内存防 OOM |
attributes | 增删改属性 |
resource | 加 Resource 属性 |
filter | 过滤数据 |
| tail_sampling | 尾端采样 |
Exporters（导出）
| Exporter | 导出目标 |
|---|---|
otlp | 另一 Collector 或 OTLP 后端 |
prometheus | Prometheus（/metrics 或 remote_write） |
jaeger / tempo | 追踪后端 |
loki / elasticsearch | 日志后端 |
datadog / honeycomb / newrelic | 商业 SaaS |
四、部署模式对比
| 模式 | 架构 | 优点 | 缺点 | 适合 |
|---|---|---|---|---|
| 无 Collector | 应用直连后端 | 简单 | 绑死后端、无集中处理 | 小规模验证 |
| Agent | 本机 Collector | 本地低延迟、应用不管后端 | 每机一个、资源分散 | K8s 节点级 |
| Gateway | 集中 Collector | 集中管控、易扩容 | 单点风险、跨网延迟 | 中等规模 |
| Agent + Gateway | 两级 | 兼顾低延迟与集中管控 | 架构复杂 | 大规模生产 |
五、API vs SDK vs Instrumentation
| 概念 | 是什么 | 谁依赖 |
|---|---|---|
API（@opentelemetry/api） | 接口定义（不产生数据） | 库代码（轻量零依赖） |
SDK（@opentelemetry/sdk-node） | 实现（产生+导出数据） | 应用入口配置 |
| Instrumentation | 自动接入框架的库 | 应用入口加载 |
六、生态角色速查
| 角色 | 做什么 | 例子 |
|---|---|---|
| 生产者（OTel） | 应用里埋点生产数据 | OTel SDK |
| 传输（OTel） | 协议+代理 | OTLP + Collector |
| 存储 | 存遥测数据 | Prometheus/Loki/Tempo/ES |
| 可视化 | 画图看板 | Grafana/Jaeger UI/Kibana |
| 告警 | 阈值告警 | Alertmanager |
七、易错点清单
- 「OpenTelemetry 替代了 Prometheus」：错。OTel 是数据生产者，Prometheus 是存储/查询消费者。OTel SDK 生产 metric → Collector → Prometheus 存。71% 组织同时用两者。
- 「OpenTelemetry 是个监控后端」：错。OTel 不存数据、不画图、不告警——只生产与传输遥测数据。存储用 Prometheus/Loki/Tempo，可视化用 Grafana。
- 「Metrics/Logs/Traces 是三套独立系统」：错。OTel 的精髓是三支柱统一——一套 API/SDK/协议（OTLP），且共享 trace_id 联动。
- 「自动埋点就够了，不用手动」：错。自动埋点只覆盖框架级调用（HTTP/DB），业务语义（如「处理支付」span）要手动埋点补充。
- 「OTLP 必须用 gRPC」：错。OTLP 支持 gRPC（默认 4317）和 HTTP（4318，protobuf 或 JSON）。不支持 gRPC 的环境（如部分 Serverless）用 HTTP。
- 「OpenTelemetry 是 Google 的项目」：部分渊源。它由 OpenTracing（CNCF）+ OpenCensus（Google）2019 年合并而来，现在是 CNCF 顶级的独立项目（2026 毕业）。
- 「OpenTelemetry 毕业 = 完成了」：错。毕业是成熟度里程碑，但项目仍在演进——Logs 信号各语言陆续 GA、Profiling（第四支柱）开发中、eBPF 集成等新方向。
- 「Collector 必须部署」：不一定。小规模可以让应用直连后端（无 Collector），但生产推荐用 Collector（解耦、扇出、集中处理）。
- 「trace_id 只是 trace 的事」：错。OTel 的精髓是 trace_id 贯穿三支柱——metric 的 exemplar 关联 trace、log 带 trace_id，三者联动排障。
- 「Context Propagation 是 OTel 自己发明的」：部分。OTel 默认用 W3C Trace Context（
traceparent），这是 W3C 推荐标准，跨厂商跨语言通用。