OpenTelemetry 对接 Prometheus 后端：OTLP 直推的配置与数据模型避坑

OpenTelemetry 与 Prometheus 的组合逻辑是"用 OTel 统一埋点，用 Prometheus 存储查询"——埋点层厂商中立、一次接入多端导出，存储层继续沿用团队熟悉的 PromQL 与 Grafana 生态，两者各取所长。

核心要点速览

• 组合价值：标准化埋点 + 熟悉的存储查询 + 独立扩缩容 + 双社区背书；
• Prometheus 需显式开启 OTLP 接收端点（默认关闭）；
• 数据模型关键差异：资源属性需"提升"为标签、Delta/Cumulative 时间性转换；
• 生产上警惕标签基数膨胀，提升属性务必克制。

为什么要把 OTel 指标送进 Prometheus？

五个现实理由：

1. 埋点标准化：OTel 提供跨语言的中立 API/SDK，埋一次点，后端随便换；
2. 存储查询强大：Prometheus 的时序库 + PromQL 是指标分析的事实标准；
3. 部署灵活：埋点、管道、存储三层各自独立扩缩容；
4. 社区双保险：两个 CNCF 顶级项目，长期演进有保障；
5. 统一可观测：指标走 Prometheus，链路日志走 OTel 生态，埋点层只有一套。

如何配置对接？

Prometheus 的 OTLP 接收默认关闭（安全考虑），需显式开启：

prometheus --web.enable-otlp-receiver

应用侧用 OTel SDK 的 OTLP exporter 直推：

exporters:
  otlp:
    endpoint: "http://prometheus:9090/api/v1/otlp"

如果中间经过 Collector，则在 Collector 配置同样的导出端点——推荐后者，便于批量处理与路由。

数据模型的三个关键差异

1. 资源属性 → 标签：OTel 用资源属性描述数据产生者（service.name、Pod 名等），Prometheus 只有标签。两种对接方式：

• 提升为标签：在 prometheus.yml 配置 otlp.promote_resource_attributes，把 service.name、k8s.pod.name 等直接变成可查询标签；
• 走 target_info：不提升，属性存在特殊指标 target_info 里，查询时 join——查询繁琐但基数安全。

service.name 与 service.instance.id 会被自动映射为 Prometheus 的 job 与 instance 标签，无需手动处理。

2. 基数红线：每提升一个属性就乘以一份组合数。经验法则——唯一标签组合总数控制在百万级以内，否则 Prometheus 性能急剧劣化（参见《高基数问题》）。

3. 时间性与命名：OTel 指标有 Delta/Cumulative 两种时间性（见《指标对比》），Prometheus 只认 Cumulative——Prometheus 3.0 会自动转换 Delta 并统一命名（计数器加 _total 后缀），老版本则需要在 SDK 或 Collector 侧强制 Cumulative 输出。

生产注意事项

• 给 OTLP 端点加认证：开启接收等于开了一个写入口，内网也要配 Basic Auth 或 mTLS；
• 批量导出：应用侧或 Collector 侧务必配 batch，避免每指标一请求；
• Remote Write 兜底：大规模场景建议 Prometheus 只做采集层，长期存储交给兼容 Remote Write 的时序库；
• 验证映射：上线前先推一条测试指标，确认标签映射与命名符合预期。

观测云落地：不维护 Prometheus 的另一种选择

如果你的目标是"指标可查可告警"而非"必须是 Prometheus"，观测云可以整体替代这一组合：应用经 OTel SDK 埋点后，DataKit 的 OTLP 接收器直接接收指标数据，资源属性自动保留为观测云标签，在指标模块用 DQL 查询、用监控器配告警——没有 Prometheus 运维、没有基数焦虑、没有 Remote Write 架构设计。

已有 Prometheus 资产的用户也不必推倒重来：DataKit 支持直接抓取 Prometheus 暴露的 /metrics 端点，把存量指标平滑迁移进观测云统一分析。

常见问题（FAQ）

Q：Prometheus 2.x 能接 OTLP 吗？ OTLP 接收需要 2.47+ 并开启特性开关，3.0 起体验完整（含自动 Delta 转换与 UTF-8 支持）。老版本建议走 Collector 的 prometheusremotewrite 导出器。

Q：直推和经过 Collector 哪个好？ 生产推荐经过 Collector（或 DataKit）：批量、重试、属性处理都在管道层完成，应用侧保持轻量。

Q：资源属性全提升会怎样？ 标签基数爆炸，Prometheus 内存飙升甚至 OOM。只提升查询确实需要的维度，其余留在 target_info。

Q：观测云支持 PromQL 吗？ 观测云使用自研 DQL 查询语言，覆盖 PromQL 的聚合、过滤、计算场景；存量 Grafana 看板可按指标逐个迁移，核心告警规则迁移工作量通常在小时级。

系列阅读

• 上一篇：《OpenTelemetry 最佳实践》
• 下一篇：《K8s 部署 OpenTelemetry Collector》
• 相关：《OpenTelemetry 与 Prometheus 对比》 · 《OpenTelemetry 指标 vs Prometheus 指标》 · 《返回索引》