三个主角与分工 · Prometheus、OTel Collector、Grafana

Prometheus 的历史地位在于：它不只是一个软件，它定义的数据模型和查询语言成了整个行业的事实标准。

• 数据模型 —— “指标名 + 标签集 = 一条时间序列”这个模型被广泛采纳，连后来的 OpenTelemetry 也要兼容它。
• 暴露格式 —— /metrics 的文本格式后来标准化为 OpenMetrics，几乎所有中间件（数据库、消息队列、网关）都原生支持“吐一个 Prometheus 格式的端点”。
• PromQL —— 成了时序查询的通用语，VictoriaMetrics、Thanos、Mimir、云厂商的托管服务全都兼容它。

换句话说：即使你不用 Prometheus 这个进程，你大概率仍在用它的模型和语言。 这就是为什么本专栏花两个部分（TSDB + PromQL）深挖它的内核——你学的不是一个工具，是这个领域的通用语。它是 CNCF 继 Kubernetes 之后第二个毕业的项目，足见其地位。

OpenTelemetry（OTel）是一套标准 + 一族 SDK**；Collector 只是它生态里的一个组件。两者不是一回事。**

• OpenTelemetry 标准 —— 规定了三大支柱的数据模型、语义约定（比如 HTTP 请求该用哪些属性名）、以及传输协议 OTLP。这层是纸面规范。
• OTel SDK —— 各语言的埋点库（Java/Go/Python/...），让你在代码里产生符合标准的数据。
• OTel Collector —— 一个独立的进程，负责接收、加工、导出数据。它不是必须的（SDK 可以直连后端），但在生产里几乎总会用上——原因见下。

本专栏读的源码是 Collector（opentelemetry-collector-v0.156.0），但会顺带讲清标准和 OTLP 协议（第 5、6 部分）。记住：OTel 最大的价值其实是“标准”——它让埋点和后端解耦，你换后端不用重新埋点。

N 个数据源 × M 个后端 = N×M 种对接。加一个中转站，就变成 N+M。 这就是 Collector：它站在中间，接收各种格式（OTLP、Prometheus、Jaeger、Fluent...）、加工（过滤、改标签、批量、采样、脱敏）、导出到各种后端。

它的组件模型极其规整，源码目录一目了然：

opentelemetry-collector-v0.156.0/
├── receiver/    接收器:数据从哪进来
├── processor/   处理器:中间怎么加工
├── exporter/    导出器:数据往哪出去
├── connector/   连接器:把一条管道的输出接到另一条的输入
├── extension/   扩展:不碰数据的辅助能力(健康检查、认证等)
├── consumer/    消费者接口:组件间怎么传数据(背压在这)
├── pdata/       内部数据模型:三大支柱在内存里长什么样
├── pipeline/    管道定义
└── service/     服务编排(管道图的构建在这)

receiver → processor → exporter 是最经典的三段式。但有个反直觉的事实：Collector 的管道实际上是一张 DAG，靠拓扑排序构建和启动，而不是简单的线性链——第 5 部分会打开 service/internal/graph/graph.go 看这件事。

因为它们各自代表了可观测性的一个根本问题**，而且都是各自领域的头部实现：**

• Prometheus → “数据怎么存好查好”。这是算法与数据结构问题（压缩、索引、LSM），最有技术含量，也最能学到硬功夫。
• Collector → “数据怎么被灵活地运输”。这是软件架构问题（插件化、管道、背压、DAG），是学“如何设计可扩展系统”的绝佳样本。
• Grafana → “数据怎么被人理解”。这是抽象与产品问题（把千差万别的后端统一成一个心智模型）。

三个项目，三种不同性质的工程难题——这也是为什么读这三份源码的收获，远超“学会用监控”。它们分别是存储引擎、数据管道、统一抽象层的优秀范本，这些模式在别的领域一样通用。