2. Grafana 告警体系深度解析：架构、规则、评估组、通知策略与静默机制
本章深入剖析 Grafana 告警体系的核心组件与工作流。理解告警架构、规则定义、评估组、通知策略与静默机制，是构建可靠自动化运维体系的基础。我们将从整体架构入手，逐步拆解每个环节的设计原理与最佳实践。
2.1 Grafana Alerting 整体架构
Grafana Alerting 采用模块化设计，核心组件包括数据源、告警规则、评估器、通知策略与静默管理器。下图展示了告警从数据采集到通知触发的完整链路。
架构要点：Grafana Alerting 支持多数据源混合评估，告警规则独立于仪表盘，评估组控制并发粒度，通知策略实现灵活路由，静默机制提供临时抑制能力。
2.2 告警规则 (Alert Rules)
告警规则是告警体系的核心配置，定义了“何时触发告警”的逻辑。每条规则包含以下关键属性：
| 属性 | 说明 | 示例 |
|---|---|---|
| 数据源 | 规则评估的数据来源 | Prometheus / Loki / 自定义数据源 |
| 查询表达式 | PromQL / LogQL / 其他查询语言 | avg(rate(http_requests_total[5m])) > 100 |
| 条件 | 阈值比较逻辑 | IS ABOVE / IS BELOW / IS WITHIN |
| 评估频率 | 规则评估的时间间隔 | 30s / 1m / 5m |
| 标签 | 用于路由和分组的键值对 | severity=critical, team=platform |
| 注解 | 告警触发时携带的额外信息 | summary: "高错误率" |
2.2.1 规则类型
- Grafana 管理规则：直接在 Grafana UI 中创建，支持多数据源混合查询，适合复杂聚合场景。
- 数据源管理规则：由数据源自身管理（如 Prometheus 原生规则），Grafana 仅负责同步和展示。
2.2.2 规则设计最佳实践
- 标签标准化：统一使用
severity、team、service等标签，便于通知策略路由。 - 注解丰富化：在注解中包含 Runbook 链接、当前值、历史趋势，减少排障上下文切换。
- 评估频率合理：高频规则（<30s）用于关键指标，低频规则（>5m）用于容量规划类告警。
实战案例：某电商平台为订单成功率设置告警规则：
sum(rate(order_failed_total[1m])) / sum(rate(order_total[1m])) > 0.05，评估频率 30s，标签 severity=critical, service=order，注解包含 Runbook 链接和当前失败率。
2.3 评估组 (Evaluation Group)
评估组是 Grafana 9+ 引入的告警评估并发控制机制。它将告警规则分组，每组独立评估，避免大量规则同时评估导致性能抖动。
| 概念 | 说明 | 默认值 |
|---|---|---|
| 组名 | 评估组的唯一标识 | 默认组 |
| 评估间隔 | 组内所有规则的评估频率 | 60s |
| 并发限制 | 组内同时评估的最大规则数 | 10 |
| 规则列表 | 属于该组的告警规则 | — |
2.3.1 评估组设计原则
- 按服务/团队分组：将同一微服务或团队的规则放入同一组，便于独立管理和监控。
- 评估间隔差异化：关键规则组使用短间隔（10-30s），非关键组使用长间隔（1-5m）。
- 并发控制：组内规则超过 20 条时，适当降低并发数，避免数据源压力过大。
注意：评估组配置不当可能导致告警延迟或丢失。建议生产环境至少划分 3 个评估组：关键组（10s 间隔）、普通组（1m 间隔）、容量组（5m 间隔）。
2.4 通知策略 (Notification Policies)
通知策略决定告警触发后如何路由、聚合和发送。它采用树形结构，支持多层匹配和继承。
2.4.1 通知策略核心配置
| 配置项 | 说明 | 推荐值 |
|---|---|---|
| 匹配条件 | 基于告警标签的路由规则 | severity=critical |
| 联系人点 | 通知发送的目标 | PagerDuty / Slack / 邮件 |
| 分组配置 | 相同标签的告警合并发送 | 按 alertname 分组，5m 内合并 |
| 重复发送 | 告警持续未解决时的重发间隔 | 30m / 1h / 4h |
| 模板 | 自定义通知内容格式 | 包含摘要、当前值、Runbook 链接 |
2.4.2 通知策略最佳实践
- 分层路由：根策略设置默认联系人（如值班邮箱），子策略按严重级别或团队分流。
- 分组聚合：相同告警在短时间内多次触发时合并为一条通知，避免告警风暴。
- 重复发送策略：关键告警每 30 分钟重复一次，非关键告警每 4 小时重复一次。
2.5 静默机制 (Silences)
静默机制允许在指定时间段内抑制告警通知，常用于维护窗口、已知问题或临时变更。静默可以基于标签匹配精确控制。
| 属性 | 说明 | 示例 |
|---|---|---|
| 匹配条件 | 基于告警标签的匹配规则 | severity=warning |
| 时间范围 | 静默生效的起止时间 | 2025-03-15 02:00 ~ 04:00 |
| 持续时间 | 静默生效的时长 | 2h / 4h / 永久 |
| 创建者 | 静默的创建人 | admin / 自动化脚本 |
| 注释 | 静默原因说明 | 数据库维护窗口 |
2.5.1 静默使用场景
- 计划维护：在维护窗口前创建静默，避免维护操作触发大量告警。
- 已知问题：已知 Bug 或依赖服务故障期间，静默相关告警直到修复。
- 变更窗口：发布或配置变更期间，静默非关键告警，聚焦变更影响。
自动化静默：通过 Grafana API 创建静默，与变更管理系统（如 ServiceNow、Jira）联动。变更单创建时自动生成静默，变更完成后自动解除。
2.5.2 静默与通知策略的交互
静默在告警评估后、通知发送前生效。匹配静默条件的告警不会触发通知，但告警状态仍会记录在 Grafana 中。静默优先级高于通知策略。
注意：静默不会阻止告警规则的评估，仅抑制通知。长时间静默可能导致告警被忽略，建议设置自动过期时间。
2.6 告警生命周期与状态机
理解告警状态转换是排查告警问题的关键。Grafana 告警包含以下状态：
| 状态 | 说明 | 触发条件 |
|---|---|---|
| Normal | 正常状态，未触发告警 | 条件不满足 |
| Alerting | 告警触发中 | 条件满足且持续超过 for 时长 |
| Pending | 等待确认状态 | 条件满足但未超过 for 时长 |
| Resolved | 告警已恢复 | 条件不再满足 |
| No Data | 数据源无数据 | 查询返回空结果 |
| Error | 规则评估出错 | 查询语法错误或数据源不可达 |
2.6.1 状态转换流程
- Normal → Pending：条件首次满足，进入等待期（
for参数）。 - Pending → Alerting：条件持续满足超过
for时长，触发告警。 - Alerting → Resolved：条件不再满足，告警自动恢复。
- Alerting → Normal：条件不再满足且无
for延迟，直接恢复。 - No Data / Error：数据源异常时进入，可配置是否触发告警。
关键参数：
for 参数用于防止瞬态抖动导致误告警。生产环境建议设置 for: 1m 或 for: 5m，根据指标波动特性调整。
2.7 本章小结
Grafana 告警体系通过模块化架构实现了灵活、可扩展的告警管理。告警规则定义触发逻辑，评估组控制并发粒度，通知策略实现智能路由，静默机制提供临时抑制。掌握这些核心组件，是后续实现 Runbook 联动和基础设施优化的前提。