2. Grafana 告警体系回顾：Alertmanager、告警规则、通知渠道
在深入分析告警历史与优化 SLO 自愈触发条件之前，必须对 Grafana 告警体系的三大核心组件建立清晰认知。本章从 告警规则（触发条件）、Alertmanager（路由与抑制中枢）和 通知渠道（触达终端）三个维度展开，为后续的告警历史数据建模与自愈剧本调优奠定基础。
2.1 告警规则：定义“什么值得告警”
告警规则是告警体系的起点。Grafana 支持两种规则类型：Grafana 管理的规则（直接查询数据源）和 Mimir/Loki 管理的规则（在数据源侧评估）。无论哪种类型，规则的核心结构都包含以下要素：
| 要素 | 说明 | 示例 |
|---|---|---|
| 指标查询 | 定义要监控的指标与聚合方式 | histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m])) |
| 条件表达式 | 比较阈值或异常检测结果 | B > 0.5（多维度组合） |
| 评估频率 | 每多久执行一次规则检查 | 1m、5m |
| 持续时间（Pending） | 条件满足多久后才触发告警 | 2m（避免毛刺） |
| 标签（Labels） | 附加元数据，用于路由与分组 | severity=critical, team=platform |
| 注解（Annotations） | 告警消息中的可读信息 | summary, description, runbook_url |
最佳实践： 为每条告警规则添加
team、tier、slo_name 等标签。这些标签在后续告警历史分析中将成为分组与过滤的关键维度，直接影响自愈剧本的匹配精度。
2.2 Alertmanager：告警路由与抑制中枢
Alertmanager 是告警体系中的“交通警察”。它接收来自 Grafana 或数据源的告警事件，执行分组、抑制、静默和路由，最终将告警发送到正确的通知渠道。其核心工作流如下：
2.3 通知渠道：告警触达的最后一公里
Grafana 支持多种通知渠道类型，每种渠道的配置参数与适用场景不同。在 SLO 自愈场景中，通知渠道不仅是“发消息”，更是触发自动化剧本的入口。
| 渠道类型 | 配置要点 | SLO 自愈适用性 |
|---|---|---|
| Webhook | URL、HTTP 方法、自定义 Header、消息模板 | ✅ 最推荐：直接触发自愈剧本 API |
| PagerDuty | Routing Key、Severity 映射、事件动作 | ✅ 适合：需要值班排班 + 自动升级 |
| Slack / 钉钉 / 飞书 | Webhook URL、消息模板、@指定人 | ⚠️ 仅通知：需额外中间件才能触发自愈 |
| SMTP 服务器、收件人列表、模板 | ❌ 不推荐：延迟高，无法自动化 | |
| Grafana OnCall | 集成 Grafana 原生 OnCall 流程 | ✅ 推荐：支持告警升级与自动动作 |
常见陷阱： 很多团队将 Webhook 直接指向自愈剧本的 HTTP 端点，却忽略了 告警分组 带来的影响。当 Alertmanager 将多条告警合并为一条通知时，自愈剧本可能只收到一条请求，但实际需要处理多个故障实例。在后续章节中，我们将通过告警历史分析来识别这类分组导致的触发条件偏差。
2.4 告警生命周期状态机
理解告警的状态转换是分析告警历史的前提。Grafana 告警从产生到关闭经历以下状态：
2.5 告警历史数据的关键字段
在后续章节中，我们将基于告警历史数据来优化自愈剧本的触发条件。以下是需要重点关注的字段：
- alert_name：告警规则名称，用于关联 SLO 指标。
- labels：标签集合（如
severity、team、slo_name），是分组与路由的核心。 - state：告警状态（Normal / Pending / Firing / Resolved）。
- starts_at / ends_at：告警开始与结束时间，用于计算持续时间。
- annotations：可读描述，通常包含
summary和runbook_url。 - silenced / inhibited：是否被静默或抑制，影响自愈剧本是否应执行。
课程关联： 本章回顾的 Alertmanager 路由规则与告警状态机，将直接用于第 5 章“告警历史数据建模”中的 ETL 设计。特别是
silenced 和 inhibited 字段，在判断自愈剧本是否应该跳过某些告警时至关重要。