拉取与推送是什么
监控采集有两种模型：拉取（pull）由监控服务端周期请求目标的 /metrics 端点，Prometheus 默认采用这种方式；推送（push）由被监控程序或代理主动上报，适合批处理任务或需要穿透网络限制的场景，通常经 Pushgateway 中转。两者不是优劣之争，而是适用边界不同。
基本信息
| Pull 发起方 | 监控服务端（Prometheus） |
|---|---|
| Push 发起方 | 被监控程序或代理 |
| Push 中转件 | Pushgateway（常见） |
| Pull 失联语义 | 抓取失败即 up=0，可告警 |
| Push 失联语义 | 停推难以区分正常与异常 |
| 选择依据 | 生命周期、网络可达性、目标数量 |
典型使用场景
- 常驻服务、主机与中间件：用 pull 配合服务发现自动感知变化
- 批处理与定时任务：任务结束后用 push 上报结果指标
- 跨网段或单向网络：由内网侧 push 到可访问的中转点
- Serverless 与短生命周期任务：来不及被抓取，只能主动上报
- Kubernetes 工作负载：pull 配合服务发现是标准做法
- 临时脚本上报一次性业务指标，用 push 最省事
推送批处理指标到 Pushgateway
推送批处理指标到 Pushgateway
# 任务结束后推送结果
printf 'etl_last_success_timestamp_seconds 1755000000\netl_records_processed_total 182000\n' | \
curl --data-binary @- http://127.0.0.1:9091/metrics/job/nightly_etl/instance/db-01
# 任务下线时删除对应分组，避免陈旧数据反复上报
curl -X DELETE http://127.0.0.1:9091/metrics/job/nightly_etl/instance/db-01模型对比
| 维度 | Pull 拉取 | Push 推送 |
|---|---|---|
| 发起方 | 监控服务端 | 被监控程序或代理 |
| 目标管理 | 服务发现自动感知变化 | 发送方自行维护地址 |
| 失联语义 | 抓取失败即 up=0 | 停推难以区分正常与异常 |
| 典型场景 | 常驻服务、主机、中间件 | 批处理、定时任务、跨网段上报 |
Pushgateway 上的序列不会自动过期：任务下线后要删除对应分组，否则陈旧数据会持续被上报，形成长期虚假指标。
Pushgateway 默认没有访问控制，不要暴露到公网；清理用 DELETE /metrics/job/<job>。
给常驻服务用推送会把服务发现与失联检测的职责推给应用，部署变更时容易漏改地址，是常见的架构性踩坑。
推送的 job 与 instance 标签由 URL 决定：分组设计要预留区分维度，否则多实例上报会互相覆盖。