公司刚上班不到半小时，IT 小李就被一通电话叫到财务部。原来财务系统突然无法访问，发票开不了，整个部门都卡住了。查了一圈才发现，是核心交换机的某个端口异常，但前一天晚上设备早就发出了警告，只是没人收到。
告警不是摆设，得让它真正发声
很多单位的网络设备虽然支持告警功能，但实际配置却很敷衍。比如 SNMP Trap 只配了个默认接收地址，或者邮件通知只发给一个早已离职的管理员。更常见的是，告警阈值设得太松，CPU 利用率跑到 95% 才触发，等发现时设备已经卡死。
真正的告警设置，是要在问题影响业务前就拉响警报。比如某台防火墙连接数持续上升，可能意味着有人在扫描或发起慢速攻击。如果能在连接数达到正常值 80% 时就提醒，就能提前介入，而不是等到用户反馈“网页打不开”才行动。
常见的告警类型和建议阈值
不同设备关注的重点不一样，下面是一些实用参考：
- 交换机端口状态变化：端口从 up 变成 down 必须立即通知，尤其是接服务器或关键办公区的端口。
- CPU 和内存利用率：连续 5 分钟 CPU 超过 70% 就该提醒，超过 85% 应升级为高优先级告警。
- 温度异常：机房空调出问题时，设备温度上升很快。设定超过 45℃ 就发警告，避免硬件损坏。
- 日志中的关键词匹配：比如防火墙日志中出现 "denied" 频率突增，可能是策略误配或攻击行为。
怎么把告警送到手上
光有告警不行，还得确保人能收到。很多人依赖邮件，但手机静音、邮箱延迟都可能导致漏看。更好的方式是结合多种通道：
- 紧急告警通过短信或企业微信推送，确保第一时间看到。
- 一般告警汇总成日报邮件，方便复盘。
- 使用开源监控工具如 Zabbix 或 Prometheus + Alertmanager，灵活配置通知策略。
比如用 Zabbix 监控路由器，可以这样设置触发条件：
{Router01:sysUpTime.last()}<3600 && {Router01:sysUpTime.prev()}>3600意思是：当前设备运行时间小于 1 小时，且上次大于 1 小时，说明刚重启了。这种情况如果是非计划的，就得马上知道。
别忘了测试和清理
设完告警不测试，等于没设。可以手动断开一根测试线缆，看看是否收到端口 down 的通知。另外，旧设备退役后要及时关闭相关告警，不然半夜收到一台不存在的服务器的硬盘故障提示，只会让人麻木。
有个客户曾经长期忽略一条“UPS 电量低”的重复告警，后来一次停电直接导致核心设备断电重启。其实那台 UPS 早就坏了，但因为没人验证告警有效性，问题被当成噪音忽略了。
告警系统不是一次配置就一劳永逸的事。定期 review 告警记录，调整阈值，合并冗余信息，才能让它保持敏锐。