4. 告警体系搭建：告警分级、源接入、路由与去重

告警体系是自愈剧本的“神经末梢”。如果告警不准、延迟高、重复轰炸，后续的降级、熔断、自愈动作都会失去依据。本章聚焦四个核心环节：告警分级（P0/P1/P2）、告警源接入（Prometheus / Grafana）、告警路由与去重降噪，目标是让每一条告警在正确的时间到达正确的人，且只到达一次。

4.1 告警分级：P0 / P1 / P2 定义与响应目标

告警分级不是简单的“严重/警告/信息”，而是与业务影响面和响应 SLA 强绑定的等级制度。下表给出生产环境通用的分级标准：

4.2 告警源接入：Prometheus + Grafana 双通道

现代可观测性栈中，Prometheus 负责指标采集与告警规则评估，Grafana 负责可视化与告警事件转发。两者可以独立作为告警源，也可以串联使用。

4.2.1 Prometheus Alertmanager 原生接入

Prometheus 通过 alerting_rules.yml 定义告警规则，由 Alertmanager 统一处理路由、分组、抑制和发送。以下是一个典型的 P0 告警规则片段：

groups:
  - name: p0_critical
    rules:
      - alert: Payment5xxRateHigh
        expr: |
          sum(rate(http_requests_total{status=~"5..", endpoint="payment"}[1m]))
          / sum(rate(http_requests_total{endpoint="payment"}[1m]))
          > 0.5
        for: 2m
        labels:
          severity: p0
          team: payment
        annotations:
          summary: "支付接口 5xx 率超过 50%"
          description: "当前 5xx 率 {{ $value | humanizePercentage }}，持续 2 分钟以上"

4.2.2 Grafana 告警引擎接入

Grafana 8.0+ 内置统一告警引擎，支持从 Prometheus、Loki、Tempo 等多数据源直接生成告警。Grafana 告警的优势在于：

• 可视化规则管理：直接在 Dashboard 面板上创建告警，所见即所得。
• 多维度标签：自动继承查询中的 label，减少手动维护。
• 静默与抑制：支持基于时间窗口的静默规则。

4.3 告警路由：基于标签的智能分发

告警路由的核心是标签匹配。Alertmanager 的 route 配置块支持树形路由结构，根据 severity、team、region 等标签将告警分发到不同的接收器（Receiver）。

route:
  receiver: 'default'
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  routes:
    - match:
        severity: p0
      receiver: 'p0-oncall'
      repeat_interval: 5m
    - match:
        severity: p1
      receiver: 'p1-im'
      repeat_interval: 30m
    - match:
        severity: p2
      receiver: 'p2-slack'
      group_wait: 2m
      group_interval: 15m

路由决策树如下图所示：

4.4 告警去重：从源头到聚合的降噪策略

重复告警是值班人员的头号痛点。去重需要从三个层面协同：

1. 规则层去重：避免多条规则覆盖同一指标。例如，不要同时配置“CPU > 90%”和“CPU > 95%”两条独立告警，应使用单一规则配合不同 severity。
2. Alertmanager 分组去重：通过 group_by 将相同标签的告警合并为一条通知。例如，所有 severity=p2, team=infra 的告警每 15 分钟聚合一次。
3. 接收端去重：在即时消息机器人（如 PagerDuty、Opsgenie）侧启用外部去重，防止网络抖动导致重复投递。

4.5 告警去重与聚合流程

下图展示了一条告警从产生到最终通知的完整去重与聚合链路：

4.6 实战检查清单

• 分级是否覆盖所有业务？ 每个核心服务至少有一条 P0 规则，每条规则必须有明确的 severity 标签。
• 路由是否闭环？ 所有告警必须匹配到至少一个 receiver，避免落入默认接收器导致无人响应。
• 去重是否生效？ 在故障演练中故意触发多条同类告警，验证最终通知数量是否被压缩到 1 条。
• 静默是否可管理？ 维护窗口期间应通过 Alertmanager 的 silence API 或 Grafana 静默规则提前抑制，避免误报。