告警生命周期是什么
Prometheus 告警有四种状态：inactive 表示条件未满足；pending 表示条件已满足但持续时间还没超过 for 设置的时长，处于观察期且不发通知；firing 表示已超过 for 并进入通知流程；resolved 表示条件消失并发出恢复通知。pending 的停留时长分布是阈值与 for 调参的重要输入——长期停在 pending 说明阈值贴边或数据抖动频繁。
基本信息
| 四种状态 | inactive、pending、firing、resolved |
|---|---|
| 状态流转 | 条件满足进 pending，超过 for 变 firing，条件消失变 resolved |
| 通知时机 | 只有 firing 与开启时的 resolved 会发送 |
| 观察期长度 | 由规则里的 for 控制 |
| 适用版本 | Prometheus 2.x |
典型使用场景
- 调参依据：统计 pending 停留时长，判断阈值是否贴边或抖动过多
- 告警核对：判断某条告警是刚刚触发还是已经持续很久
- 恢复确认：依赖恢复通知确认故障结束，而不是靠人工盯图
- 演练观察：模拟故障时对照状态流转验证规则是否符合预期
- 复盘取证：用状态时间线说明告警从触发到恢复的完整过程
使用要点
- pending 阶段不会通知，把它当已故障对外播报会虚报
- 关闭恢复通知后，故障结束只能靠人工确认，容易留下尾巴
- for 时长过短会把抖动直接变成通知，过长会漏掉短故障
- 状态变化本身可以采集为指标，用于长期统计告警质量
- 通知去重与分组都会影响最终收到的条数，与状态本身是两回事
时间轴示例
时间轴示例
10:00 条件满足 -> pending
10:05 超过 for -> firing，发出通知
10:20 条件消失 -> resolved，发出恢复通知
# pending 阶段不会通知，把它当成已故障容易虚报
# 关闭恢复通知后，故障结束只能靠人工盯图确认状态说明
| 状态 | 含义 | 是否通知 | 备注 |
|---|---|---|---|
| inactive | 条件未满足 | 否 | 无记录或已清空 |
| pending | 已满足但未过 for | 否 | 观察期，用于防抖 |
| firing | 超过 for 持续满足 | 是 | 按路由发送通知 |
| resolved | 条件已消失 | 视配置 | 取决于是否发送恢复通知 |
| 状态变化 | 可采集为指标 | 无 | 用于长期评估告警质量 |
pending 占比偏高说明阈值贴边或抖动频繁，用触发时长分布来校准 for 与评估窗口，比凭感觉调参更有效。