章
目
录
一、问题的发现
近期，一款Java系统刚刚上线不久便接收到了磁盘利用率方面的告警，磁盘利用率已超过90%以上，且持续呈上升趋势。
二、问题引发的影响
由于服务器的磁盘被充满占用，致使正常的业务日志无法继续记录，这严重地影响了系统的稳定性与可靠性。
三、问题排查的详细过程
初期，接收到磁盘警示时，怀疑问题或许源自日志等级过高，导致业务日志过度记录而引发磁盘充满。但是，仔细检视自身的业务日志文件夹，每个日志文件的容量都并不巨大。
于是，通过登入问题服务器的堡垒机，察看高磁盘利用率的文件夹清单，发现主目录内有一巨大的日志文件，命名为log4j.log。
然而，在审查应用的日志设置后，发现并未配置该日志路径。同时，我们实际使用的是logback日志组件及其配置文件，而非log4j来执行日志记录。
因此，我们打开了这个未知来源的日志文件，结果发现所记录的日志内容实际上是我们Java系统所生成的，其中大多数内容为debug级别的日志。
鉴此，我们推测在系统所依赖的JAR包中，可能还存在一个log4j的日志配置文件。于是，我们下载了部署包，并透过文件文档逐一扫描所有JAR包中的日志配置文件。
最终，在一个第三方JAR包内，我们找到了一个log4j.xml的配置文件，其中的根日志级别被设定为debug，日志输出目录指向系统主目录，且各个日志文件名能够一一对应。
四、问题解决方法
透过上述排查过程，我们确定了第三方JAR包中的log4j配置文件，于是我们进一步追查该JAR包的来源。结果发现，这个JAR包是被其他JAR包作为依赖传递进来的，并非我们实际所需。
因此，我们借助Maven，将引发问题的JAR包排除在外，从而解决了此问题。
五、总结与反思
今后，在引入第三方JAR包时，务必仔细审视其依赖范围，确保其不会与现有系统的JAR包发生冲突，或带来其他负面影响。同时，若向外部提供第三方JAR包，应当避免将调试代码和日志配置测试文件打包至JAR包中。这样的举措能够有效地避免类似的问题。
