Prometheus告警规则怎么写才不误报？分级告警与抑制配置实战

告警是监控体系的出口，告警规则写不好，监控就变成摆设。常见的告警问题是”阈值写死导致误报”和”告警风暴把值班人淹掉”。本文围绕Prometheus告警规则的编写、分级与抑制，给出从单条规则到整体告警策略的配置方法。

告警规则的基础结构：expr、for与labels

groups:
  - name: host-basic
    rules:
      - alert: HostCpuHigh
        expr: 100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 90
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "实例CPU使用率过高"
          description: "{{ $labels.instance }} CPU使用率已超过90%，持续10分钟"

三个关键点：expr只描述异常状态；for是持续时长，用来过滤瞬时抖动；labels里的severity用于后续分级路由。实践中for时间按指标特性取值，CPU这类波动指标建议5-10分钟，磁盘空间这种缓慢变化指标可以用30分钟，杜绝”5分钟窗口内瞬时突刺”触发告警。

用relabeling和比率指标避免阈值误报

直接对原始值设阈值容易误报，比如”内存使用率>90%”在跑缓存的机器上就是常态。先算比率再设阈，才能反映真实压力：

# 内存使用率用available换算，比used更准确
- record: node_memory_usage_ratio
  expr: (1 - (node_memory_Available_bytes / node_memory_MemTotal_bytes)) * 100

对磁盘这类持续写满的服务，设置”预计满盘时间”比固定阈值更有用：

- record: disk_fill_time_hours
  expr: (node_filesystem_avail_bytes / rate(node_filesystem_writes_bytes_total[1h])) / 3600

用routes做分级：warning、critical怎么分

Alertmanager的路由按标签匹配，把告警分流到不同渠道和接收人。分级配置示例：

route:
  group_by: ['alertname', 'instance']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  routes:
    - match:
        severity: critical
      receiver: pager
      repeat_interval: 30m
    - match:
        severity: warning
      receiver: slack-general

receivers:
  - name: pager-call
    webhook_configs:
      - url: http://10.0.0.5:8080/call
  - name: slack-general
    slack_configs:
      - api_url: ...

分级时不必把阈值设得太激进：critical留给”服务不可用、数据不完整”这类真正影响业务的事件；warning留给”资源告急、容量预警”这类可观察、可等待的。核心指标用critical，环境指标用warning，是写规则时比较省心的分法。

抑制与聚合：防止告警风暴

节点宕机时，该节点上的所有服务都不可达，会给每个指标都触发告警。用inhibit_rules对父级告警做抑制，避免连发十几条：

inhibit_rules:
  - source_match:
      severity: critical
      alertname: InstanceDown
    target_match_re:
      severity: "warning|info"
    equal: ["instance"]

聚合方面，把group_by设置成alertname+instance即可把同一告警收敛成一条；真正在意的是报警内容能否让人一眼看出故障对象和持续时间，summary和description要写清实例名、指标名、阈值、持续时长四要素。

告警规则上线前的三类验证

写好的规则别直接推到生产。用promtool做校验：

promtool check rules alert.yml
promtool test rules test.yaml  # 内置单元测试，指定条件预期触发

另外要定期跑”告警规则对账”：把历史告警记录和值班记录的相符程度拉出来对比，规则长期触发却没有对应故障事件的，多半是阈值或表达式写偏了。告警系统本身也需要SLA：延迟（触发到收到消息）与漏报率（规则没触发但业务实际故障），这两个指标比告警规则数量更有意义。