pushgateway 不支持真正集群，因其设计为单点临时指标收件箱，无状态同步、数据分片或节点发现机制；生产中需通过多实例+客户端容错、反向代理轮询拉取、业务逻辑分片等方式实现高可用与负载分散。
Pushgateway 本身不支持集群模式，官方明确设计为单点服务——它没有内置的节点发现、数据分片或状态同步机制。所谓“Pushgateway 集群”，实际是通过架构层面的冗余与分流来规避单点风险，而非真正意义上的分布式集群。
为什么不能直接部署 Pushgateway 集群？
Pushgateway 的核心定位是“临时指标收件箱”，不是时序数据库或高可用中间件。它的关键限制包括：
- 所有推送数据默认只存在内存中（除非启用持久化），重启即丢失；
- 无跨节点指标合并能力，不同实例间数据完全隔离；
- 不提供一致性哈希、负载均衡或 failover 协议；
- Prometheus 抓取目标只能配置一个 URL，无法自动轮询多个 Pushgateway 实例。
替代方案：用多实例 + 前置组件实现类集群效果
生产环境中要保障离线任务监控的可靠性，推荐采用以下组合方式：
-
部署多个独立 Pushgateway 实例（例如：pushgw-a、pushgw-b），分别监听不同端口或 IP，各自配置持久化路径（
--persistence.file）； -
在客户端脚本中实现推送容错：先尝试推送到主实例，失败后自动 fallback 到备用实例。示例 Shell 片段：
curl -f -s --data-binary @- http://pushgw-a:9091/metrics/job/backup || \ curl -f -s --data-binary @- http://pushgw-b:9091/metrics/job/backup - 用反向代理做简易负载分发（仅限读请求）：Nginx 或 HAProxy 可将 Prometheus 的拉取请求轮询转发到多个 Pushgateway，但不适用于推送场景（推送必须指定具体实例）；
- 按业务维度做逻辑分片：比如备份任务推送到 pushgw-a，CI 测试任务推送到 pushgw-b，避免单点压力过大，也便于故障隔离。
Prometheus 配置要点
每个 Pushgateway 实例需单独配置为一个 job，不可共用同一 target：
scrape_configs: - job_name: 'pushgateway-backup' static_configs: - targets: ['pushgw-a:9091'] - job_name: 'pushgateway-ci' static_configs: - targets: ['pushgw-b:9091']
这样既能区分来源，又可单独设置抓取间隔、超时和 relabel 规则，避免指标混淆。
务必注意的数据清理问题
离线任务推送的指标不会自动过期，长期累积会导致内存膨胀和查询变慢。必须主动管理：
- 为每个 job 设置唯一且有意义的
job=xxx标签，方便后续清理； - 定期调用删除接口清除过期数据，例如：
curl -X DELETE http://pushgw-a:9091/metrics/job/backup/instance/20260610 - 在脚本退出前主动清理自身上报的指标（使用
DELETE /metrics/job/.../instance/...），或借助定时任务按时间戳批量清理。
