最近两天业务反馈，自己的页面编辑的时候报404错误。业务告诉我们16层网络有问题17层就没事，问我们怎么解决。估计不细心的小伙伴可能就会被业务自我判断的“结果”给误导了。
我们组的小伙伴还真信以为真，仔细想想，业务反馈的问题有漏洞，其他页面使用正常而编辑页面404这哪是网络问题。于是我找了运维同学查了下业务使用页面的情况，先找到链接查询Nginx上404调用记录，发现只有73机器使用编辑的时候404，其他页面正常。难道是代码问题，奇怪的是同样的代码其他机器没有问题，就是73机器有问题。连接73机器看看情况，发现这个机器硬盘空间已经满了，Tomcat当天日志都没有，那查询怎么没事？原来是编辑页面打开的时候要写入大量的日志而查询不写日志，结果返回给浏览器上是404状态，这个误导性很大，希望小伙伴注意这个情况。
总结下，如何避免这个问题，使用脚本定期清理日志，要有磁盘报警通知运维。其实我们公司都是有预警的，只是之前的运维把我这个项目忘记安装监控软件了，就导致这样的结果。
