# 第 6 部分导论 · OpenTelemetry 与 Collector

> OTel 最大的价值不是任何一个软件，而是「标准」——它让埋点和后端解耦。这一章讲清 OTel 的三层（标准/SDK/Collector）、Collector 存在的 N×M 理由，以及它和 Prometheus 是什么关系（不是竞品）。

- 作者：David（道雾轩）
- 专栏：指标采集与观测（https://daiw.org/manual/observability.md）
- 最后更新：2026-07-15
- 原文：https://daiw.org/manual/observability/otel-overview
- 转载与引用：请注明出处并附原文链接（https://daiw.org/about/copyright）

# 第 6 部分导论 · OpenTelemetry 与 Collector

[Prometheus 那条线讲完了](https://daiw.org/manual/observability/alerting-philosophy)。现在换主角：**OpenTelemetry**。

但开始前必须先破除一个**极常见的混淆**。

## OTel 不是一个软件

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

  | 层 | 是什么 | 形态 |
  | --- | --- | --- |
  | **① 标准** | [三大支柱](https://daiw.org/manual/observability/three-pillars)的**数据模型** + **语义约定** + **传输协议（OTLP）** | **纸面规范** |
  | **② SDK** | 各语言的埋点库（Java/Go/Python/...） | 你 import 的库 |
  | **③ Collector** | 独立进程，接收/加工/导出 | 一个二进制 |

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

## 最大的价值：标准

<Callout type="info">
  **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 的命名规范](https://daiw.org/manual/observability/defining-metrics)是同一类东西——**约定比机制更难，但更有价值**。
</Callout>

## Collector 为什么存在：N×M → N+M

<Callout type="info">
  **Collector 解决的是个朴素的工程问题：**

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

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

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

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

  **一句话：Collector 是可观测性数据的“[网关](https://daiw.org/manual/observability/otel-overview)”**——和 API 网关的价值主张几乎一模一样（集中处理横切关注点）。
</Callout>

## 它和 Prometheus 是什么关系

<Callout type="warn">
  **这是最常见的问题：“有了 OTel，还要 Prometheus 吗？”**

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

  ```mermaid
  flowchart LR
      APP["应用<br/>(OTel SDK 埋点)"] -->|"OTLP"| COL["OTel Collector<br/>接收·加工·导出"]
      COL -->|"remote write"| PROM["Prometheus / Mimir<br/>存储 + 查询"]
      COL --> JAEGER["Jaeger/Tempo<br/>(traces)"]
      COL --> LOKI["Loki/ES<br/>(logs)"]
      PROM --> GRAF["Grafana"]
      style COL fill:#3b82f6,color:#fff
      style PROM fill:#f59e0b,color:#000
  ```

  - **OTel 管“[数据怎么产生和运输](https://daiw.org/manual/observability/collector-architecture)”** —— 埋点标准 + 管道。**它不存储、不查询。**
  - **Prometheus 管“[指标怎么存好查好](https://daiw.org/manual/observability/tsdb-overview)”** —— [TSDB](https://daiw.org/manual/observability/tsdb-overview) + [PromQL](https://daiw.org/manual/observability/promql-model)。

  **典型的现代架构是两者配合**：OTel SDK 埋点 → Collector 加工 → [remote write](https://daiw.org/manual/observability/query-path) 到 Prometheus/Mimir 存储 → [PromQL 查询](https://daiw.org/manual/observability/promql-model) → [Grafana 展示](https://daiw.org/manual/observability/three-pillars)。

  **有意思的是它们互相“抄”了对方：**
  - Collector 有 **prometheus receiver**（[它能像 Prometheus 一样去抓 `/metrics`](https://daiw.org/manual/observability/scrape-loop)）和 **prometheusremotewrite exporter**。
  - Prometheus 3.x 支持**原生接收 OTLP**。

  **两个生态在互相靠拢**——这对用户是好事：你不用二选一。**指标的事实标准还是 Prometheus 的模型和 PromQL（[第 0 部分说过](https://daiw.org/manual/observability/the-three-projects)），而 OTel 提供了统一的埋点和运输。**
</Callout>

## 这一部分怎么安排

- [Collector 架构](https://daiw.org/manual/observability/collector-architecture) —— 五类组件、以及那个反直觉的事实：**管道是个 DAG**。
- [pdata](https://daiw.org/manual/observability/pdata) —— [三大支柱](https://daiw.org/manual/observability/three-pillars)在内存里长什么样。
- [组件生命周期](https://daiw.org/manual/observability/custom-components) —— `Component` 接口与工厂模式。
- [consumer 与背压](https://daiw.org/manual/observability/consumer-backpressure) —— 数据怎么在组件间传，以及 `MutatesData` 这个精妙的契约。
- [配置](https://daiw.org/manual/observability/collector-config) —— confmap 与部署形态。
- [自定义组件](https://daiw.org/manual/observability/custom-components) —— 怎么扩展它。

## 小结与下一章

**OTel 是三层**：[**标准**（数据模型 + 语义约定 + OTLP）、**SDK**（各语言埋点库）、**Collector**（独立进程）](https://daiw.org/manual/observability/otel-overview)——“上了 OTel”这句话必须说清是哪层。**最大的价值是标准**：它[把埋点（最贵的投资，散布在几百处业务代码里）和后端解耦](https://daiw.org/manual/observability/otel-overview)，从“一辈子的婚姻”变成“可换的供应商”；**语义约定是被低估的一半**（[统一字段名，否则格式统一了也没法通用分析](https://daiw.org/manual/observability/defining-metrics)）。**Collector 把 N×M 变 N+M**，但真正的价值是“[它是一个可以插手的地方](https://daiw.org/manual/observability/sampling)”——[脱敏 / 改标签 / 采样 / 批量重试 / 换后端零改应用](https://daiw.org/manual/observability/relabeling)，本质是**可观测性数据的网关**。**它和 Prometheus 不是竞品**：[OTel 管产生与运输、Prometheus 管存储与查询](https://daiw.org/manual/observability/tsdb-overview)，典型架构是两者配合；而且[两个生态在互相靠拢](https://daiw.org/manual/observability/scrape-loop)（Collector 有 prometheus receiver,Prometheus 3.x 原生收 OTLP）。

Collector 的内部长什么样？下一章打开它——你会发现管道并不是一条“线”。👉 [Collector 架构](https://daiw.org/manual/observability/collector-architecture)。

## 参考资料

- [1] OpenTelemetry 官方文档：Specification、Semantic Conventions、OTLP。
- [2] OTel Collector 源码 `docs/vision.md`、`README.md`、`distributions.yaml`。
- [3] 关联[三大支柱](https://daiw.org/manual/observability/three-pillars)、[三个主角](https://daiw.org/manual/observability/the-three-projects)、[Prometheus 架构](https://daiw.org/manual/observability/prometheus-architecture)。