告警体系为什么总出问题

告警过多导致值班人员麻木、关键告警被淹没、告警阈值不合理引发误报——这三个问题几乎出现在所有没有系统设计过告警规则的团队里。SRE方法论中，告警系统的核心目标是”在用户感知到故障之前发现问题”，而非”把所有异常都报出来”。一套经过设计的Prometheus告警体系，需要从指标选择、规则编写、分级策略、路由分发到抑制静默全链路考虑。本文给出从零搭建可运维告警体系的完整路径。

指标分类与告警规则设计原则

不是所有指标都适合告警。把指标分为四类：

• 黄金指标（Golden Signals）：延迟、流量、错误率、饱和度——这四个是必须告警的核心
• 业务指标：订单量、支付成功率等——需要根据业务SLI设定阈值
• 资源指标：CPU、内存、磁盘——设高水位告警即可
• 运维指标：进程存活、配置变更——简单阈值判断

告警规则设计的三条原则：

1. 每条告警必须对应一个明确的处理动作，无法指导行动的告警不该存在
2. 优先使用速率类指标而非绝对值，减少短时波动误报
3. 设置合理的for持续时间，避免瞬时抖动触发告警

黄金指标告警规则编写

以下是一组经过生产验证的核心告警规则：

# prometheus_rules/golden_signals.yml
groups:
  - name: golden_signals
    interval: 30s
    rules:
      # 错误率告警 - 5分钟内5xx比例超过5%
      - alert: HighErrorRate
        expr: |
          (
            sum(rate(http_requests_total{status=~"5.."}[5m]))
            /
            sum(rate(http_requests_total[5m]))
          ) > 0.05
        for: 2m
        labels:
          severity: critical
          team: sre
        annotations:
          summary: "服务 {{ $labels.service }} 5xx错误率超过5%"
          description: "当前5xx比例: {{ $value | printf "%.2f" }}%，持续2分钟"

      # 延迟告警 - P99延迟超过基线3倍
      - alert: HighLatencyP99
        expr: |
          histogram_quantile(0.99,
            sum(rate(http_request_duration_seconds_bucket[5m]))
            by (le, service)
          ) > 
          histogram_quantile(0.99,
            sum(rate(http_request_duration_seconds_bucket[24h]))
            by (le, service)
          ) * 3
        for: 5m
        labels:
          severity: warning
          team: sre
        annotations:
          summary: "服务 {{ $labels.service }} P99延迟异常"
          description: "当前P99: {{ $value | printf "%.3f" }}s，超过24小时基线的3倍"

      # 流量突降 - 5分钟QPS相对1小时前下降超过50%
      - alert: TrafficDrop
        expr: |
          (
            sum(rate(http_requests_total[5m]))
            /
            sum(rate(http_requests_total[1h] offset 1h))
          ) < 0.5
        for: 3m
        labels:
          severity: critical
          team: sre
        annotations:
          summary: "整体流量突降超过50%"
          description: "当前QPS相对1小时前: {{ $value | printf "%.1f" }}倍"

      # 饱和度 - 连接池使用率超过85%
      - alert: ConnectionPoolSaturation
        expr: |
          (
            db_connection_pool_active / db_connection_pool_max
          ) > 0.85
        for: 5m
        labels:
          severity: warning
          team: dba
        annotations:
          summary: "数据库连接池 {{ $labels.pool }} 使用率超过85%"
          description: "活跃连接: {{ $value | printf "%.1f" }}%"

告警分级与路由策略

告警分级决定了通知渠道和响应时效。建议分为三级：

Alertmanager路由配置示例：

# alertmanager.yml
route:
  group_by: ['alertname', 'service']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  receiver: 'default'
  routes:
    - match:
        severity: critical
      receiver: 'critical-team'
      repeat_interval: 15m
    - match:
        severity: warning
      receiver: 'warning-team'
      repeat_interval: 2h

receivers:
  - name: 'default'
    webhook_configs:
      - url: 'http://alertmanager-webhook:8080/alert'
  - name: 'critical-team'
    pagerduty_configs:
      - routing_key: 'YOUR_PAGERDUTY_KEY'
  - name: 'warning-team'
    webhook_configs:
      - url: 'https://hooks.slack.com/services/YOUR/SLACK/WEBHOOK'

告警抑制与静默机制

抑制（Inhibit）用于在高级别告警触发时自动静默低级别相关告警。经典场景：节点宕机触发NodeDown告警，同时会连带产生ServiceUnavailable、HighErrorRate等告警，只需通知NodeDown即可：

# alertmanager.yml - inhibit规则
inhibit_rules:
  - source_match:
      alertname: NodeDown
    target_match:
      alertname: HighErrorRate
    equal: ['instance']

  - source_match:
      alertname: DatabaseDown
    target_match_re:
      alertname: ConnectionPoolSaturation|SlowQuery
    equal: ['cluster']

静默（Silence）用于计划内维护窗口，避免发布、扩容期间触发大量预期中的告警：

# 通过API创建静默规则
curl -X POST http://alertmanager:9093/api/v1/silences -d '{
  "matchers": [
    {"name": "service", "value": "payment-api", "isRegex": false}
  ],
  "startsAt": "2026-07-23T10:00:00Z",
  "endsAt": "2026-07-23T12:00:00Z",
  "createdBy": "sre-team",
  "comment": "payment-api版本发布，预期告警静默"
}'

告警质量治理与持续优化

告警系统本身需要定期治理，否则会逐步退化。以下指标用于衡量告警质量：

# 告警质量指标
# 1. 告警确认率 = 已确认告警 / 总告警数（目标 > 90%）
# 2. 告警行动率 = 触发操作的告警 / 总告警数（目标 > 70%）
# 3. 告警噪音率 = 无需处理的告警 / 总告警数（目标 < 10%）
# 4. MTTA = 告警触发到首次响应的时间（P1目标 < 5分钟）

每季度做一次告警复盘：审查噪音率超过15%的规则，调整for持续时间或阈值；删除连续3个月未触发的规则；对频繁触发的P3告警考虑降级为日志输出。

告警规则测试：在CI流水线中加入promtool检查，确保规则语法正确；对关键规则使用PromQL单元测试验证边界值行为：

# promtool 单元测试
# tests.yml
rule_files:
  - golden_signals.yml
tests:
  - interval: 30s
    input_series:
      - series: http_requests_total{service="api",status="500"}
        values: "0 10 20 30 40 50 60 70 80 90 100"
      - series: http_requests_total{service="api",status="200"}
        values: "1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000"
    alert_rule_test:
      - eval_time: 5m
        alertname: HighErrorRate
        exp_alerts:
          - exp_labels:
              severity: critical
              service: api
            exp_annotations:
              summary: "服务 api 5xx错误率超过5%"

这套测试确保规则在预期数据下产生预期告警，防止修改规则后引入回归。