校园网WiFi网络计费系统上线之后，真正考验信息化部门的工作才刚开始。网络是一个持续运行的东西，不是"装好了就不用管了"。尤其校园网面对的是几万学生用户，他们的使用习惯不可预测，网络设备的故障也是随机发生的。没有一套靠谱的运维监控体系，运维人员就是在"等事故"而不是"管网络"。

先区分三个层面的监控需求

运维监控不是一个笼统的概念，在校园网WiFi网络计费系统里至少要区分三个层面。

第一个层面是网络基础设施监控。这包括AP在线状态、AC（无线控制器）运行状态、交换机端口流量、出口带宽使用率。这些数据大部分来自网络设备本身的SNMP或者Telemetry接口，跟计费系统没有直接关系，但计费系统出了问题的时候，这些数据能帮你快速判断是"网络层故障"还是"应用层故障"。比如学生报WiFi连不上，如果监控显示对应楼层AP全部离线，那根本不用查计费系统，是网络层的问题。

第二个层面是认证服务监控。这是计费系统的核心：认证服务器的CPU和内存使用率、RADIUS请求的成功率和响应时间、在线用户数的变化趋势、认证失败的错误类型分布。这些指标能告诉你系统当前是否健康、是否接近承载极限。

第三个层面是业务异常监控。比如某个时间段认证失败率突然升高、某个运营商的认证链路持续超时、某个宿舍楼的在线用户数异常偏低。这些异常可能不是设备故障，而是配置变更、运营商网络波动、或者学生批量换手机号等业务层面的变化导致的。这类监控需要运维人员有一定的业务理解能力才能判断和处理。

监控数据从哪来

对于网络基础设施层，主流做法是用Zabbix或者Prometheus采集SNMP数据。大部分AP和AC都支持SNMP v2c或v3，你可以把它们的IP、community string配进监控系统，自动采集CPU利用率、内存使用率、客户端连接数等指标。出口带宽监控可以在核心交换机或者防火墙上做端口流量采样。

认证服务层的监控数据主要来自计费系统本身。好的计费系统应该提供监控API或者至少把关键指标通过日志暴露出来。如果系统没有现成的API，可以用日志分析的方式——定期从RADIUS日志里统计认证成功率、平均响应时间等指标。这种方法不如直接API调用精确，但胜在通用。

业务异常层的监控数据来源比较分散：用户投诉记录（来自服务台工单系统）、运营商反馈的故障通知、自动化巡检脚本的结果。这些数据不能靠单一工具采集，需要运维人员有一个"信息汇聚"的习惯——不管是用钉钉群、飞书群还是邮件，把各种异常信号集中到一个地方，便于快速判断。

告警怎么做才不会"狼来了"

监控做好了，告警如果做得不好，结果就是运维人员屏蔽了所有告警通知，然后监控系统形同虚设。校园网运维里最常见的告警问题有两个：告警太多（一条设备重启产生几十条关联告警）和告警不够具体（只告诉你"认证服务异常"但不告诉你是RADIUS超时还是数据库连不上）。

解决告警泛滥的方法是做告警聚合和分级。聚合就是把同一个根因产生的多条告警合并成一条——比如某台AC下面的20个AP同时离线，应该发一条"AC-X故障导致20个AP离线"的告警，而不是20条"AP离线"的告警。分级就是按照严重程度分成P0到P3：P0是影响大量用户的（比如出口链路断了），要立即处理；P1是影响部分用户的（比如某个楼层的AC异常），要在30分钟内响应；P2和P3是影响面小或者非紧急的，可以在工作时间内处理。

告警通知的渠道也要匹配严重程度。P0告警应该同时打电话和发短信给值班人员，P1告警发微信/钉钉消息，P2和P3发邮件就行。千万不要P0也用微信通知——运维人员睡觉的时候不会看微信。

可视化Dashboard不是面子工程

很多运维人员觉得Dashboard是"给领导看的"，自己用命令行查日志就行了。但在校园网场景里，Dashboard的价值不在于好看，而在于效率。

想象一个场景：深夜十一点，值班老师接到学生电话说"宿舍WiFi连不上"。如果有一个Dashboard，他打开一看就知道：当前总在线用户数是否正常、最近一小时的认证成功率是多少、对应楼层的AP是否在线、出口带宽是否被打满。如果这些都正常，那大概率是学生自己的设备问题，不用大半夜去机房排查。如果Dashboard显示某楼层AP大面积离线，他可以直接带上工具去现场。

Dashboard至少要展示这些信息：实时在线用户数（折线图）、认证成功率（最近1小时/6小时/24小时）、各运营商认证链路状态（红绿灯）、AP在线率（按区域分组）。数据更新频率不要低于每分钟一次——校园网的状态变化很快，五分钟更新一次的Dashboard跟没有差不多。

定期巡检不能省

自动化监控能发现大部分突发故障，但有些问题是慢慢恶化、不会触发阈值告警的。比如RADIUS服务器的磁盘空间在几个月内逐渐接近满、认证日志表的数据量增长导致查询越来越慢、某个运营商的认证链路平均响应时间从500ms慢慢涨到2000ms但还没超阈值。

这些问题需要定期巡检来发现。建议每周做一次自动化巡检：检查服务器磁盘空间、数据库表大小、SSL证书有效期、系统日志中的Warning和Error数量。巡检结果自动生成报告发送给运维负责人，有异常的标红。这种"低成本、低频次"的检查能帮你赶在问题爆发之前发现隐患。

运维文档要写但别写太多

最后提一个不太技术但很重要的事：运维文档。你的校园网WiFi网络计费系统的配置有哪些、各模块之间怎么关联、常见故障的排查步骤是什么、运营商对接人的联系方式、设备管理IP和密码——这些东西如果只存在于某个运维人员的脑子里，一旦他离职或者请假，其他人接手会非常痛苦。

运维文档的写作原则是"够用就好"。不需要写成几十页的操作手册，但至少要把架构图、关键配置、联系人、常见故障处理这四样东西整理出来，放在整个团队都能访问到的地方（Wiki、共享文档、甚至是群里置顶消息）。当凌晨两点出了故障、值班的人又不太熟悉系统的时候，一份简洁有效的文档可能是最可靠的帮手。