2. Grafana 告警基础：告警规则核心概念与状态机详解
在构建自动化 Runbook 映射之前，必须深入理解 Grafana 告警引擎的核心抽象。本章将拆解 Alert Rule、Evaluation Group、Pending / Firing 三个基础概念，并完整解析告警状态机的转换逻辑。这些概念是后续参数提取与 Runbook 绑定的数据基础。
2.1 告警规则（Alert Rule）
Alert Rule 是告警系统的“配置单元”，它定义了：在什么数据条件下，触发什么级别的告警。每条规则包含以下关键字段：
| 字段 | 说明 | 示例值 |
|---|---|---|
| Name | 规则名称，用于标识和搜索 | CPU 使用率 > 90% |
| Data Source | 查询的数据源类型（Prometheus、Loki、Graphite 等） | Prometheus |
| Query / Expression | PromQL 或其它查询表达式，定义告警条件 | avg by(instance) (cpu_usage) > 0.9 |
| Condition | 表达式计算结果与阈值的比较逻辑 | IS ABOVE 90 |
| Evaluation Group | 所属的评估组，决定评估频率 | 5m 间隔组 |
| For | 持续时间要求，防止瞬时抖动触发告警 | 5m |
| Labels | 附加标签，用于告警路由、分组和 Runbook 参数传递 | severity=critical, team=platform |
| Annotations | 描述信息，通常包含 Runbook URL、摘要、详细说明 | runbook_url=https://.../cpu-spike.md |
Runbook 映射关键点： Labels 和 Annotations 是告警到 Runbook 参数传递的“桥梁”。在后续章节中，我们将通过
alert.labels 和 alert.annotations 提取动态参数，注入自动化执行流程。
2.2 评估组（Evaluation Group）
Evaluation Group 是告警规则的调度容器。同一组内的规则共享相同的评估间隔（例如每 30 秒、每 1 分钟、每 5 分钟）。Grafana 会为每个组启动一个独立的评估协程，按固定周期执行组内所有规则的查询与条件判断。
- 组名：用户自定义，如
high-frequency-group、low-priority-group。 - 评估间隔：
10s、30s、1m、5m等。 - 并发控制：同一组内的规则按顺序评估，不同组之间并行执行。
- 最佳实践：将延迟敏感的关键规则放入短间隔组（如 10s），将趋势类规则放入长间隔组（如 5m）。
注意： 评估间隔过短可能导致数据源查询压力过大；间隔过长则可能错过快速恶化的指标。建议根据指标采集频率和业务容忍度合理设置。
2.3 告警状态机详解
Grafana 告警引擎使用三态状态机管理每条告警实例的生命周期：Pending → Firing → Resolved。理解状态转换是编写可靠 Runbook 触发条件的前提。
2.4 状态转换详细说明
| 当前状态 | 评估结果 | 下一状态 | 触发动作 |
|---|---|---|---|
| Normal | 条件不满足 | Normal（保持） | 无 |
| Normal | 条件满足 | Pending | 启动 For 计时器 |
| Pending | 条件持续满足 & 计时器未到期 | Pending（保持） | 继续计时 |
| Pending | 条件持续满足 & 计时器到期 | Firing | 发送告警通知、触发 Runbook |
| Pending | 条件恢复（不再满足） | Normal | 重置计时器，不触发告警 |
| Firing | 条件持续满足 | Firing（保持） | 可配置重复通知 |
| Firing | 条件恢复 | Resolved | 发送恢复通知，触发恢复 Runbook |
| Resolved | — | Normal（自动转换） | 清理告警实例 |
For 参数的实际意义： 设置
For: 5m 意味着指标必须连续 5 分钟超过阈值才会进入 Firing 状态。这能有效过滤毛刺（spike）和瞬时波动，避免 Runbook 被频繁误触发。在 Runbook 参数映射中，alert.for 可作为“问题持续时长”参数传递给自动化流程。
2.5 告警实例生命周期与 Runbook 触发点
每个告警规则可以产生多个告警实例（Alert Instance），实例由规则标签组合唯一标识。例如，规则 CPU > 90% 可能为每台主机生成一个实例。实例的生命周期与状态机紧密绑定，Runbook 的触发时机通常选择在 Firing 和 Resolved 两个状态点：
- Firing 触发：执行故障恢复 Runbook（如重启服务、扩容、切换流量）。
- Resolved 触发：执行清理 Runbook（如恢复配置、发送总结报告、关闭工单）。
- Pending 阶段：通常不触发 Runbook，但可用于记录“潜在风险”日志。
2.6 关键参数与 Runbook 映射预览
在后续章节中，我们将从告警实例中提取以下参数，动态填充 Runbook 模板：
| 告警上下文 | 参数来源 | Runbook 变量示例 |
|---|---|---|
| 规则名称 | alert.name |
{{ .alert_name }} |
| 严重级别 | alert.labels.severity |
{{ .severity }} |
| 触发主机 | alert.labels.instance |
{{ .instance }} |
| 当前值 | alert.values |
{{ .current_value }} |
| 持续时长 | alert.for |
{{ .duration }} |
| Runbook URL | alert.annotations.runbook_url |
{{ .runbook_url }} |
本章小结： 掌握 Alert Rule、Evaluation Group、Pending/Firing 三态转换是理解 Grafana 告警引擎的基础。告警状态机决定了 Runbook 的触发时机（Firing / Resolved），而 Labels 和 Annotations 是参数映射的数据通道。下一章将深入告警规则配置的实战细节。