乐闻世界logo
5月27日 17:49

Prometheus Remote Write 和 Remote Read 怎么配置？

Prometheus 自带的本地 TSDB 存储有容量和时效的限制，当数据量增长或需要跨集群查询时，就要借助 Remote Write 和 Remote Read 将数据外接到远程存储。这两个接口是 Prometheus 官方定义的标准协议，所有兼容的存储后端都能无缝对接。

Remote Write 的工作流程

Prometheus 采集到指标后，样本先写入本地 WAL（预写日志），Remote Write 组件从 WAL 中批量读取新样本，经过队列缓冲和分片后，以 Protobuf 编码通过 HTTP POST 发送到远端端点。整个过程是异步的，即使远端暂时不可用，队列也会按退避策略重试，不会阻塞采集。

典型配置：

yaml
remote_write:
  - url: "http://remote-storage:9201/api/v1/write"
    basic_auth:
      username: "user"
      password: "pass"
    queue_config:
      capacity: 10000
      max_shards: 50
      min_shards: 1
      max_samples_per_send: 1000
      batch_send_deadline: 5s
      min_backoff: 30ms
      max_backoff: 100ms
    write_relabel_configs:
      - source_labels: [__name__]
        regex: 'expensive_.*'
        action: drop

队列参数解析：

  • capacity — 内存队列中缓存的样本上限，超出会阻塞写入
  • max_shards / min_shards — 动态分片的上下限，分片越多吞吐越高，但内存和 CPU 开销也越大
  • max_samples_per_send — 每次请求发送的最大样本数，值越大吞吐越高，但单次失败代价也更大
  • batch_send_deadline — 即使样本数未达到 max_samples_per_send，超过此时间也会强制发送
  • min_backoff / max_backoff — 发送失败后的重试退避范围，避免雪崩式重试

write_relabel_configs 可以在发送前过滤或改写标签，比如丢弃 expensive_ 前缀的高基数指标，减少远程存储的压力。

Remote Read 的工作流程

当用户在 Prometheus UI 或 Grafana 发起查询时，如果本地 TSDB 没有对应数据，Prometheus 会向 remote_read 端点发送 Protobuf 编码的查询请求，远端存储返回匹配的时间序列样本，Prometheus 将其与本地数据合并后返回给用户。

典型配置：

yaml
remote_read:
  - url: "http://remote-storage:9201/api/v1/read"
    read_recent: true
    basic_auth:
      username: "user"
      password: "pass"

read_recent: true 表示优先从本地读取近期数据，只向远端请求本地没有的历史数据，能显著降低查询延迟。设为 false 则所有数据都从远端获取。

主流远程存储后端

后端特点
Thanos基于 OSS/S3 的长期存储，支持全局查询视图，社区活跃
VictoriaMetrics高性能压缩，兼容 Remote Write 协议，部署简单
Cortex多租户架构，适合大规模集群，依赖组件较多
M3DB分布式时序数据库，Uber 开源，擅长高基数场景
InfluxDB生态成熟，支持多种写入协议
TimescaleDB基于 PostgreSQL，适合已有 PG 运维经验的团队

常见问题与最佳实践

内存增长：开启 Remote Write 后 Prometheus 内存通常增加约 25%，因为需要在内存中缓存序列 ID 到标签值的映射。建议监控 prometheus_remote_storage_queue_length，如果队列持续积压，需要调大 max_shards 或检查网络。

数据丢失风险：如果 Prometheus 异常退出且 WAL 未及时同步，极端情况下可能丢失少量数据。确保 queue_config 中的重试和退避参数合理配置。

性能监控指标：

  • prometheus_remote_storage_queue_length — 当前队列深度
  • prometheus_remote_storage_failed_samples_total — 发送失败累计次数
  • prometheus_remote_storage_succeeded_samples_total — 发送成功累计次数
  • prometheus_remote_storage_highest_timestamp_in_seconds — 已成功发送的最大时间戳

标签过滤：始终用 write_relabel_configs 过滤不需要的高基数指标，避免远程存储膨胀和查询变慢。

网络压缩：Remote Write 默认使用 Snappy 压缩，部分后端也支持 gzip。确保远端支持对应压缩格式以减少带宽占用。

配置思路总结

  1. 先确定长期存储后端（VictoriaMetrics 入门最简单）
  2. 配置 remote_write，用 write_relabel_configs 过滤高基数指标
  3. 按实际吞吐调整 queue_config，从小分片起步逐步扩容
  4. 配置 remote_read 并开启 read_recent: true
  5. 在 Grafana 中添加 Remote Write 相关的面板，持续监控队列和失败率
标签：Prometheus