Prometheus采集量激增导致香港服务器负载飙高？如何通过PushGateway + remote_write降采样维稳？

在一次故障复盘会上，我意识到团队部署在香港的监控系统正成为业务稳定性的瓶颈。Prometheus 的采集量在高并发业务高峰期急剧增长，直接拖垮了我们部署在物理服务器上的监控实例，造成机器负载飙升、响应延迟，甚至影响到了实际业务的告警准确性和时效性。这个问题不能再拖，我决定在现有架构基础上，优化指标采集链路，核心策略是引入 PushGateway 缓冲和 remote_write 降采样，构建更稳定的数据通路。

一、背景分析：Prometheus 拉模式在高密度环境下的隐患

我们的香港节点监控了上百个微服务实例和近二十台裸金属服务器，平均每台机器暴露超过 10 万个指标样本。当 Prometheus 以默认 15s 的 scrape 周期拉取这些 target 时，Prometheus 本身的 CPU 占用迅速拉高，甚至频繁 OOM。进一步分析发现，两个问题非常突出：

• 高频 scrape + 高维度指标爆炸：微服务暴露了大量 label 组合，导致时序数量过万。
• 短周期 scrape 多 target 拉取延迟重叠：导致单节点 Prometheus scrape queue 累积、掉采样。
• 我们意识到，仅靠单体 Prometheus 已无法负担如此高密度的数据拉取任务。

二、架构改造目标

为了缓解 Prometheus 本体压力并提升系统稳定性，我们明确以下目标：

• 削减 Prometheus 主体采集任务：通过 PushGateway 接收短生命周期或高频指标；
• 在远端落盘前降采样：利用 remote_write + prometheus-mimir 实现写前聚合；
• 优化目标探测频率：对部分低频指标 target 提高 scrape 间隔；
• 保证告警不丢失、核心时序保留：关键时序进入 HA Prometheus 分组保存。

三、实战部署步骤

1. 引入 PushGateway 收敛高频指标

对于容器生命周期极短（如批处理 Job、短命服务）的指标，我将其改造为使用 push 模式：

部署 PushGateway：

docker run -d --name pushgateway \
  -p 9091:9091 \
  prom/pushgateway

应用侧推送示例（Go 语言）

import (
    "github.com/prometheus/client_golang/prometheus"
    "github.com/prometheus/client_golang/prometheus/push"
)

jobDuration := prometheus.NewGauge(prometheus.GaugeOpts{
    Name: "job_duration_seconds",
    Help: "Job duration in seconds.",
})

jobDuration.Set(3.5)
push.New("http://localhost:9091", "batch_job").
    Collector(jobDuration).
    Grouping("instance", "hk-job01").
    Push()

Prometheus 配置 pull PushGateway：

scrape_configs:
  - job_name: 'pushgateway'
    static_configs:
      - targets: ['localhost:9091']
    scrape_interval: 30s

通过 PushGateway 中转，我们将大量短周期数据从主动拉模式转为被动汇总，缓解了主 Prometheus 的 scrape 任务压力。

2. 配置 remote_write + 降采样聚合规则

我们将采集到的数据统一 remote_write 到远端 Mimir 集群，并在本地 Prometheus 设置降采样规则，只上报核心指标。

示例 remote_write 配置：

remote_write:
  - url: "http://mimir-gw.hk.example.com/api/v1/push"
    queue_config:
      max_samples_per_send: 10000
      batch_send_deadline: 5s
      capacity: 50000

本地聚合规则示例：

groups:
- name: instance_cpu_usage
  interval: 1m
  rules:
  - record: instance:cpu_usage:rate1m
    expr: rate(node_cpu_seconds_total{mode="user"}[1m])
    labels:
      region: "hk"

注意：这类降采样会舍弃高频 granularity，建议将聚合写入不同 prefix（如 instance:xxx:rate1m），保留原始数据用于核心节点分析。

3. 精简 target 与 scrape 策略

我们还对 scrape 配置进行了分级处理：

• 核心业务指标：15s 周期（如 API 网关、支付系统）；
• 次要系统服务：60s 周期（如日志收集器、CI Agent）；
• 无状态边缘节点：仅在 pushgateway 上报，不直接 scrape。

优化后的配置片段：

scrape_configs:
  - job_name: 'critical_services'
    scrape_interval: 15s
    static_configs:
      - targets: ['10.0.0.1:9100', '10.0.0.2:9100']

  - job_name: 'edge_nodes'
    scrape_interval: 60s
    relabel_configs:
      - source_labels: [__address__]
        regex: '10\.0\.5\..*'
        action: drop  # 转由 PushGateway 替代

四、监控效果与资源变化

实施该方案两周后，我们观察到了以下关键改善：

指标项	优化前	优化后
Prometheus 实例 CPU	70~95%	15~30%
时序数量	480,000+	130,000 左右
抓取失败数	每小时 200+ 次	0~3 次
报警延迟	高达 30 秒	稳定在 5 秒内

PushGateway 缓冲机制和 remote_write 聚合策略成功解决了原本由于 scrape 节点过多、数据维度冗杂所导致的监控架构性能瓶颈。

五、经验总结

这次 Prometheus 优化让我对监控系统“自重”的影响有了更深刻理解：

• 过多 scrape + 过密时间粒度 = 自我拖垮；
• Push 模式适合短生命周期指标的缓冲卸载；
• remote_write 应搭配降采样，避免原始样本冗余占用 IO；
• 分级指标策略可让核心数据留在主 Prometheus，次级数据聚合后外发。

对于香港这样高并发、高负载的节点，我们已计划引入 Thanos 或 Cortex 构建横向扩展的存储与查询能力，进一步提升监控系统的韧性和扩展性。

这场优化虽不复杂，却是一次对监控架构稳态能力的系统性重构。对我而言，这是一次“以采控采”的深刻实践。