2. Grafana 告警基础:告警规则、评估组、通知策略的核心概念

在深入告警聚合与质量门禁之前,必须牢固掌握 Grafana 告警引擎的三个核心抽象:告警规则(Alert Rule)、评估组(Evaluation Group)与通知策略(Notification Policy)。这三者构成了从“数据采集 → 条件判定 → 告警路由 → 用户触达”的完整链路。

2.1 告警规则:告警系统的“判定单元”

告警规则是 Grafana 告警的最小逻辑单元,它定义了一条告警“何时触发、触发后携带什么信息”。每条规则必须包含以下要素:

要素 说明 示例
数据源查询 从 Prometheus、Loki、CloudWatch 等数据源获取时序数据 avg by(service) (http_requests_total{status=~"5.."})
条件表达式 对查询结果进行阈值或同比判定,返回 true/false MAX() > 100 或 LAST() < 0.95 * MEAN()
评估频率 规则被评估的时间间隔,由所属评估组决定 每 30s 评估一次
持续时间(Pending) 条件满足后需持续多久才真正触发告警,用于防抖 持续 1 分钟
标签与注释 附加元数据,用于路由、分组和告警内容渲染 severity=critical, summary="高错误率"
最佳实践:为每条规则至少添加 severity(critical/warning/info)和 team 标签。这将在后续通知策略中实现精准路由,避免所有告警涌入同一个渠道。

2.2 评估组:规则的组织与调度容器

评估组(Evaluation Group)是 Grafana 9.x+ 引入的告警架构改进。它将多条告警规则组织在一起,共享同一个评估时间窗口和评估队列。评估组的设计解决了旧版中每条规则独立调度导致的资源碎片化问题。

评估组的关键属性:

  • 组名称:唯一标识,建议按业务域或团队命名,如 payment-critical。
  • 评估间隔:组内所有规则共享同一个评估周期(如 30s、1m、5m)。
  • 规则列表:组内可包含 1~N 条规则,规则之间相互独立,但共享调度资源。
  • 文件夹归属:评估组必须属于某个文件夹,便于权限管理和组织隔离。
性能要点:将评估间隔相近的规则放入同一评估组,可减少 Grafana 告警引擎的调度开销。例如,将所有“秒级实时告警”规则放入一个 10s 组,将所有“分钟级趋势告警”放入一个 5m 组。
告警规则与评估组关系图 评估组:payment-critical(评估间隔 30s) 规则 A 查询:5xx 错误率 条件:> 5% 标签:severity=critical 规则 B 查询:P99 延迟 条件:> 2000ms 标签:severity=warning 规则 C 查询:队列积压 条件:> 10000 标签:severity=critical 共享评估时钟:每 30s 同时评估三条规则

2.3 通知策略:告警的“路由与分发引擎”

通知策略(Notification Policy)决定了告警实例(Alert Instance)被触发后,发送给谁、通过什么渠道、以什么频率发送。Grafana 采用树形策略结构,从根策略开始逐级匹配,直到找到第一个匹配的策略为止。

通知策略的核心组成:

  • 匹配条件:基于告警标签(label)进行匹配,支持精确匹配、正则匹配和通配符。
  • 联系点(Contact Point):定义通知渠道,如邮件、Slack、PagerDuty、Webhook、钉钉等。
  • 分组配置:将相似的告警合并为一条通知,避免告警风暴。分组依据为标签组合(如 severity, service)。
  • 抑制与静默:在指定时间段内或特定条件下,阻止告警发送。
策略层级 匹配逻辑 典型用途
根策略 默认匹配所有未匹配的告警 兜底通知,发送给值班组
子策略 1 severity=critical 严重告警立即发送 PagerDuty + 短信
子策略 2 team=platform 平台团队告警发送到 Slack 频道
子策略 3 severity=warning + env=prod 生产环境警告发送邮件,非工作时间静默
常见陷阱:通知策略的匹配顺序是从上到下、先父后子。如果根策略设置了“匹配所有”,且没有子策略,则所有告警都会走根策略。务必在根策略下创建子策略来分流不同严重级别的告警。
通知策略树形匹配流程 根策略(默认匹配) 联系点:值班组邮件 子策略 1 匹配:severity=critical 联系点:PagerDuty + 短信 分组:按 service 分组,5 分钟窗口 子策略 2 匹配:team=platform 联系点:Slack #platform-alerts 分组:按 severity 分组,10 分钟窗口 告警实例进入策略树

2.4 三者的协作流程

从数据源到最终通知,告警规则、评估组、通知策略按以下顺序协作:

  1. 数据查询:告警规则按评估组设定的频率,从数据源拉取最新数据。
  2. 条件判定:规则引擎执行条件表达式,若满足则进入 Pending 状态。
  3. 持续时间检查:若条件持续满足超过设定的“持续时间”,则触发为 Firing 状态,生成告警实例。
  4. 标签注入:告警实例携带规则中定义的标签和注释。
  5. 策略匹配:告警实例进入通知策略树,从根策略开始逐级匹配。
  6. 分组与发送:匹配到的策略按分组配置合并告警,通过联系点发送通知。
质量门禁视角:在告警规则中设置合理的持续时间(Pending),可以过滤掉毛刺和瞬态抖动,避免“告警风暴”。例如,对于 CPU 使用率告警,设置持续 2 分钟再触发,能大幅减少误报。

2.5 关键概念对比总结

概念 职责 配置位置 典型粒度
告警规则 定义“什么条件下触发告警” Grafana Alerting → Alert Rules 单条指标或日志查询
评估组 组织规则并控制评估频率 Grafana Alerting → Alert Rules → Group 一组相关规则(如支付域)
通知策略 定义“告警发给谁、怎么发” Grafana Alerting → Notification Policies 按标签匹配的树形策略
联系点 定义通知渠道的具体配置 Grafana Alerting → Contact Points 单个渠道实例(如 Slack Webhook)