keep_firing_for 是什么
keep_firing_for 让告警在条件不再满足后继续维持触发状态一段时间，防止抖动场景下告警刚触发就恢复、值班人还没看到通知就消失了。Prometheus 2.42 起在告警规则中支持该字段。它与 for 的语义相反：for 决定告警何时开始，keep_firing_for 决定告警何时停止，两者配合能把抖动这类既不值得打扰、又需要留痕的情况处理得更稳。
基本信息
| 配置位置 | 告警规则字段 keep_firing_for |
|---|---|
| 引入版本 | Prometheus 2.42 |
| 语义 | 条件消失后继续维持触发的时长 |
| 与 for 的关系 | for 控制开始，keep_firing_for 控制结束 |
| 校验方式 | promtool check rules 与 promtool test rules |
典型使用场景
- 抖动抑制：指标在阈值附近来回跳动时，避免通知与恢复反复刷屏
- 短故障留痕：瞬时故障仍留下一条记录，便于事后统计发生频率
- 恢复延后：让恢复通知稍晚发出，避免值班人刚点开就已经恢复
- 联动稳定：上游规则状态稳定后，下游的抑制判断也更可靠
- 演练观察：模拟短故障时用它观察告警与恢复的完整时间线
使用要点
- 时长不宜过长，否则会推迟恢复通知，影响故障结束的确认节奏
- 添加字段后先用 promtool 校验版本兼容性，别让规则加载失败
- 与 for 一起设计：for 过长会漏掉短故障，keep_firing_for 过长会拖慢恢复
- 该字段只影响告警状态维持，不改变表达式本身的评估结果
- 变更后用测试用例固化预期行为，避免后续被误删
规则示例
规则示例
- alert: InstanceDown
expr: up == 0
for: 5m
keep_firing_for: 10m
labels:
severity: critical
annotations:
summary: "{{ $labels.instance }} 失联"
# 校验：promtool check rules 与 promtool test rules 都会检查该字段
# 旧版本 Prometheus 不支持该字段，本地校验通过不代表线上可用字段对照
| 字段 | 作用 | 设置过长的后果 |
|---|---|---|
| for | 条件满足多久后开始告警 | 短故障被完全忽略 |
| keep_firing_for | 条件消失后维持多久 | 恢复通知被推迟 |
| interval | 规则评估间隔 | 评估过密增加服务端负载 |
| labels | 附加标签 | 路由与抑制依赖它 |
| annotations | 通知内容模板 | 写不清楚会影响处置效率 |
旧版本 Prometheus 不支持该字段，升级前先用 promtool 校验规则文件，避免规则整组加载失败导致告警缺失。