Prometheus 远程写入生态的新关注点

如果把 Prometheus 远程写入只看成“把样本发到远端”，这次生态变化很容易被误读。现在更值得关注的是：发送端和接收端能否说清楚使用的协议、哪些样本真的写入成功，以及 Prometheus 与 OpenTelemetry 混合之后，标签、元数据和命名是否仍然可控。

官方地址：https://prometheus.io/

生态关注点已经从单点发送转向互操作

Prometheus 官方 2026 年 9 月发布的互操作调查，分析了 81 名活跃使用 OpenTelemetry 指标、同时使用 Prometheus 相关后端的受访者。调查中，基础设施侧 Prometheus exporter 使用率为 72%，OTel receiver 为 57%，49% 的受访者同时使用两种采集风格；应用指标侧 OTel SDK 为 65%，Prometheus SDK 为 52%。这组数据不等于全行业普查，但足以说明迁移叙事正在变成混合部署。

因此，远程写入生态的新关注点不是“谁替代谁”，而是边界能不能稳定地接起来：Prometheus 的 relabeling、OTel Collector 的处理、PromQL 后端的存储，以及接收端对元数据的理解，都需要放在同一条链路里看。

Remote Write 2.0 把“写入成功”说得更具体

Remote Write 2.0 规范仍标记为 Experimental。它引入 io.prometheus.write.v2.Request，并逐步淡化旧的 prometheus.WriteRequest；新消息可以承载元数据、exemplar、start timestamp 和原生直方图，还通过 symbols 表复用字符串。

这个方向的价值在于接收端不必只收到一串样本数字，还能得到更完整的语义。但它也带来一个现实边界：2.0 不是把 1.0 的请求头换个版本号就结束，接收端必须按 Content-Type 识别消息。对 1.x 接收端保持兼容时，发送端通常需要回到兼容的媒体类型和版本声明。

接收端兼容性要用响应头和错误码验证

一个常见误区是看到 2xx 就认为整批数据可靠落库。Remote Write 2.0 规范要求接收端在同步处理完成后，用专门的 Written 响应头报告样本、直方图和 exemplar 的成功数量；异步返回 202 时，因为校验可能延后，不能把缺失响应头简单解释成零写入。

如果发送 2.0 消息得到 415，问题可能是接收端不支持该媒体类型，而不是业务数据坏了。此时可以按接收端文档降级到兼容格式；但对 400、非可重试的 4xx 不应盲目重放。429 和 5xx 才进入带退避的重试路径，部分写入场景还要求接收端具备幂等能力。

升级时先盯住积压、内存和语义漂移

协议升级不能绕开 Prometheus 本地队列。官方调优文档说明，远程写入从 WAL 读取后进入按 shard 划分的内存队列；队列被填满会阻塞继续读取 WAL。远端持续不可用超过约两小时，尚未送出的 WAL 数据可能随压缩而丢失。上线前应同时观察 prometheus_remote_storage_samples_pending、CPU、网络、队列容量和后端拒绝率。

remote_write:
  - url: https://metrics.example.invalid/api/v1/write
    queue_config:
      # 容量先按每个 shard 的突发量估算，避免只加大并发。
      capacity: 10000
      # 批量越大不一定越快，要结合接收端单请求限制。
      max_samples_per_send: 2000
      # 失败重试使用退避，避免后端恢复时被瞬间打满。
      min_backoff: 30ms
      max_backoff: 5s

这段配置只展示观察维度，不代表所有后端都适合相同参数。官方建议 capacity 通常取 max_samples_per_send 的 3 到 10 倍，同时要留意 shard 数量和内存；迁移时应先用小流量灰度，再比较 pending、写入计数和查询结果，而不是一次性放大队列。

常见问题

Remote Write 2.0 现在能直接替换所有 1.x 接收端吗？

不能。规范仍是 Experimental，2.0 消息和 1.x 兼容格式的协商边界必须由发送端、接收端和后端产品共同确认。

HTTP 202 代表数据已经写入了吗？

不一定。202 只表示接收端接受了异步处理请求，后续校验或落库可能尚未完成，不能按同步 2xx 的规则推断 Written 数量。

Prometheus 和 OpenTelemetry 应该二选一吗？

从官方调查看，混合使用已经很常见。更稳妥的做法是先明确标签、资源属性和命名转换边界，再决定在哪一层做 relabeling 或 Collector 处理。

把这次生态变化落地成一句话：先验证协议和数据语义，再调队列吞吐；先证明兼容和可恢复，再扩大远程写入范围。