Pushgateway

短生命周期任务可能在 Prometheus 下一次抓取之前就结束。Pushgateway 提供中间层，保留任务推送的指标以供后续抓取，但它不是每个短进程的默认方案。Prometheus 主要建议把它用于适当的服务级批任务结果。保留数据的生命周期与任务自身独立，因此抓取成功不能证明任务最近运行过，也不能证明业务工作已经成功完成。 为稳定的批任务结果建立身份 夜间对账这样的服务级任务，可以把最近结果发布到稳定分组键下。如果把新的运行编号、时间戳或机器身份放进键中，每次运行都可能创建额外分组，而不是更新同一份结果。Pushgateway 没有自动清理旧分组的过期时间机制，负责人需要明确替换或删除相关数据，不能假定退出任务后数据也会跟着消失。 与具体机器相关的批任务，往往可以使用节点导出器的文本文件采集器。共享网关本身也增加了可用性依赖。它的 up 表示 Prometheus 能否抓取网关，不表示每个原始推送任务都健康。应根据观测事件与清理责任选择采集方式，而不是把推送当成绕过服务发现或网络策略的通用办法。任务语义没有确定时，先增加网关并不会自动解决监控定义。 替换范围由 HTTP 方法决定 URL 路径定义分组键，包括任务名称与其他标签对。HTTP PUT 替换这个精确分组中的指标；POST 则替换本次请求包含的同名指标族，同时保留组内其他指标族。POST 不表示给原值递增，也不是向持久事件日志追加一条记录。如果一次报告把数值从七写成九，结果是九，而不是自动累加成十六。 DELETE 删除 URL 标识的精确分组。仅删除任务名构成的分组键，不会删除所有同时包含该任务名和额外标签的分组。网关文档规定的方法顺序允许后续成功推送排在先前已入队的删除之后，这可以用于验证清理结果。不能只看到删除请求被接受，就认定所有名称相似的序列都已经被处理，尤其不能把分组键误当成标签子集查询。 抓取时间不等于最近成功时间 网关通过 push_time_seconds 导出某组最近成功推送的时间。读取指标端点不会推进这个值。Prometheus 为采集样本赋予抓取时间戳，所以刚刚抓到的样本仍可能描述很久以前的任务结果。如果真正关心任务何时成功完成，应把最近成功时间作为独立的仪表值导出，并按任务计划检查其新鲜度。 不要给推送的指标样本附带显式样本时间戳，Pushgateway 会拒绝这种输入。把 Unix 时间戳作为仪表指标的数值是另一回事，可以正常使用。推送成功也不能证明业务成功或已经立即持久化：任务可以成功报告自己的失败，而没有配置持久化的网关在重启后可能丢失保留数据。各项完成语义应分别核对。 坏掉的样子 任务失败或被停用之后，旧的成功指标可能一直存在。只检查序列是否存在的告警，就会漏掉没有发生的新执行。应把最近成功值与预期调度比较，并让任务移除与分组清理同步。若分组标签不断改变，新旧运行还可能永久并列显示，给面板制造重复任务或持续健康的错觉，而实际已经没有新的成功结果。 本来想发布完整快照，却使用 POST，可能保留本次任务已不再输出的指标；只准备更新一个指标，却使用 PUT，又可能删除其他面板仍需要的结果。应明确哪个组件拥有整个分组，以及它使用哪种方法。不存在能够代替这些 HTTP 语义的 --replace 选项，不能把一个未经核实的命令参数写进操作流程。 ...