OpenTelemetry vs Prometheus：定位、差异与协同
OpenTelemetry 与 Prometheus 是可观测性领域最常见的两个开源项目，但定位不同：OTel 统一遥测数据的生产与传输，Prometheus 专注指标的抓取、存储与告警。本文系统对比两者，并给出共存与迁移建议。
OpenTelemetry 是覆盖链路、指标、日志三大信号的埋点与传输标准；Prometheus 是以拉取模型为核心的指标数据库与告警系统——两者解决不同层的问题：OTel 管「数据怎么产生和送出来」，Prometheus 管「指标怎么存和怎么报警」。实践中它们经常组合使用，而非二选一。
核心要点速览
- 信号范围：OTel 覆盖链路/指标/日志，Prometheus 只做指标；
- 采集模型：OTel 主推（push）到 Collector/后端，Prometheus 主拉（pull）；
- 生态角色：OTel 是「生产与传输标准」，Prometheus 是「指标存储与查询」的经典实现；
- 协同模式：OTel SDK 埋点 → Collector 转换 → Prometheus 或观测云存储分析。
两者的核心差异
| 维度 | OpenTelemetry | Prometheus |
|---|---|---|
| 定位 | 遥测生产/传输标准 | 指标存储 + 告警系统 |
| 信号 | 链路、指标、日志 | 仅指标 |
| 数据模型 | OTLP（push 为主） | 时间线（pull 为主，文本协议） |
| 存储 | 无（需后端） | 内置 TSDB |
| 查询 | 无（依赖后端） | PromQL |
| 告警 | 无 | Alertmanager |
| 治理方 | CNCF | CNCF |
什么时候用哪个？
- 应用埋点与链路追踪：OpenTelemetry 是无可争议的选择，Prometheus 不做链路；
- 基础设施指标告警：Prometheus 成熟简单（node_exporter + 告警规则），OTel Collector 的
hostmetricsreceiver 也能做； - 多信号统一平台：两者数据最终都需要一个统一平台来关联分析——这正是观测云的位置。
两者如何协同？
三种常见架构：
- OTel 埋点 + Prometheus 存储：SDK 暴露 Prometheus 端点，Prom 抓取——简单但丢了链路；
- OTel 埋点 + Collector 转换 + 观测云：全信号进入观测云，指标模块支持类 PromQL 查询（DQL），链路进 APM，日志进日志模块——信号关联最完整；
- 存量 Prom + 观测云：DataKit 直接抓取
/metrics或接收 remote write，Prometheus 只保留边缘采集角色。
观测云落地：兼容两边生态
观测云对两个生态都是一等公民：OTLP 全信号原生接收；Prometheus 的 exporter 指标、remote write、ServiceMonitor CRD 全部支持。团队可以从任意一侧起步，最终汇聚到统一平台做关联分析与告警。
常见问题（FAQ）
Q：Prometheus 会被 OpenTelemetry 取代吗？ 短期内不会。两者定位不同且都在演进：OTel 标准化数据生产，Prometheus 生态在指标告警领域依然强势。长期看 OTLP 作为交换格式的渗透率会持续提高。
Q：已经在用 Prometheus 全家桶，迁到观测云要多大成本？ DataKit 可直接抓取现有 exporter 指标或接收 remote write，告警规则可平移到监控器，无需改动应用。
Q：OTel Collector 和 Prometheus Agent 模式有什么重叠？ 两者都能做指标抓取与转发。二选一即可；若还需要日志与链路，OTel Collector 或 DataKit 一站覆盖更省。
Q：PromQL 查询在观测云里怎么用？ 观测云指标查询使用 DQL，语义与 PromQL 类似（速率、聚合、分维度），迁移成本低；同时保留对 PromQL 生态数据的完整存储。
