一、先想一个生活场景
你平时网购，快递员（Prometheus）每天都会到你家门口（业务进程）敲门取件（/metrics）。
但有一天，你只有 5 分钟在家，快递员还没来你就走了。怎么办？
你把包裹先放进小区门口的快递柜（Pushgateway），快递员依然按老规矩去快递柜统一取件。
Prometheus 的 Pushgateway 就是这只“快递柜”。

二、Prometheus 的默认模式——“Pull（拉）”

1. Prometheus Server 每隔固定周期（默认 15 s）主动向目标 HTTP 端口 /metrics 抓数据。
2. 要求：
   • 目标进程 7×24 在线；
   • 端口可被 Prometheus 网络直连；
   • 进程生命周期足够长。

三、现实困境——“拉”不到的三种典型场景

1. 短作业
   备份脚本、一次性数据迁移脚本，跑完即退出。
2. 网络隔离
   边缘 IoT、CI/CD 临时容器，防火墙/ NAT 导致 Prometheus 无法直连。
3. 动态端口
   批处理任务每次启动端口随机，Prometheus 无法提前配置。

四、Pushgateway 的“桥”作用——把“推”转成“拉”

1. 部署 Pushgateway
   一条命令：

   docker run -p 9091:9091 prom/pushgateway
   

   它启动后监听 http://pushgateway:9091/metrics，这就是快递柜的大门。

2. 业务端主动 “push”
   以 shell 为例：

   cat <<EOF | curl --data-binary @- http://pushgateway:9091/metrics/job/backup/instance/db01
   # TYPE backup_duration_seconds gauge
   backup_duration_seconds 137.2
   EOF
   

   含义：把指标 backup_duration_seconds 放到快递柜里，贴的标签是 job=backup, instance=db01。

3. Prometheus 继续 “pull”
   在 prometheus.yml 里加一段最普通的 scrape 配置：

   scrape_configs:
     - job_name: pushgateway
       static_configs:
         - targets: ['pushgateway:9091']
   

   Prometheus 仍然按老习惯去快递柜取件，对 Server 而言毫无差异。

五、Pushgateway 不是万能钥匙——使用边界

注意点：
• Pushgateway 不做数据去重，旧指标会累积，需要脚本结束后主动 DELETE /metrics/job/... 清理。
• 它不是分布式存储，重启即丢数据。
• 避免标签泛滥（如把时间戳、随机 ID 当标签），否则时间序列爆炸。

六、一句话总结
Pushgateway 让“推模式”像“拉模式”一样简单：
短作业或网络隔离的业务先把指标“寄”到 Pushgateway，Prometheus 仍按原节奏“取”即可。
只要记住：

“Pushgateway 是快递柜，不是仓库；是桥，不是目的地。”