上周三凌晨两点，内网值班手机响了。和外内网监控平台弹出一条告警：核心交换机CPU利用率冲到92%，网告持续了整整八分钟。整改我爬起来连上VPN，报告发现同时有台外网Web服务器在疯狂往外发包——两个告警几乎同一秒出现，内网但分属两套监控系统，和外谁也没关联谁。网告

这就是整改问题所在。内网告警和外网告警，报告像两个各说各话的内网哨兵。内网盯着交换机、和外防火墙、网告服务器硬件；外网盯着域名解析、整改HTTP状态码、报告响应延迟。两边数据不互通，阈值各定各的。那次事件后来查清楚，是外网一台机器被入侵后当跳板，向内网发起扫描，把交换机CPU拖垮了。可告警系统压根没把这两件事串起来。

内网告警：阈值拍脑袋，误报当饭吃

翻了下过去三个月的记录，内网告警总数1847条，其中真正需要处理的只有211条。剩下的全是“内存使用率超过80%”这种——那台服务器本来跑着数据库，80%是常态。当初设阈值的人估计没问过运维。更离谱的是，同一个机房的温度传感器，夏天每天下午准时报警，因为空调出风口对着它吹。没人去调，大家习惯了每天删一次。

整改从删告警开始。把纯阈值型告警砍掉三成，换成动态基线：连续七天同一时段波动超过两个标准差才触发。温度传感器挪了位置，加了五分钟持续判定。交换机CPU告警加了个前置条件——必须同时检测到内网端口异常流量。改完第一周，内网告警降到每天不到五条。

外网告警：只盯可用性，不看行为

外网那边更粗糙。监控平台只做三件事：ping通不通、HTTP返回200还是500、页面加载超过三秒就报。至于谁在访问、请求了什么、有没有异常参数，一概不管。那次入侵的机器，外网监控显示“一切正常”——网站能打开，响应也快。它偷偷往外发包的行为，压根不在监控范围里。

我们加了一层流量行为分析。不复杂，就是抓每个外网IP的请求频率、URL长度分布、POST体大小。跑了一周，发现有个IP每分钟请求同一个接口四百多次，参数里带了一串base64。拦掉之后，内网交换机CPU再没无故飙升过。外网告警现在会带一个“关联内网ID”的标签，一旦某个外网IP触发了行为规则，自动去查内网有没有对应端口的异常连接。

两套系统怎么打通

没买新平台。内网监控用的是Zabbix，外网是Prometheus，中间加了个Python脚本做桥接。脚本每三十秒拉一次两边的最新告警，用IP和端口做关联。匹配上了就生成一条合并告警，推送到同一个钉钉群。脚本写得糙，但管用。上线那天试了一次模拟攻击：外网机器扫内网端口，十二秒后合并告警到了群里，附带了攻击源IP、目标端口、交换机CPU曲线截图。

值班同事说，以前半夜被吵醒得先判断是内网还是外网的事，现在一条消息看完就知道该动哪。误报还是会有，但至少不会两个系统各报各的，让人来回切换查半天。

这活儿没干完。内网还有一批老设备不支持SNMP v3，外网日志格式不统一，关联规则目前只覆盖了TCP。但比起之前那种“告警响了先骂一句再爬起来”的状态，现在至少能多睡二十分钟。

(责任编辑：综合)