网络设备监控报警不响？先别急着重启
最近公司会议室的网络老是断，可监控系统却一声不吭。直到同事打电话过来问‘你们网是不是又挂了？’才发现问题。查了一圈，原来是报警没响，压根没人知道设备出事了。这种情况其实挺常见，尤其是用Zabbix、Prometheus或者一些国产监控平台的时候。
第一步：确认是不是真的‘没响’
有时候不是报警没触发，而是你没听见。比如声音被系统静音了，或者通知发到了邮箱但没人看。先去后台看看有没有报警记录，登录系统，翻一下最近的告警日志。如果记录里有报警事件，但你这边没收到，那问题出在通知通道。
检查通知方式配置
常见的通知方式有邮件、短信、微信、钉钉、企业微信机器人等。比如你用了钉钉机器人，得确认Webhook地址有没有失效，网络能不能通。可以手动测试一下：
curl -X POST \
'https://oapi.dingtalk.com/robot/send?access_token=你的token' \
-H 'Content-Type: application/json' \
-d '{"msgtype": "text", "text": {"content": "测试报警"}}'如果返回错误，说明机器人配置有问题，可能是权限改了或者token过期。
声音报警没响？查系统和播放设备
有些监控软件支持本地弹窗+声音提醒。如果你坐在电脑前却没听到，先看音箱是不是关了，系统音量有没有调低。Windows用户可以点右下角喇叭，看看对应程序的声音输出是不是被禁了。Mac也一样，去声音设置里挨个排查。
报警规则设对了吗？
有时候设备CPU跑到95%，但你设的是98%才报警，那就不会响。去监控系统的触发条件里看看阈值是不是太严。还有些人把报警级别设成‘信息’而不是‘警告’或‘严重’，结果根本不推送。比如Zabbix里，动作（Action）必须绑定正确的触发器级别和操作方式。
服务本身卡了或没运行
最怕的是监控系统自己罢工。比如服务器资源耗尽，Java进程挂了，或者Docker容器崩了。SSH登录上去看看服务状态：
systemctl status zabbix-server或者查看容器：
docker ps | grep monitor如果发现服务没在跑，先启动，再查日志定位原因。
防火墙或网络策略拦了通知出口
有些公司内网严格限制外发请求。比如监控系统要发邮件，但SMTP端口25被封了；发微信通知要连腾讯的API，但 outbound 被策略挡住。这时候就算规则配对了也送不出去。可以临时用telnet或curl测试目标地址通不通。
加个备用通知方式更安心
别只依赖一种通知。比如主用钉钉，再加个邮件抄送，关键人员手机上装好客户端。还可以设置二次通知，第一次不读，10分钟后自动再发一次。这样哪怕人不在电脑前，也能及时发现问题。
监控报警不响，往往不是大故障，但容易拖成大问题。定期做一次报警测试，就像消防演习，花十分钟，能省掉半夜救火的麻烦。