Prometheus 接收 OTLP 指标带来哪些部署选择

一个团队已经用 Prometheus 抓取基础设施指标，新服务却采用 OpenTelemetry SDK。此时不必先把所有指标改回抓取形式：Prometheus 提供 OTLP HTTP 指标接收入口，应用可以直接发送，也可以经过 Collector 转发；原有抓取任务仍可按业务边界保留。

这带来的部署选择，是应用与指标后端之间可以有不同的中间层，而不是“OTLP 已经取代 Prometheus 抓取”。官方地址：https://prometheus.io/。下文依据官方现有能力讨论接入方向，不声称它在最近某一天刚刚发布，也不把示例当成已完成的部署。

先把指标接收与全信号后端分开

这里讨论的是 Prometheus 接收 OTLP 指标。接收器使用 HTTP，指标请求路径为 /api/v1/otlp/v1/metrics；不能把一个只会向 gRPC 端口发送的客户端，直接指向这个 HTTP 接口。也不能把 traces、logs 一并送给 Prometheus，期待它自动成为三种信号的统一存储。

接收开关是 --web.enable-otlp-receiver，默认关闭。不要把它与 Remote Write receiver 的开关混淆，也不要从旧的 feature flag 示例推断当前版本的启动方式。真正部署时，应使用与你安装的二进制版本对应的帮助和文档，而不是只复制 latest 页面里的所有实验选项。

对于这个假设团队，先确定三个条件：新服务能导出什么协议；有没有统一治理和多后端需求；旧指标的查询与告警是否必须保持。下面的三种接入形态，就从这三个条件出发。

应用直连、Collector 转发与原有抓取怎样选

直连路径里，应用 SDK 与 Prometheus OTLP 接收端直接建立指标发送关系。Collector 路径则多了一层：SDK 对接 Collector，Collector 用合适的 HTTP 指标导出配置对接接收端。Collector 是可选的治理层，不是因为 Prometheus 有 OTLP 接收能力就失去价值。

OpenTelemetry 官方列出 Agent、Gateway 等 Collector 部署模式。这里不要求某一种必须搭配 Prometheus；选择取决于你希望把处理逻辑放在应用附近，还是集中管理。对本例团队，先让一组新服务走 Collector、保留旧 exporter 抓取，是一种便于限定迁移范围的方案，而不是性能必然更好的结论。

如果保留抓取链路，Prometheus 抓取端仍对接 exporter；不要让同一个逻辑指标未经设计地同时从 OTLP 和 scrape 两边进入相同统计口径。即使标签不同而没有发生写入冲突，也可能在聚合查询中被算两遍。

在隔离实例上只启用需要的入口

先准备一份独立测试用的 prometheus.yaml，并使用独立数据目录。下面是本机试点启动示例，不是生产部署命令，也没有在本文环境执行：

# 仅监听本机，启用指标接收；配置和数据目录须与现有实例隔离
prometheus --config.file=./prometheus.yaml \
  --storage.tsdb.path=./data-otlp-demo \
  --web.listen-address=127.0.0.1:9090 \
  --web.enable-otlp-receiver

发送端需要选择 OTLP HTTP，并确保最终指标请求落到上面的完整路径。SDK 和 Collector 对“基础 endpoint”与“指标专用 endpoint”的拼接约定不一定相同；按所用实现的文档配置，不要统一手工追加一次 /v1/metrics，再被实现追加第二次。可以把最终请求地址是否正确作为测试环境中的检查项。

Collector 侧要选择支持 HTTP 的导出组件，并把接收组件、处理组件与导出组件明确加入 metrics pipeline。只在配置中声明 exporter，并不意味着它已经启用。组件名称及可用性与 Collector 发行版、版本有关，本文不提供可跨所有版本直接复制的完整 YAML。

本机地址的含义也要保持清楚：若 Collector 和 Prometheus 在不同容器或主机中，Collector 看到的 localhost 并不是 Prometheus。示例刻意绑定回环地址；跨进程网络边界的生产接入需要另外设计可达地址、认证、TLS 和访问限制，而不是为了连通就把接收端直接暴露到公网。

能接收之后，还要统一标签和时间语义

试点可以先选一项业务计数指标，记录它的名称、单位、服务身份和预期标签集合。资源属性、指标属性与 Prometheus 标签不是任意等同的。官方提供资源属性提升及名称翻译等配置方向，团队应只选择查询真正需要的维度，不要把所有动态资源属性都变成长期标签。

例如“服务身份”要能区分同服务的不同实例，“标签集合”要能支持原本的聚合逻辑；名称和单位变化则可能影响看板与告警。这里的决定应该写成指标契约，跟随试点保存，而不是只看接收接口是否返回成功。

时间语义也不能靠换协议解决。当前 feature flags 文档分别列出 otlp-deltatocumulative 和 otlp-native-delta-ingestion，两者不能一起启用；前者维护转换状态，后者保留原始 delta 值且仍处于早期阶段。原始 delta 不能不加区分地沿用面向累计计数器的 rate 等查询。若本来只需要累计指标，就不要为了“功能完整”而同时试开一批实验开关。

经 Collector 批处理、多个副本发送等条件下，还需评估乱序样本；Prometheus 提供 storage.tsdb.out_of_order_time_window 配置方向，但窗口不是解决重复采集和标签混乱的替代品。先确定实际链路和可接受延迟，再决定是否需要调整。

用一组服务试点，再决定是否扩大

对前面的团队，一个可控推进方式是：选一组非核心测试服务，固定 SDK 与 Collector 版本，选定累计指标口径，并记录正式发送地址和身份映射。保持原有告警链路不动，先观察新指标；需要对照时隔离测试存储或明确区分标签，不把两条副本一起作为生产统计输入。

在自己的测试环境中，应观察发送错误、接收错误、样本数量、标签基数及预期查询结果；必要时模拟接收端短时不可达，看应用或 Collector 的行为是否符合约定。这些是建议执行的试点动作，不是本文的测量结果，也不保证增加 Collector 就不会丢数据。

回退方案要与变更范围对应。若只改了一个测试服务的出口，回退就是恢复这项出口配置；若同时停掉旧抓取，就还要恢复它以及依赖的告警。不要把回退理解为简单删除实验指标，也不要在没有确认新旧口径一致前批量替换看板。

OTLP 接收能力扩展了 Prometheus 的接入选择，但没有消除指标建模、发送治理和查询兼容的工作。实际收益是可以按服务逐步采用 OpenTelemetry，同时让稳定的抓取资产继续工作。

官方资料

Prometheus OpenTelemetry 指南：https://prometheus.io/docs/guides/opentelemetry/

启动参数：https://prometheus.io/docs/prometheus/latest/command-line/prometheus/

实验能力边界：https://prometheus.io/docs/prometheus/latest/feature_flags/

Collector 部署模式与配置：https://opentelemetry.io/docs/collector/deploy/、https://opentelemetry.io/docs/collector/configuration/