Prometheus告警规则设计实战：构建稳定可收敛的多级监控告警体系

监控告警体系的质量决定故障被发现的速度。Prometheus是最主流的监控告警体系核心组件，但很多团队的告警规则还是凭经验拍出来的，要么大量误报被当作噪音，要么真实故障淹没在信息里。本文从规则设计原则、表达式写法、分级路由三个层面，说明如何构建一套稳定、可收敛的监控告警体系。

告警规则设计的基本原则

好的告警规则满足四条标准：可解释、可恢复、不抖动、有分级。可解释指每一条规则都要能回答”这条告警说明什么不可用”；可恢复指条件回归后系统能自动关闭告警；不抖动指对瞬时波动做缓冲；有分级指告警通知强度与影响面匹配。Prometheus规则引擎原生支持表达式与持续时长组合，这些标准都能落进规则文件：

groups:
  - name: node-basic
    rules:
      - alert: NodeCPUHigh
        expr: 100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 85
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "{{ $labels.instance }} CPU占用超过85%"
      - alert: NodeDiskWillFull
        expr: (1 - node_filesystem_avail_bytes / node_filesystem_size_bytes) * 100 > 90
        for: 10m
        labels:
          severity: critical
        annotations:
          summary: "{{ $labels.instance }} 磁盘剩余不足10%"

服务与业务层级的告警表达式

基础设施层之外，业务指标更值得纳入告警。HTTP错误率、SLO错误预算、队列积压这三类指标最常出问题。错误率指标的计算要注意时间窗口：5分钟窗口对突发流量敏感，30分钟窗口能过滤短暂抖动，具体取多少要看业务容忍度。

      - alert: APIHighErrorRate
        expr: sum(rate(http_requests_total{status=~"5.."}[10m])) / sum(rate(http_requests_total[10m])) > 0.05
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "API 5xx错误率超过5%"
      - alert: SLIBudgetExhausted
        expr: (1 - sum(rate(http_requests_total{status=~"2.."}[30d])) / sum(rate(http_requests_total[30d]))) < 0.90
        labels:
          severity: page
        annotations:
          summary: "30天SLO错误预算已耗尽"

错误预算告警用的是30天滚动窗口，比瞬时错误率更能反映服务质量的真实退化，适合纳入SRE的paging级别。

Alertmanager多级告警路由与收敛策略

告警规则只负责触发，路由和收敛交给Alertmanager。通过severity标签把warning、critical、page三个级别路由到不同接收渠道，同时用抑制规则避免级联告警把pager打爆：

route:
  group_by: ['alertname']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  routes:
    - match: { severity: page }
      receiver: phone
    - match: { severity: critical }
      receiver: im
    - match: { severity: warning }
      receiver: email

inhibit_rules:
  - source_matchers: ['severity=critical']
    target_matchers: ['severity=warning']
    equal: ['alert']

抑制规则解决的是”一个故障炸出多条告警”的问题：高级别告警触发时，同alertname的低级别告警自动静默，值班处理成本明显下降。

告警规则的质量巡检与调优

规则上线前用promtool做静态校验，check与test命令可以直接在CI里跑：

promtool check rules rules.yaml
promtool test rules test_rules.yaml

上线后按月复盘指标：告警准确率等于有效告警数除以总告警数，低于60%说明阈值过严或表达式选取不当；连续三个月paging级别告警中重复事件占比高，就该补充抑制规则或做永久性修复。稳定的监控告警体系下，paging级别告警应长期处于低位，剩余的都交给自动化工具自动恢复。