Prometheus告警规则如何优化？

在大型集群里，Prometheus 的告警规则往往像密布的雷区，一不小心就会触发海量噪声。如何在保证及时发现真实故障的前提下，压缩规则体积、降低计算开销，是每位运维工程师的必修课。

规则粒度与表达式简化

规则粒度决定了查询的复杂度。把同一类指标的阈值写在同一条 alert 中，看似省事，却会让每一次 eval 产生多余的聚合计算。拆分成业务维度或主机标签的细粒度规则，配合 for 持续时间，可让 Prometheus 只在异常持续一定周期后才触发，显著削减抖动。

• 使用 rate / irate 替代原始计数，避免全局计数的瞬时波动。
• 避免在 alert 表达式里使用跨实例的 count、sum 聚合，改为先写成 recording rule。
• 将高频计算抽取为 recording rule，供后续多条 alert 复用。
• 合理设置 evaluation_interval 与 for，防止短暂峰值触发。
• 为每条 alert 添加明确的 severity 与 service 标签，便于后续抑制。

# 优化后的 HighCPU 规则
- alert: HighCPU
  expr: (100 - avg by (instance) (irate(node_cpu_seconds_total{mode="idle"}[2m]) * 100)) > 85
  for: 3m
  labels:
    severity: critical
    service: compute
  annotations:
    summary: "实例 {{ $labels.instance }} CPU 使用率持续高于 85%"
    description: "当前 CPU 使用率为 {{ $value }}%，请检查进程异常或负载突增。"

录制规则与复用

把常用的聚合表达式写入 recording_rules.yml，生成如 node_cpu_idle:5m 的时间序列后，后续 alert 只需引用该指标，计算量从每分钟的几百次降到十几次。实际案例中，一家电商平台将 CPU、内存、磁盘 IO 三个录制规则合并后，Prometheus 的 CPU 使用率查询从 450 ms 降至 120 ms。

Alertmanager 抑制与分组

告警抑制（inhibition）是防止同一根因产生多条冗余通知的关键。通过在 alertmanager.yml 中定义 inhibit_rules，让高危级别的告警屏蔽低危级别的同源告警；再配合 group_by 与 group_wait，把同一服务的多条告警合并为一条摘要，邮件、钉钉或 Slack 的噪声大幅下降。

监控成本的细致衡量

指标基数（cardinality）是隐藏的性能杀手。使用标签时要审慎，避免在同一 metric 上叠加过多维度。比如 http_requests_total{method,code,instance,job} 在数千台机器上会产生上千万条时间序列。实践中，将 instance 抽象为 service，并在节点层面通过 relabel 将不必要的标签剔除，整体存储成本下降约 35%。

于是，告警系统从噪声海洋变成了精准的灯塔。