Prometheus远程写入与长期存储部署指南

背景

在运维监控体系中，Prometheus因其灵活的数据模型和强大的查询能力被广泛采用。然而，单实例Prometheus的存储容量和时长受限于本地磁盘，高频采集场景下通常只能保留15~30天。对于需要长期历史数据进行分析、审计或容量规划的企业来说，远程写入（Remote Write）实现数据持久化是必经之路。

远程写入原理

Remote Write 是 Prometheus 从 v2.25.0 开始稳定支持的功能，允许 Prometheus 将采集的样本数据通过网络协议实时推送到远程接收端。其核心流程如下：

  1. 样本生成：Prometheus 抓取 Targets 后，将指标样本存储在本地 TSDB 中，同时触发 Remote Write 队列。
  2. 序列化与发送：后台 goroutine 定期将队列中的样本序列化为 protobuf 格式，通过 HTTP/HTTPS 推送到 remote_write_url。
  3. 确认与重试：若接收端返回非 2xx 响应或网络中断，Remote Write 会自动重试并保留数据在本地 WAL（预写日志）中。

关键配置参数：

  • remote_write.url：接收端地址
  • remote_write.queue：可调整 capacity、batch_send_deadline、min_shards 等优化吞吐量
  • remote_write.tls_config：支持 HTTPS 双向认证

方案选型：Thanos vs VMStorage

部署远程写入接收端时，主流方案有两类：

Thanos Sidecar 模式

在每个 Prometheus 实例旁运行一个 Thanos Sidecar 容器，通过 Remote Write 将数据写入对象存储（如 S3、MinIO）。优势在于：

  • 原生支持 99 年数据保留：基于对象存储的无限容量
  • 全局视图：通过 Thanos Query 实现多集群联邦查询
  • 压缩与降采：自动执行 2h → 30d → 90d 的分级压缩

不足是 Sidecar 占用额外资源，且对象存储本身有使用成本。

VictoriaMetrics

作为 Prometheus 远程存储的专业替代方案，VictoriaMetrics 以单节点高性能著称：

  • 单实例可接收数百万指标每秒写入
  • 存储效率高，30天数据占用远低于同等规模的 Prometheus 本地存储
  • 支持 clustering 模式水平扩展

适合监控规模中等、追求部署简便的团队。

生产环境部署步骤（以 Thanos 为例）

第一步：部署 MinIO 对象存储

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
# docker-compose.yml
version: '3.8'
services:
  minio:
    image: minio/minio:latest
    ports:
      - "9000:9000"
      - "9001:9001"
    environment:
      MINIO_ROOT_USER: admin
      MINIO_ROOT_PASSWORD: password123
    command: server /data --console-address ":9001"
    volumes:
      - minio-data:/data
volumes:
  minio-data:

启动后访问 http://localhost:9001 创建名为 thanos 的 bucket。

第二步：修改 Prometheus 配置文件

1
2
3
4
5
6
7
8
# prometheus.yml
remote_write:
  - url: http://localhost:10908/api/v1/write
    queue_config:
      capacity: 10000
      min_shards: 4
      max_shards: 32
      batch_send_deadline: 10s

第三步：启动 Thanos Sidecar

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
# thanos-sidecar.yml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: thanos-sidecar
spec:
  replicas: 1
  template:
    spec:
      containers:
        - name: thanos
          image: quay.io/thanos/thanos:v0.35.1
          args:
            - sidecar
            - --prometheus.url=http://prometheus:9090
            - --objstore.config-file=/etc/thanos/minio.yaml
          volumeMounts:
            - name: minio-config
              mountPath: /etc/thanos
      volumes:
        - name: minio-config
          configMap:
            name: minio-config
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: minio-config
data:
  minio.yaml: |
    type: S3
    config:
      bucket: thanos
      endpoint: minio:9000
      access_key: admin
      secret_key: password123
      insecure: true

第四步：验证数据持久化

1
2
3
4
5
# 检查对象存储中的块数据
docker exec -it <minio-container> mc ls thanos/

# 查看 Thanos Store 发现的块
docker exec -it <thanos-store> thanos tools bucket ls --objstore.config-file=/etc/thanos/minio.yaml

常见问题排查

Remote Write 延迟升高

若发现 remote_write 队列持续积压，首先检查：

  • 网络带宽是否成为瓶颈（Remote Write 默认使用 gzip 压缩，可调整 compression: snappy）
  • 接收端处理能力：查看 VictoriaMetrics 或 Thanos Receiver 的 ingestion 速率指标
  • WAL 磁盘是否满：Prometheus 将未确认的数据写入 WAL，默认在 data/wal 目录

数据一致性问题

使用 Prometheus API 验证本地与远程数据偏差：

1
2
3
# 查询本地与远程（通过 Thanos）同一时间点的指标总量
curl -s http://localhost:9090/api/v1/query?q=up | jq '.data.result | length'
curl -s http://thanos-query:9090/api/v1/query?q=up | jq '.data.result | length'

若数量差异超过 5%，需检查网络丢包或接收端写入失败日志。

总结

通过 Prometheus Remote Write 将监控数据外推到专门存储系统，可在不牺牲查询性能的前提下实现任意时长的历史数据保留。Thanos 适合需要跨实例聚合和无限存储的场景；VictoriaMetrics 则在单节点性能与运维简便性上更胜一筹。根据实际规模与团队能力选择对应方案，能有效降低长期数据存储的复杂度。