你有没有遇到过这种情况：半夜手机突然狂震，打开一看是路由器发来的“严重告警”，心一紧以为整个办公室断网了，结果发现只是某台打印机掉线了？其实问题没那么大，但告警级别没分清，搞得跟出大事一样。
告警不是越响越好，得分级才实用
网络监控系统每天要处理成千上万条状态信息，如果每条都当成紧急事件来处理，运维人员早就崩溃了。所以得像医院分诊一样，把告警按影响程度分级，让不同问题得到匹配的响应速度。
常见的四级划分法，接地气又管用
在实际工作中，大多数团队会采用四个级别来区分告警的轻重缓急：
Level 1 - 紧急（Critical）
这是最高等级，代表服务完全中断或核心设备宕机。比如主交换机挂了、数据库服务器死机、外网链路全断。这种必须立刻处理，通常会触发电话呼叫、短信轰炸，值班人得马上上线。
Level 2 - 严重（Major）
功能部分受损，但还能撑一会儿。例如某个业务接口响应超时超过5分钟，或者磁盘使用率飙到95%以上。这类需要在1小时内介入，防止滑向Level 1。
Level 3 - 警告（Minor）
小毛病，不影响主流程。像是某台边缘设备CPU短暂冲高，或是备份任务延迟了几分钟。这类可以放进工单系统，第二天排班处理就行。
Level 4 - 提醒（Info）
不算故障，只是告诉你发生了什么。比如用户正常登录登出、配置变更记录。这类一般不推送到手机，只存日志里备查。
举个生活化的例子
这就像家里装了智能安防系统：
Level 1 是有人破门而入，警笛拉响；
Level 2 是阳台窗户没关，风雨可能进屋；
Level 3 是猫碰倒了花瓶，动静不大；
Level 4 是你下班开门回家，系统记一笔“主人已归”。
配置示例：Zabbix里的简单实现
如果你用的是Zabbix这类监控工具，可以通过触发器设置不同严重性。下面是一个判断Web服务是否可达的表达式：
{Template HTTP Service:web.test.failures.last()}>0然后把这个触发器关联到“严重”级别，一旦检测到HTTP测试失败，就生成Major告警。如果是响应时间超过3秒，可以用另一个规则设为Minor：
{Template HTTP Service:web.test.time.avg(5m)}>3别让低级告警淹没关键信息
见过最头疼的情况，是一家公司把所有告警都设成“紧急”，结果运维直接把通知静音了。等真出事时没人知道。合理的分级本质是信息过滤，把真正该关注的问题筛出来。
另外提醒一句，级别划分不是定下来就一劳永逸。随着业务变化，原来算Minor的问题，可能现在就是Critical。定期回顾告警记录，调整阈值和分类，才能让监控系统一直保持灵敏。