Grafana Alerting 进阶：统一告警架构、通知策略树与告警降噪实战

Alert Rule（规则）
   │  基于数据源查询，评估是否触发
   ▼
Rule Evaluator（评估器）
   │  周期性执行（默认 1m），产生 Alert
   ▼
Notification Policy Tree（通知策略树）
   │  分组、路由、抑制、静默
   ▼
Contact Point（联系点）
   │  邮件/Slack/钉钉/Webhook/PagerDuty...
   ▼
通知送达

旧架构（≤7.x）：
  · 每数据源独立告警（Prometheus 自带 Alertmanager、Loki 无）
  · 无统一模板，配置分散在数据源里

新架构（8.x+，Grafana Alerting）：
  · 所有数据源统一用 Grafana 评估（数据源无关）
  · 内置 Alertmanager（可选外接 Prometheus AM）
  · 模板化通知（Go template）统一邮件/IM 格式
  · 通知策略树支持复杂路由与抑制

# 规则：服务 5xx 比例超过 1% 且持续 5m
groups:
  - name: availability.rules
    rules:
      - alert: HighErrorRate
        expr: |
          sum(rate(http_requests_total{code=~"5.."}[5m])) by (service)
          / sum(rate(http_requests_total[5m])) by (service) > 0.01
        for: 5m
        labels:
          severity: critical
          team: backend
        annotations:
          summary: "服务 {{ $labels.service }} 错误率超阈值"
          runbook_url: "https://wiki.example.com/runbooks/high-error-rate"

# 日志告警：5 分钟内 ERROR 日志超 50 条
groups:
  - name: log.rules
    rules:
      - alert: LogErrorSurge
        expr: |
          sum(count_over_time(
            {job="payment-service"} |= "ERROR"
            [5m]
          ))
        for: 3m
        labels:
          severity: warning
        annotations:
          summary: "日志错误数量突增"

Grafana 原生规则支持：
  · 阈值类（count / min / max / avg / sum）
  · 数学表达式（A-B / A*100）
  · 多查询组合（分阶段）
  · 时间范围类（reduce + threshold）
  · 数据源：Prometheus、Loki、Elasticsearch、CloudWatch、Graphite...

适合：跨数据源聚合、非 Prometheus 场景

根策略（默认）
 ├── 按 team 路由
 │   ├── team: backend   → Slack #backend-alerts（分组按 severity）
 │   └── team: frontend  → 邮件 frontend@
 ├── 按 severity 路由
 │   ├── severity: critical → PagerDuty + 升级
 │   └── severity: warning  → Slack #ops（合并成一条）
 └── 默认策略 → 邮件 ops@

# 根策略
routes:
  - matchers: []                  # 根，匹配所有
    receiver: default-email
    group_by: ['grafana_folder']  # 按文件夹分组
    group_wait: 30s
    group_interval: 5m
    repeat_interval: 4h           # 相同告警 4h 重发一次
    routes:
      # 子路由 1：critical 走 PagerDuty
      - matchers:
          - severity="critical"
        receiver: pagerduty
        continue: false            # 命中后不继续下钻
        routes:
          - matchers:
              - team="oncall"      # 特定团队再升级
            receiver: pagerduty-high-priority
      # 子路由 2：warning 走 Slack
      - matchers:
          - severity="warning"
        receiver: slack-ops
        group_by: ['service']

关键参数：
  group_wait      分组首条告警等待时长（合并风暴）
  group_interval  同一组两次通知最小间隔
  repeat_interval 同一告警重复通知间隔（防刷屏但要避免漏报）

最佳实践：
  · 风暴场景：group_wait 30-60s，把同一服务的并发告警合并成一条
  · 按 severity 分组：critical 独立、warning 合并
  · repeat_interval 设 4-8h，避免深夜刷屏

# 静默：变更窗口 / 已知问题 / 维护期
# 匹配条件（matcher）：
matchers:
  - severity="warning"
  - service="payment"

# 时间范围：开始/结束（最长可预设计划）
# 状态：Active / Expired / Pending

抑制规则：A 告警抑制 B 告警
  例：节点宕机(node_down) 抑制该节点上所有服务告警
   · 避免"节点挂了 + 上面 20 个服务全报错"的二次轰炸
   · Grafana 内置 Alertmanager 支持抑制配置

# 创建静默（API）
curl -X POST http://grafana:9093/api/v2/silences \
  -H "Content-Type: application/json" \
  -d '{
    "matchers": [{"name": "service", "value": "payment", "isRegex": false}],
    "startsAt": "2026-09-26T00:00:00+08:00",
    "endsAt": "2026-09-27T00:00:00+08:00",
    "comment": "支付服务计划变更窗口"
  }'

# 查询活跃静默
curl -s http://grafana:9093/api/v2/silences?state=active | jq .

Grafana Alerting 高可用：
  · 多 Grafana 实例共用同一数据源（配置同步）
  · Alertmanager 持久化状态（状态文件挂盘）
  · 通知重复：内置 dedupe（同一告警多实例只发一次）
  · 推荐：单集群 2-3 个 Grafana 实例 + 共享 SQLite/Postgres

场景：已有 Prometheus Alertmanager 体系
  · Grafana 规则评估后可转给外接 AM（Firing 状态转发）
  · 保留 Prometheus 原告警 + Grafana 新增告警的统一出口
  · 配置：Grafana Alerting → 外接 Alertmanager 地址

评估器故障 / 数据源不可达：
  · 规则评估失败 → 保留上次状态（默认不误报）
  · 可配 onError 策略：Error 也发通知（适合高风险）
  · 数据源查询超时 → 该轮不更新，等恢复

1. 综合（Reduction）：同一原因合并成一条
   · group_by 按 service/severity 分组
   · 风暴时"1 条代表 + N 条细节"

2. 分层（Tiering）：
   · P1 critical  → 立即 PagerDuty + 升级
   · P2 warning   → Slack，合并发送
   · P3 info      → 面板上红点，不打扰

3. 期限（for）：持续 N 分钟才报警
   · for: 5m 过滤瞬时抖动，避免"闪报"

每个服务应有的基础告警：
  · 错误率（5xx/error ratio）> 阈值
  · 延迟（p95/p99）突破 SLO
  · 资源饱和（CPU/内存/磁盘/连接数）
  · 可用性（探活失败 / 副本数不足）
  · 队列积压 / 消费停滞
  · 安全（登录失败突增、异常流量）

反模式：
  · 只报"值超阈值"不给上下文（无 service 标签）
  · 一报警就来 N 条重复（没分组/没 repeat 控制）
  · 告警没有处理人（无 team 标签）

告警应携带的元数据：
  · severity（P1-P3）— 决定路由与升级
  · team（owner）— 决定通知对象
  · runbook_url — 处理人点开就有文档
  · summary — 一句话说清"什么坏了"
  · dashboard 链接 — 一键跳转排查面板

Grafana OnCall 提供：
  · 值班排班（日历、轮换规则）
  · 升级链（一级没人接 → 二级/经理）
  · 确认/解决动作
  · 与 Grafana Alerting 深度集成

通知链示例：
  Slack 提醒 → 5 分钟未确认 → 电话/PagerDuty → 经理升级

# 告警规则 annotation 配置升级链
annotations:
  # 一级值班（OnCall 当前 oncall 用户）
  oncall_waiting_interval: 5m
  oncall_escalation_chain: "default-chain"

场景：支付服务 p99 延迟超 SLO
流程：
  1. PromQL 规则命中（p99 > 500ms，持续 5m）
  2. 规则评估 → 触发 Alert
  3. 通知策略树路由：
     severity=critical + team=backend → PagerDuty 高优
  4. 模板渲染通知：
     "支付服务 p99 延迟 812ms，已超 500ms SLO"
     + runbook 链接 + dashboard 链接
  5. OnCall 接收 → 确认 → 处理 → 解决
  6. 恢复后 Grafana 自动发 [RESOLVED]

groups:
  - name: latency-slo.rules
    rules:
      - alert: ServiceLatencySLO
        expr: |
          histogram_quantile(0.99,
            sum by (le, service) (rate(http_request_duration_seconds_bucket[5m]))
          ) by (service) > 0.5
        for: 5m
        labels:
          severity: critical
          team: backend
          slo: latency-p99
        annotations:
          summary: "{{ $labels.service }} p99 延迟 {{ $value | humanize }}s 超 SLO 0.5s"
          runbook_url: "https://runbooks.example.com/latency-slo"
          dashboard_url: "http://grafana/d/payment-latency"

告警系统本身要可观测：
  · 规则评估状态（firing/error 计数）
  · 通知发送成功率（Alertmanager 指标）
  · 静默/抑制数量
  · 关键规则从未触发 = 可能配置错了（配"心跳"告警验证链路）

心跳告警：
  · 每条规则打上 version 标签
  · 定期验证 Webhook 回环（ping 自己）