Prometheus告警规则怎么配才合理？

配置告警规则从来都不是简单的“写个表达式”那么简单，很多团队刚上手 Prometheus 时，往往容易陷入两个极端：要么把阈值设得过于敏感，导致半夜两点被毫无意义的“CPU飙升”短信轰炸，最后愤而把手机调成静音；要么为了图清净，把阈值设得极其宽松，等到业务真的挂了才发现监控系统一声不吭。所谓的“合理”，本质上是在发现问题的灵敏度和运维人员的心理健康之间寻找那个微妙的平衡点。

告警的核心在于“降噪”

很多人配置告警规则时，恨不得把所有指标都监控起来，这种“宁可错杀一千”的思路是造成告警疲劳的元凶。一个合理的告警规则，必须具备可操作性。如果一条告警触发了，接收者除了“把它关掉”之外没有任何实际操作手段，那这条告警就是噪音。

举个例子，CPU 使用率瞬间飙到 90% 其实很常见，如果这时候立即告警，大概率是虚惊一场。真正合理的配置是引入持续时间（for 子句）。比如：

- alert: HighCPU
  expr: 100 - (avg by(instance) (irate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 85
  for: 5m
  labels:
    severity: warning

这段规则的意思是，只有当 CPU 持续 5 分钟高于 85% 才触发告警。这 5 分钟的缓冲期，能有效过滤掉瞬时流量波动带来的干扰，确保推送到手机上的每一条信息都值得关注。

分级：别把所有鸡蛋放在一个篮子里

把所有告警都发到同一个地方（比如公司大群或者个人的短信）是另一个常见的错误。合理的配置必须包含分级策略。通过 Alertmanager 的路由配置，我们可以根据严重程度（severity）将告警分流。

• Warning（警告）：这类问题通常不需要立即处理，比如磁盘使用率达到 70%。这类信息适合发到钉钉或 Slack 的低优先级频道，每天看一眼就行。
• Critical（严重）：这类问题意味着业务受损，比如服务宕机、数据库连接池耗尽。这需要立即触发电话或短信通知，甚至要能自动叫醒值班人员。

这种分层机制能保护运维人员的“警报敏感度”，如果每天收到 100 条无关痛痒的 Warning，等到真正的 Critical 来临时，人的本能反应往往是迟钝的。

避免静态阈值的陷阱

“CPU 超过 80% 就告警”这种静态阈值写进文档里看起来很标准，但在实际生产环境中往往很鸡肋。对于某些 IO 密集型应用，80% 可能是常态；而对于某些核心交易服务，60% 可能就已经是异常了。

更合理的做法是结合基线检测或者多维度判断。虽然 Prometheus 本身主要依赖阈值，但我们可以在规则编写上动动脑筋。比如，不要只看绝对值，而是看“变化率”。如果错误率在 1 分钟内翻倍，哪怕绝对值只有 0.1%，也往往意味着严重故障的开始。与其死磕那个完美的百分比数字，不如多花时间研究业务指标的波动规律。

告警不是终点，是排障的起点

最后，一个完美的告警规则不应该只是一行冷冰冰的文字。当凌晨三点警报响起时，值班人员最需要的不是知道“出事了”，而是知道“怎么看”。在 annotations 中附上相关的查询链接、排查手册的 Wiki 地址，甚至是预期的止损方案，能极大地缩短故障恢复时间（MTTR）。

说到底，Prometheus 告警规则的配置过程，就是对团队故障处理流程的一次梳理。规则写得越合理，团队在故障面前的表现就越从容。那些被删掉的冗余告警，往往比新增的监控指标更有价值。