pushgateway是解决定时任务监控失效的关键组件，因其允许短期任务主动推送指标至中转站，再由prometheus定期拉取，避免pull模式因任务生命周期短于采集间隔而导致的指标丢失。
定时任务本身不“说话”，监控系统也抓不到它——这是联动失败最常见的原因。关键不是把Prometheus配得有多复杂，而是让任务在结束那一刻，把状态、耗时、结果这些信息主动“喊出来”，送到Pushgateway这个中转站。
为什么Pull模式对定时任务失效
Prometheus默认每15秒或30秒拉一次指标，但一个Cronjob可能只运行20秒就退出。等Prometheus来“敲门”时，进程早已消失，HTTP端点根本不存在。这不是采集频率调快就能解决的问题，而是模型错配。
Pushgateway的作用，就是给这类“说完就走”的任务一个临时发言台——任务自己推，Prometheus定期来抄笔记。
指标推送必须包含的三个要素
-
唯一且一致的标签组合：比如
job="backup"和instance="db01"必须全程统一。同一任务不同执行不能用不同标签，否则Prometheus会当成多个独立时间序列，告警和图表全乱。 -
基础状态指标：至少两个——
script_execution_status{job="xxx"} 0或1（0成功，1失败），以及script_execution_duration_seconds{job="xxx"} X.XX（秒级精度）。 -
推送时机必须在脚本末尾：放在
your_command之后、exit $?之前。失败也要推，否则你永远不知道它卡在哪一步。
告警规则要盯住“没来”和“来了但不对”
光有推送还不够。Pushgateway里的数据不会自动过期，得靠规则兜底：
- 查“缺失”：用
absent(script_execution_status{job="backup"}) == 1触发告警——说明最近一次该推的指标根本没来，可能是脚本没跑、网络不通或推送命令写错了。 - 查“异常”：
script_execution_status{job="backup"} != 0表示失败；script_execution_duration_seconds{job="backup"} > 600表示超时（按实际SLA调整）。 - 避免误报：加
unless on(job) script_execution_status{job="backup"} offset 1h == 0，确认上次确实成功过，再报本次失败才可信。
运维上容易忽略的细节
Pushgateway不是“一推了之”的黑盒：
- 默认内存存储，重启即丢数据——生产环境务必启用
--persistence.file并挂载持久卷。 - 指标不自动清理，长期堆积会导致查询变慢甚至OOM。建议配合定时任务清空旧数据：
curl -X DELETE http://pushgateway:9091/metrics/job/backup（在下次任务开始前执行）。 - 不要给每个Cronjob单独起一个Pushgateway实例——一个网关服务，承载所有脚本推送即可，靠
job和instance标签区分。
