第 6 部分导论 · OpenTelemetry 与 Collector

“我们上了 OpenTelemetry”这句话，几乎总是含糊的——因为 OTel 是三层东西**，说的人往往指其中一层。**

本部分读的源码是 ③ Collector（opentelemetry-collector-v0.156.0），但你必须知道：OTel 最大的价值其实是 ①。

OTel 真正解决的问题是：埋点和后端的耦合。

OTel 之前的世界：

你用 Jaeger  → 代码里 import jaeger-client,按 Jaeger 的 API 埋点
想换 Zipkin? → 改所有埋点代码
想换某云厂商? → 再改一遍

埋点是最贵的投资（它散布在你所有业务代码里、几百上千处），而它被锁死在一个后端上。换后端 = 重新埋点 = 没人愿意做 = 厂商锁定。

OTel 之后：

代码里 import OTel SDK,按标准埋点(一次)
想换后端? → 改一行配置(改 exporter)

埋点这笔投资，和后端解耦了。 这是个巨大的转变——它把可观测性后端从“一辈子的婚姻”变成了“可以随时换的供应商”。

语义约定（semantic conventions）是标准里被低估的一半： 它规定了“HTTP 请求该用哪些属性名”（http.request.method 而不是 httpMethod/method/http_verb）。没有它，即使数据格式统一了，各家吐出的字段名还是五花八门，照样没法通用分析。 这和 Prometheus 的命名规范是同一类东西——约定比机制更难，但更有价值。

Collector 解决的是个朴素的工程问题：

没有 Collector:
  N 个数据源 × M 个后端 = N×M 种对接
  (每个应用都要知道所有后端的地址、认证、格式)

有 Collector:
  N 个源 → Collector → M 个后端 = N+M

但“减少对接”只是表面收益。Collector 真正的价值在于它是一个可以插手的地方：

• 加工数据 —— 脱敏（去掉手机号）、改标签、采样、丢弃无用数据。这些事在应用里做要改所有应用，在 Collector 里做改一处。
• 批量与重试 —— 应用只管把数据吐给本地 Collector（极快），由 Collector 负责批量、压缩、重试、缓冲。应用不用关心后端慢不慢。
• 解耦运维 —— 后端要换、要加一个、要做灰度？改 Collector 配置，应用零改动、零重启。
• 统一治理 —— 想给所有数据加个 env=prod 标签？一处配置。

一句话：Collector 是可观测性数据的“网关”——和 API 网关的价值主张几乎一模一样（集中处理横切关注点）。

这是最常见的问题：“有了 OTel，还要 Prometheus 吗？”

它们不是竞品，是链条上的不同段：

• OTel 管“数据怎么产生和运输” —— 埋点标准 + 管道。它不存储、不查询。
• Prometheus 管“指标怎么存好查好” —— TSDB + PromQL。

典型的现代架构是两者配合：OTel SDK 埋点 → Collector 加工 → remote write 到 Prometheus/Mimir 存储 → PromQL 查询 → Grafana 展示。

有意思的是它们互相“抄”了对方：

• Collector 有 prometheus receiver（它能像 Prometheus 一样去抓 /metrics）和 prometheusremotewrite exporter。
• Prometheus 3.x 支持原生接收 OTLP。

两个生态在互相靠拢——这对用户是好事：你不用二选一。指标的事实标准还是 Prometheus 的模型和 PromQL（第 0 部分说过），而 OTel 提供了统一的埋点和运输。