Prometheus Pushgateway 使用指南与最佳实践（中文总结）

本文档来自 Prometheus 官方文档 - When to use the Pushgateway，核心观点是：Pushgateway 仅适用于极少数特定场景，不应作为常规指标采集手段。盲目使用会带来严重问题。

一、Pushgateway 是什么？

  • 一个中间代理服务，允许无法被 Prometheus 主动拉取（scrape）的作业主动推送（push）指标。
  • 详细机制见 Pushing metrics。

二、为什么不推荐常规使用？

1. 破坏 Prometheus 的拉取模型优势

  • ❌ 失去自动健康监控：
    Prometheus 通过 up 指标判断目标是否存活。Pushgateway 本身始终“up”，即使原始作业已崩溃。

  • ❌ 生命周期错位：

    Pushgateway 永不自动删除已推送的指标序列（time series），即使原始作业已终止或重命名。

    • 结果：陈旧指标长期存在，污染监控数据。
    • 对比：拉取模式下，实例消失 → 指标自动消失。

2. 架构风险

  • ❌ 单点故障 & 性能瓶颈：
    多个作业通过同一个 Pushgateway 上报 → 它成为关键依赖和性能瓶颈。

三、唯一推荐的使用场景

✅ 服务级批处理作业（Service-level batch job）

  • 定义：
    作业逻辑不绑定到特定机器或实例，而是代表整个服务的行为。
    示例：
    • 全局用户清理任务
    • 跨集群数据归档
    • 全站缓存预热
  • 关键要求：
    • 指标不得包含 instance、host 等标识具体机器的标签。
    • 指标生命周期与作业本身解耦，避免因实例变动产生陈旧数据。
    • 推荐指标：
      • last_success_timestamp_seconds（上次成功时间戳）
      • job_duration_seconds（作业耗时）

📌 参考：Batch Job 监控最佳实践

四、常见误用场景及替代方案

误用场景 问题 正确做法
机器相关的批处理任务 （如 cron 安全更新、配置管理） 每台机器独立运行，需保留 instance 标签 → 导致陈旧指标堆积 ✅ 使用 Node Exporter 的 textfile collector 将结果写入 /var/lib/node_exporter/textfile_collector/ 下的 .prom 文件
因防火墙/NAT 无法拉取 将 Pushgateway 当作“穿透工具” ✅ 将 Prometheus 部署到同网络内 或使用 **PushProx**（专为 NAT/防火墙设计的反向代理）
临时调试或一次性脚本 指标无明确生命周期，易成垃圾数据 ⚠️ 若必须使用，务必在脚本结束时调用 Pushgateway API 删除指标

五、如果必须使用 Pushgateway

  • 严格限制使用范围：仅用于上述“服务级批处理”。
  • 避免高基数标签：不要推送含用户 ID、会话 ID 等动态标签的指标。
  • 定期清理：通过 Pushgateway 的 /metrics/job/<job> DELETE API 手动清理陈旧作业数据。
  • 不要用于实时监控：它不是为高频、持续上报设计的。

总结：决策流程图

1
2
3
4
5
6
7
8
9
10
你的作业是否是“服务级批处理”？
  │
  ├─ 否 ──> 不要用 Pushgateway！
  │         • 机器相关批处理 → 用 Node Exporter textfile
  │         • 网络隔离 → 用 PushProx 或迁移 Prometheus
  │
  └─ 是 ──> 可以用 Pushgateway，但：
            • 指标不含 instance/host 标签
            • 仅推送关键结果（如 last_success_timestamp）
            • 避免推送高基数数据

🌟 核心原则：
能 Pull 就绝不 Push。Pushgateway 是例外，不是常规选项。