2. Prometheus 告警体系回顾：架构、告警规则与 Alertmanager
在深入自愈 API 调用之前，必须牢固掌握 Prometheus 告警体系的完整链路。本章从架构总览、告警规则定义、Alertmanager 核心组件三个维度，为你建立告警触发自愈的底层认知。
2.1 Prometheus 告警架构总览
Prometheus 采用“拉取 + 推送”混合模型：Server 定期从 Exporter 拉取指标，由 Alerting Rule 评估是否触发告警；触发后的告警被推送到 Alertmanager，由其完成去重、分组、抑制、静默，最终路由到接收器（如自愈 API）。
2.2 告警规则：触发自愈的“触发器”
告警规则是自愈流程的起点。规则定义在 Prometheus Server 的配置文件中，通过 groups 组织，每条规则包含：告警名称、表达式、持续时间、标签和注解。
2.2.1 规则结构
groups:
- name: self_healing_alerts
rules:
- alert: HighCpuUsage
expr: (100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)) > 80
for: 2m
labels:
severity: critical
team: sre
annotations:
summary: "Instance {{ $labels.instance }} CPU usage > 80%"
description: "CPU usage at {{ $value }}% for over 2 minutes"
2.2.2 关键字段说明
| 字段 | 作用 | 自愈场景建议 |
|---|---|---|
alert |
告警名称，唯一标识 | 建议与自愈动作名称对应 |
expr |
PromQL 表达式，决定触发条件 | 表达式应精确，避免误触发 |
for |
持续时间，防止抖动 | 自愈场景建议 1-3 分钟 |
labels |
附加标签，用于路由和分组 | 必须包含 severity 和 team |
annotations |
告警描述信息，传递给接收器 | 包含实例、当前值等上下文 |
自愈关键点： 在
annotations 中携带自愈所需的参数（如实例 IP、故障类型），自愈 API 可直接解析这些字段执行恢复动作。
2.3 Alertmanager：告警的“路由中枢”
Alertmanager 是告警体系的核心枢纽，负责接收 Prometheus Server 推送的告警，经过处理后将告警发送到正确的接收器（包括自愈 API）。
2.3.1 核心处理流程
- 接收：通过 API 接收来自 Prometheus Server 的告警。
- 分组：按
group_by标签将相似告警合并，减少通知数量。 - 抑制：当高等级告警触发时，抑制相关的低等级告警。
- 静默：根据静默规则，在指定时间内不发送特定告警。
- 路由：根据
route树匹配告警标签，分发到对应接收器。
2.3.2 路由配置示例
route:
receiver: 'default-receiver'
group_wait: 30s
group_interval: 5m
repeat_interval: 4h
routes:
- match:
severity: critical
receiver: 'self-healing-api'
continue: true
- match:
severity: warning
receiver: 'email-notifier'
receivers:
- name: 'self-healing-api'
webhook_configs:
- url: 'http://self-healing-service:8080/api/v1/heal'
send_resolved: true
注意： 自愈 API 接收器必须设置
send_resolved: true，以便在告警恢复时通知自愈系统执行回滚或确认操作。
2.4 告警生命周期与状态机
理解告警的状态转换，有助于设计自愈 API 的幂等性和重试逻辑。
| 状态 | 含义 | 自愈触发时机 |
|---|---|---|
| Pending | 表达式满足，但未达到 for 持续时间 |
不触发自愈，避免抖动 |
| Firing | 表达式持续满足，告警正式触发 | 立即调用自愈 API |
| Resolved | 表达式不再满足，告警恢复 | 调用自愈 API 的恢复接口 |