为何Prometheus会自动将未实际恢复的Job失败告警标记为已解决

核心根因：告警规则表达式的滑动窗口逻辑设计问题 #

你当前使用的告警规则是increase(kube_job_status_failed[30m]) > 0，该表达式的含义是统计过去30分钟内Job失败指标的增量，只要30分钟内没有新的失败事件产生，当最初触发告警的那个失败事件时间点滑出30分钟窗口后，increase()的计算结果就会变为0，告警判定条件不再满足，自然就会触发恢复通知。
你遇到的2小时后才发恢复通知的情况，属于该问题的衍生场景：如果该Job的失败事件产生后，后续没有新的失败事件，滑动窗口逐秒后移，最终失败事件完全离开30分钟窗口后，Prometheus评估告警不触发，会向Alertmanager发送恢复信号，加上Alertmanager的告警分组、静默规则、resolve_timeout配置的延迟，刚好在2小时后推送恢复通知。

其他可能触发该问题的原因 #

• 指标被停止暴露：Kubernetes Job属于一次性运行资源，当Job运行结束后，kube-state-metrics默认不会永久保留已完成Job的指标，避免指标数量无限膨胀；如果集群配置了TTLAfterFinished自动清理已完成Job，Job资源被删除后对应指标会直接消失，Prometheus采集不到指标就会判定告警条件不成立。
• 指标数据断层：如果Prometheus对kube-state-metrics的采集任务出现异常，导致kube_job_status_failed指标连续多次采集不到，Prometheus会将该时间序列标记为过期，也会误判告警恢复。

• 如果需要监控所有未处理的失败Job，直接将规则改为kube_job_status_failed > 0，只要Job的累计失败次数大于0、指标未被删除就会持续触发告警。
• 如果需要保留滑动窗口逻辑避免历史已处理的失败Job一直告警，可以调大时间窗口范围，比如改为increase(kube_job_status_failed[24h]) > 0，延长告警的有效触发时间。
• 如果期望失败Job即使被集群清理也能保留告警，需要将Prometheus告警同步到独立的工单/事件管理系统，由人工标记故障处理状态，不要完全依赖Prometheus的自动恢复逻辑。

内容的提问来源于stack exchange，提问作者cosmos-1905-14