半夜手机突然响个不停，打开一看又是服务器CPU使用率飙到95%的告警。可等你迷迷糊糊登录系统查看，发现这已经是本周第三次同类提醒——其实系统扛得住，但告警没分级，搞得人神经紧张。问题就出在“严重性告警设置”没做好。
告警不是越多越好，关键在“分等级”
很多系统默认把所有异常都标成“严重”，结果磁盘空间80%、服务重启一次、网络延迟跳一下全发短信邮件，反而把真正要命的问题淹没了。合理划分告警级别，才能让运维人员快速判断：是继续睡觉，还是马上起床处理。
常见的严重性等级可以这样定：
- 紧急（Critical）：服务完全不可用、数据库宕机、核心API全部超时——必须立刻响应
- 严重（High）：性能明显下降、某节点离线、磁盘使用超90%——需在1小时内介入
- 警告（Warning）：资源使用上升、偶发错误增多——可在日常巡检时处理
- 信息（Info）：系统重启、配置变更——记录即可，无需通知
以Prometheus + Alertmanager为例设置分级
假设你在用Prometheus监控，可以在Alertmanager中通过路由（route）机制实现分级通知。比如：
route:
group_by: ['alertname']
group_wait: 30s
group_interval: 5m
repeat_interval: 4h
receiver: 'default-receiver'
routes:
- match:
severity: critical
receiver: pagerduty-escalation
repeat_interval: 1h
- match:
severity: warning
receiver: email-notification
receivers:
- name: pagerduty-escalation
pagerduty_configs:
- routing_key: <your-integration-key>
- name: email-notification
email_configs:
- to: ops@example.com上面这段配置的意思是：只有标记为critical的告警才会推送到PagerDuty触发电话呼叫，而warning级别的只发邮件，避免半夜误扰。
在Grafana里给面板加告警时也别忘了设级别
你在Grafana看某个MySQL连接数的图表，添加告警规则时，记得在Details里填上severity字段。例如：
{
"annotation": {
"summary": "MySQL连接数过高",
"severity": "high"
}
}这样下游系统就能识别并按等级处理。如果不写，等于埋了个“定时炸弹”——不知道哪天就炸了你的睡眠。
定期回顾和压降无效告警
上线三个月后回头看看：哪些告警每周都报但没人理？可能是阈值太敏感，比如“内存使用超70%”其实在业务高峰很正常。这类规则该调低等级，甚至关闭。
有个团队曾把“Kafka消费延迟超过1分钟”设为high，后来发现每天下午三点定时任务跑批处理时必然触发，持续十分钟自动恢复。他们干脆加了个时间静默规则：
inhibit_rules:
- source_match:
severity: high
target_match:
job: kafka-consumer-delay
equal: ['instance']
# 在批处理时间段内抑制该告警
period: 15m从此世界清静了。
真正的高效运维，不在于能处理多少突发事件，而在于让不该响的时候绝对安静。花半小时理清楚你的严重性告警设置，可能换回未来几百个小时的安心睡眠。