监控指标的 pull 和 push 模式怎么选？
更新时间：2026-09-19。短答页。这是设计监控体系时的第一个架构选择。
一句话回答
长生命周期、可被监控服务器网络直达的服务用 pull（Prometheus 主动抓 /metrics），目标集中可见、还能用 up 指标发现「目标消失」；短生命周期批任务、或处于防火墙后无法被反向访问的场景用 push（目标主动上报），可借助 Pushgateway 或 OpenTelemetry/VM agent 中转。 现代体系常两者混用。
对比
| 维度 | Pull（Prometheus 主动拉） | Push（目标主动推） |
|---|---|---|
| 发起方 | 监控服务器 | 被监控目标/agent |
| 目标发现 | 服务发现/静态配置，集中可见 | 目标自己注册上报 |
| 健康判断 | 抓不到自然产生 up==0 | 目标挂了反而「不发了」，需心跳/陈旧检测 |
| 频率控制 | 服务器统一控制 | 各目标自定义，易失控 |
| 网络要求 | Prometheus 必须能访问到目标 | 只要目标能访问到收集端（适合 NAT/防火墙后） |
| 短任务 | 不适合（可能来不及抓就退出） | 适合 |
| 典型 | Prometheus + exporter | Pushgateway、OTel Collector、StatsD、Telegraf |
Prometheus 的折中
- 常驻服务：一律 pull，配合 服务发现。
- 短生命周期 Job（CronJob、批处理，几十秒就结束）：任务结束前把结果 push 到 Pushgateway，再由 Prometheus 从 gateway 拉。注意 Pushgateway 会保留上次值，要处理陈旧指标（任务带唯一 label 或结束时清理），否则会把过期值当现状。
- 网络不可达：在目标网络内部署 agent / OTel Collector / vmagent，由它在本地 pull 再远程 push 到中心，兼顾两者优点。
选择建议
- 容器、微服务、节点 exporter：pull（统一、可审计、健康检测免费）。
- 边缘节点、客户端、NAT 后、Serverless、批处理：push 或 agent 中转。
- 日志/链路通常天然 push（事件流式产生），指标 pull 为主，这正是 OpenTelemetry Collector 统一接收再转发的价值。
坑
- 对秒级批任务直接 pull，Pod 已退出，指标漏采。
- Pushgateway 里的指标不自动过期，老任务结果被当成当前状态。
- push 模式下进程崩溃只是「不上报」，必须配心跳缺失告警，否则目标静默消失无人知。
- 让每个目标随便定推送频率，导致基数和流量失控。
采集与服务发现细节见 Prometheus exporter 与服务发现。
总结
pull 由监控端主动抓取，集中可控、天然用 up 指标发现目标宕机，适合常驻微服务和 exporter，但要求网络可达；push 由目标主动上报，适合批处理、Serverless、NAT/防火墙后等无法被反向访问的场景，但需要心跳和频率管控来发现静默故障；Prometheus 实践中常驻服务用 pull、短任务经 Pushgateway、跨网络用 OTel/VM agent 在本地拉再远程推，从而按生命周期和网络拓扑混用两种模式。