remote write 积压几十万条 监控数据为什么延迟十分钟

这类问题我又碰上了一次。Prometheus 2.45 往远端写数据，队列积压到八十万条，远端查询的数据延迟十分钟，日志里是 remote storage queue is full，本地查询却完全正常。

第一反应是「单批样本太多，一次请求超时被对端拒绝」，验证下来不成立。

把日志和配置对完，能解释这个现象的基本就这几处。远端存储写入慢，队列满了之后只能丢弃或者阻塞；max_shards 配得太小，并发不够，吞吐上不去；到远端机房的带宽被其他同步任务占满。

先看队列和失败的计数

curl -s 127.0.0.1:9090/metrics | grep -E 'prometheus_remote_storage_(queue|failed|dropped)' | head

测一次到远端的写入耗时

curl -o /dev/null -s -w '%{time_total}\n' -X POST http://remote-write.example.com/api/v1/write --data-binary 'x'

调大分片数和单批样本量

sed -i 's/^\s*max_shards:.*/    max_shards: 50/' /etc/prometheus/prometheus.yml && sed -i 's/^\s*max_samples_per_send:.*/    max_samples_per_send: 5000/' /etc/prometheus/prometheus.yml

等前面都确认过，再重载后观察队列是否回落

curl -X POST 127.0.0.1:9090/-/reload && sleep 120 && curl -s 127.0.0.1:9090/metrics | grep 'prometheus_remote_storage_queue_highest_sent_timestamp' | head -3

怎么算真的好了，看的是同一批现象。队列积压降到一万条以内，远端数据延迟从十分钟缩到一分钟，dropped_samples_total 不再增长。

提醒一点。队列满了就会丢数据，宁可加 shards 也别让积压长期存在；远端写入能力和带宽要一起评估，只调 Prometheus 治不了根。同一份配置在测试环境跑通，不代表线上没事，两边的默认值经常不一样。