Grafana 告警体系总览

先建立一条心智链

Grafana 9 之后的告警都归属于统一告警（Unified Alerting）：不管数据来自 Prometheus、Loki 还是 SQL，规则、状态与通知都由同一套引擎管理。在动手配置之前，先把这条主线刻在脑子里：

告警规则（Rule）
   │ 按固定间隔评估查询
   ▼
告警实例（Instance）——按标签组合展开，每个实例一个状态
   │ Normal → Pending → Firing →（恢复）Normal
   ▼
内置 Alertmanager——路由树按标签匹配 → 分组 / 抑制 / 静默
   ▼
联系点（Contact point）——Slack / Email / Webhook / PagerDuty 等

整条链路只有两个「主语」：规则决定什么算异常，策略决定异常通知谁、怎么去打扰人。

规则、实例与状态机

• 告警规则（Alert rule）：一条查询语句加上一个判断条件，例如「CPU 使用率连续 5 分钟超过 80%」。规则本身不发送通知，只负责产生状态。
• 告警实例（Alert instance）：规则查询返回的每一条带标签的时间序列都是一个实例。{instance="web-01"} 和 {instance="web-02"} 各自独立地走状态机。
• 状态机：实例从 Normal 出发；条件成立后先进入 Pending，表示「已经越线，但还没熬过 for 时长」；持续越线则转为 Firing，此时才会通知；条件恢复后回到 Normal，并发送恢复通知（是否发送取决于配置）。

注意： 查询无数据或执行出错时，实例会进入 NoData 或 Error 状态。它们默认如何处理可以在规则的 Options 里改，很多「该响的告警没响」的排查都要先看这里。

评估组（Evaluation group）

规则不会被逐条独立轮询，而是归属于评估组：同组规则共用一个评估间隔（如每 1 分钟）与一个重试次数，一起被计算。评估组存放在文件夹中，因此文件夹就是告警权限的边界——能编辑文件夹的人才能改里面的规则。组内规则越多、查询越重，一轮评估耗时越长，间隔再设得过密会造成评估延迟，这是常见的容量问题。

通知链路总图

一次告警从触发到人被叫醒，依次经过这些环节：

1. 评估：评估组按间隔执行查询，更新每个实例的状态。
2. 入队：Firing 的实例被送往 Grafana 内置的 Alertmanager。
3. 路由：沿通知策略路由树按标签匹配，决定送到哪个联系点（见通知策略与路由树）。
4. 分组：同组告警合并成一条通知，受 group_by、等待与重复间隔控制。
5. 过滤：静默（silence）与静音时段（mute timing）命中则直接拦截。
6. 发送：联系点渲染通知模板，把消息投递给 Slack、邮件或你的 Webhook 服务。

与旧版告警的区别

一句话：旧版（Legacy）告警规则嵌在面板 JSON 里、只支持部分数据源、日志告警另有一套独立系统；统一告警把规则抽成独立对象，支持全部数据源类型，并共用同一条通知链路。旧版仅存量维护，新项目一律使用统一告警。

下一步

• 动手定义异常，读告警规则。
• 决定「通知去哪」，配联系点。
• 决定「谁收到、多吵」，调通知策略与路由树。
• 想看完整例子，直接跳指标与日志告警实战。