做校园网运维的应该都经历过这种事：学生打电话说上不了网，你让他检查线插好了没，他说插好了；让他重启，他说重启了还是不行；你再问报什么错，他说不知道就是连不上。然后你只能远程或者跑到现场去查。如果校园上网计费系统的日志写得清楚，排查效率能高很多；反之日志一团糊，一个5分钟能定位的问题可能要折腾半小时。

认证日志最先该看

用户说"上不了网"，80%的情况出在认证环节。不管是Web认证、802.1X还是Portal推送，只要认证没通过后面什么都免谈。所以计费系统至少应该把每次认证尝试的这些信息记下来：请求来源的MAC和IP、提交的用户名（脱敏）、认证方式、请求时间、处理结果（成功/失败/超时）、失败原因码、后端响应耗时。

我见过最糟糕的日志设计是只记"认证失败"四个字不记原因。运维看到这条日志唯一的反应就是——然后呢？密码错了？账号过期了？并发数超限了？后端Radius挂了？完全没法判断。后来我们强制要求把Radius返回的Reject-Cause原样记下来，即使有些厂商自定义的原因码看不懂起码拿到code可以去查文档或问技术支持。

扣费日志不能只记结果

扣费相关的日志最容易出问题。不是扣费逻辑多复杂，而是当金额对不上的时候你需要有完整的证据链来还原过程。

一条合格的扣费日志至少包含：谁（用户标识）、什么时候（精确到秒）、因为什么（上线扣/周期扣/手动扣）、扣了多少（变更前余额→变更后余额）、操作人/触发源（系统自动/管理员手工/接口调用）。缺了任何一个字段后续对账和审计都很痛苦。

之前帮一个学校排查过账目差异：财务说一个月少了800多块钱。我们把扣费日志导出来跟一卡通流水比对发现问题在这：半夜有个自动化脚本在做清理僵尸会话的操作，把这些已经断开但状态没更新的会话强制下线并补扣费用。但这个脚本只记了"补扣完成共处理37个会话"没记每个会话具体扣了多少。最后只能从Radius的在线用户日志反向推算花了大半天才把数字凑平。从那以后我要求所有涉及资金变动的操作必须逐条记录明细不允许汇总式日志。

在线用户表的更新日志别漏掉

校园上网计费系统一般维护一张在线用户表记录当前谁在线、什么时候上线、分配了哪个IP走了哪个出口。这张表的状态变化也应该被记下来。

为什么？因为"幽灵在线"是常见问题——用户其实断开了（拔了线关了WiFi）但计费系统不知道还认为他在线。后果一是被持续计费（投诉重灾区），二是占用并发名额导致其他人上不去。如果你有完整的状态变更日志（上线/正常下线/异常掉线/强制下线/心跳超时踢出），排查这类问题就很简单。

有个学校的案例很典型：每到晚上10点半到11点就有大量学生投诉被多扣钱。查了几天日志发现规律——这个时间刚好是他们宿舍楼定时断电的时间，断电后AP没电了所有无线客户端同时掉线。但计费系统的掉线检测依赖心跳包心跳间隔60秒加上检测容忍窗口实际需要90秒到2分钟才能把所有掉线用户标记离线。这2分钟内产生的流量还在累计部分按流量计费的学生就被多收了。后来我们在日志里加了"批量异常掉线告警"：30秒内超过50个用户同时掉线立即触发事件标记并跳过这批用户的当次计费结算。

系统间调用链的日志

现在的校园上网计费系统很少独立工作基本都要跟Radius、DHCP、一卡通、统一身份认证等交互。当一个上网请求过来经过的链路很长：终端→AC/AP→Portal页面→计费系统→Radius→认证源→返回→计费系统写在线记录→通知网关放行。任何一环出问题都导致最终失败。

如果每个系统各自记各自的日志格式时间戳还不统一出问题时要拉好几个系统的日志做关联分析非常低效。理想的做法是给整个调用链分配一个TraceID从用户第一个HTTP请求开始一直透传到最后一步所有相关日志都带这个ID。这样在任何系统日志里搜这个ID就能把完整路径串起来。

当然这对已有系统改造成本比较高不可能一步到位。但至少可以在计费系统内部做到：对于每次外部调用（查余额、扣费、查认证状态等），记录调用的目标系统、传入参数摘要、返回码、耗时。这些信息在排错时的价值非常大尤其是当你需要判断"到底是谁慢了"的时候。

日志量太大怎么办

有人会说上面说的全记下来日志量太大了。确实万人规模的学校一天认证和扣费日志轻松几十万行。但存储现在不贵真正的成本在于查询效率和噪音过滤。

我的建议是分级别：INFO级记录关键业务节点（认证成功/失败、扣费、上下线），DEBUG级记录详细参数和中间状态。生产环境默认开INFO出问题时临时开DEBUG。定期（每周）归档到对象存储或日志平台本机只保留最近3-7天。另外加一个"异常日志自动聚合"机制：同一类错误短时间大量出现时合并上报不要每条都发告警。比如"密码错误"一天5000次不需要报警但"Radius连接超时"连续10次就该立刻通知。