一、问题是怎么发现的

最近有个Java系统上线后不久就收到了磁盘使用率告警，磁盘使用率已经超过了90%以上，并且磁盘使用率还在不停增长。

二、问题带来的影响

由于服务器磁盘被打满，导致了系统正常的业务日志无法继续打印，严重影响了系统的可靠性。

三、排查问题的详细过程

刚开始收到磁盘告警的时候，怀疑是日志级别问题，业务日志输出过多导致磁盘打满。但是查看我们自己的业务日志文件目录，每个日志文件内容都不是很大。

于是通过堡垒机登陆问题服务器，查看磁盘使用率很高的目录列表，发现根目录有个很大的日志文件，日志文件名称为log4j.log。但是检查应用日志配置后，日志输出配置路径并没有配置这个日志路径。而且我们用的是logback日志组件和配置文件，并没有使用log4j来输出日志。于是便打开这个未知来源的日志文件内容，记录的日志内容确实是我们自己的java系统写入的日志内容，且大部分都是debug级别日志内容。于是猜测在系统依赖的jar包内也有一个log4j的日志配置文件。于是便把部署包下载下来，然后通过文档遍历扫描所有jar包内的日志配置文件，结果在一个第三方jar包内找到一个log4j.xml配置文件，里边配置的root日志级别为debug，日志输出目录是系统根目录，日志文件名也都可以对应的上。

四、如何解决问题

通过上述排查过程找到了第三方jar包内的log4j配置文件，于是便排查该jar包的来源，发现是被其他jar包传递依赖进来的，并不是我们真实需要的jar包，所以通过maven排除该问题jar包即可。

五、总结反思

1. 以后在引入第三方jar包的时候一定要检查他的依赖范围，看是否会与现有系统的jar包有冲突或者带来其他的影响。

2. 对外提供第三方jar包的时候，不要把自己的调试代码和日志配置测试文件也打入jar包内。

作者：京东零售 曹志飞

来源：京东云开发者社区