Prometheus+Grafana统计告警触发次数：查询结果与Slack通知不符

核心不匹配原因 #

• ALERTS指标特性偏差：ALERTS是瞬时指标，告警持续firing时会生成连续样本，count(count_over_time(...))会把这些连续样本合并统计为1次，但Slack若配置了重复通知（如每N分钟发送一次），会产生多条通知，导致计数差异。
• 告警规则干扰：若配置了告警分组或抑制规则，Prometheus可能合并/抑制部分告警实例，但Slack可能发送分组前的通知，或ALERTS指标仍会记录被抑制的告警，两边数据错位。
• 时间窗口偏移误差：offset 1d基于Prometheus默认UTC时间计算，若你的业务用本地时区（如UTC+8），会导致统计窗口和自然日错位，出现统计结果与通知时间不对应。
• 通知渠道重试：Slack因网络问题重试发送通知，会产生多条记录，但Prometheus的告警触发次数实际仅为1次。

修正后的查询语句 #

统计真实告警触发次数（状态从非firing转为firing的次数） #

改用changes()函数检测告警状态切换，或基于ALERTS_FOR_STATE指标（仅在状态切换时生成样本）：

1. 过去24小时触发次数

sum(changes(ALERTS{alertstate="firing"}[1d])) by (alertname)

2. 昨天触发次数
   若需匹配自然日，建议结合时区调整时间范围，或用偏移量：

sum(changes(ALERTS{alertstate="firing"}[1d] offset 1d)) by (alertname)

Grafana中可借助变量实现精准自然日统计：

sum(changes(ALERTS{alertstate="firing"}[$__range] @ start_of_day(now()-1d))) by (alertname)

3. 两天前/一周前触发次数
   修改偏移量即可：

sum(changes(ALERTS{alertstate="firing"}[1d] offset 2d)) by (alertname)
sum(changes(ALERTS{alertstate="firing"}[1d] offset 7d)) by (alertname)

额外排查动作 #

• 检查告警规则的for子句：确认pending转firing的逻辑是否符合预期，避免漏统计触发点。
• 核对Slack通知配置：查看是否开启repeat_interval，区分“告警触发次数”和“重复通知次数”。
• 验证时间范围：在Grafana中直接设置目标日期的时间窗口，运行查询后对比Slack通知的时间戳。
• 核对Alertmanager日志：确认告警是否被抑制/分组，匹配ALERTS指标的记录情况。

内容的提问来源于stack exchange，提问作者oaaya