5月27日 17:42

Prometheus 性能优化与水平扩展怎么做？

Prometheus 单实例在百万级时间序列下会出现采集延迟、查询超时、OOM 等问题。本文从采集、存储、查询三个维度给出调优手段，再对比 Thanos、Mimir、VictoriaMetrics 三种水平扩展方案的选型建议。

采集优化

分级采集间隔

根据业务重要性对 Target 设置不同的采集间隔。核心服务 15 秒，普通服务 30-60 秒，批量任务 120 秒。将全局 scrape_interval 从 15s 放宽到 30s，采样量直接减半。

yaml
global:
  scrape_interval: 30s

scrape_configs:
  - job_name: critical-service
    scrape_interval: 15s
  - job_name: batch-jobs
    scrape_interval: 120s

过滤高基数指标

高基数标签（如 user_id、container_id）会令时间序列数量爆炸。用 metric_relabel_configs 在采集端丢弃不需要的指标，从源头控制数据量。

yaml
metric_relabel_configs:
  - source_labels: [__name__]
    regex: 'go_.*|process_.*'
    action: drop
  - source_labels: [__name__]
    regex: 'container_.*_seconds_.*'
    action: drop

同时设置 sample_limit 和 target_limit 作为安全阀，防止误配置导致指标暴增。

yaml
scrape_configs:
  - job_name: api
    sample_limit: 10000
    target_limit: 100

水平分片采集

当单实例采集能力不足时，用 hashmod relabel 将 Target 分散到多个 Prometheus 实例，每个实例只抓取一部分。

yaml
global:
  external_labels:
    scraper: '1'

scrape_configs:
  - job_name: sharded
    relabel_configs:
      - source_labels: [__address__]
        modulus: 4
        target_label: __tmp_hash
        action: hashmod
      - source_labels: [__tmp_hash]
        regex: '1'
        action: keep

modulus 设为 4 表示 4 个分片，每个实例 regex 匹配自己的编号。配合 external_labels 标识来源，后续通过 Thanos 或 Mimir 聚合全局视图。

存储优化

TSDB 调优

开启 WAL 压缩和内存映射写入，降低磁盘 I/O 压力。

bash
--storage.tsdb.wal-compression=true
--storage.tsdb.wal-segment-size=20MB
--storage.tsdb.memory-map-on-write=true

控制数据保留期，避免磁盘写满。生产环境通常 15-30 天，长期数据交给对象存储。

bash
--storage.tsdb.retention.time=15d
--storage.tsdb.retention.size=80GB

Remote Write 异步写入

将数据异步写入远端存储，Prometheus 本地只保留短期热数据。建议在 Remote Write 前加一层缓存队列（如 Prometheus本身的 queue 配置），避免远端慢写入拖垮采集。

yaml
remote_write:
  - url: http://thanos-receive:19291/api/v1/receive
    queue_config:
      max_samples_per_send: 10000
      capacity: 50000
      max_shards: 50

查询优化

Recording Rules 预计算

将高频、耗时的 PromQL 查询预计算为 Recording Rule，Dashboard 和告警直接查询预计算结果，查询耗时从秒级降到毫秒级。

yaml
groups:
  - name: precompute
    interval: 30s
    rules:
      - record: job:http_requests:rate5m
        expr: sum by (job) (rate(http_requests_total[5m]))
      - record: namespace:cpu:usage
        expr: sum by (namespace) (rate(container_cpu_usage_seconds_total[5m]))

查询参数调优

bash
--query.max-samples=50000000
--query.timeout=2m
--query.lookback-delta=5m

max_samples 防止单次查询扫过多数据；lookback-delta 控制无数据时的回看窗口，调小可减少扫描量。

水平扩展方案选型

单实例垂直扩展有上限。当时间序列超过 200 万、查询 QPS 超过 50、存储保留期超过 30 天时，需要引入水平扩展方案。

方案对比

维度	Thanos	Grafana Mimir	VictoriaMetrics
架构模式	Sidecar 附加现有 Prometheus	独立分布式集群	单节点或集群模式
迁移成本	最低，Sidecar 无侵入	需要部署完整微服务栈	中等，改 remote_write 地址即可
长期存储	支持 S3/GCS 等对象存储	支持 S3/GCS/Azure	支持 S3/GCS
多租户	基本支持	强隔离，适合平台团队	有限支持
全局查询	Querier 聚合多实例	Query Frontend + Distributor	vmselect 聚合
运维复杂度	中等（4-5 个组件）	高（10+ 微服务）	低（1-3 个组件）
适用规模	中大型，已有 Prometheus	大型企业，需多租户	中小型到中大型
存储效率	2-4 倍压缩	中等	5-10 倍压缩，最省磁盘

Thanos 方案

Thanos 通过 Sidecar 组件附着在现有 Prometheus 上，将 TSDB 块上传到对象存储实现长期保留，Querier 提供跨实例全局查询。适合已有 Prometheus 部署、希望低摩擦迁移的团队。

核心组件：Sidecar（上传数据块）、Store Gateway（查询历史数据）、Compactor（压缩和降采样）、Querier（全局查询）、Query Frontend（查询缓存和分片）。

Grafana Mimir 方案

Mimir 是 Cortex 的继任者，提供完全分布式的多租户 Prometheus 兼容存储。2025 年底发布 v3.0，引入 Kafka 解耦架构。适合有平台团队、需要服务多业务线的大企业。注意：新部署不应选择 Cortex，直接用 Mimir。

VictoriaMetrics 方案

VictoriaMetrics 兼容 Prometheus API，单二进制部署即可运行。存储效率比原生 Prometheus 高 5-10 倍，资源占用低。500 节点 K8s 集群仅需 2-4 GB 内存，而 Prometheus 需要 8-16 GB。适合追求简单高效、中小规模到中大规模的团队。

联邦架构

联邦是 Prometheus 原生功能，用于层级化监控。子 Prometheus 采集各区域数据，父 Prometheus 通过 /federate 端点拉取聚合指标。

yaml
scrape_configs:
  - job_name: federate
    scrape_interval: 15s
    honor_labels: true
    metrics_path: /federate
    params:
      match[]:
        - '{__name__=~"job:.*"}'
    static_configs:
      - targets:
          - prometheus-region-a:9090
          - prometheus-region-b:9090

联邦适合多数据中心、多区域的层级聚合场景，不建议用作主要水平扩展手段——它只拉取聚合结果，原始数据仍在子实例上。

自身监控

监控 Prometheus 自身的关键指标，及时发现瓶颈：

promql
# 采集速率
rate(prometheus_tsdb_head_samples_appended_total[5m])

# 查询延迟
histogram_quantile(0.9, rate(prometheus_query_duration_seconds_bucket[5m]))

# WAL 写入滞留
rate(prometheus_tsdb_wal_writes_failed_total[5m])

# 磁盘使用
prometheus_tsdb_storage_blocks_bytes

建议对这些指标设置告警：采集速率突降、P90 查询超过 10 秒、WAL 写入失败、磁盘使用超 80%。

容量规划参考

规模	活跃时间序列	内存	CPU	磁盘（30天）	建议
小型	<50 万	4 GB	2 核	50 GB	单实例 + 基础优化
中型	50-200 万	8-16 GB	4-8 核	100-200 GB	单实例 + Recording Rules + Remote Write
大型	200-1000 万	需分片	需分片	需对象存储	Thanos/VictoriaMetrics 集群
超大型	>1000 万	分布式	分布式	对象存储	Mimir 分布式集群

要点总结

采集端通过分级间隔、过滤高基数指标和水平分片控制数据入口；存储端通过 WAL 压缩、内存映射和 Remote Write 分离冷热数据；查询端用 Recording Rules 预计算并调优查询参数。超出单实例能力时，中小团队首选 VictoriaMetrics 或 Thanos，大型企业选 Mimir。联邦架构用于多区域层级聚合，不替代水平扩展。持续监控 Prometheus 自身指标，在瓶颈出现前提前扩容。

标签：Prometheus