小编点评

**问题发现过程：** 1. Java 系统出现磁盘使用率告警，磁盘使用率超过 90% 以上。 2. 问题带来的影响是服务器磁盘被打满，导致系统正常业务日志无法打印，严重影响了系统的可靠性。 3. 怀疑日志级别问题，业务日志输出过多导致磁盘打满。 4. 通过堡垒机登陆问题服务器，发现根目录有个很大日志文件，但检查应用日志配置后，日志输出配置路径并没有配置这个日志路径。 5. 仔细检查第三方 jar 包，发现其中有一个 log4j.xml 配置文件配置的 root 日志级别为 debug，日志输出目录是系统根目录，文件名也都可以对应的上。 **解决方案：** 1. 通过 Maven 排除第三方 jar 包，发现是被其他 jar 包传递依赖进来的。 2. 对外提供第三方 jar 包的时候，不要把自己的调试代码和日志配置测试文件也打入 jar 包内。 **总结：** 问题是第三方 jar 包中的 log4j 配置文件导致了系统日志输出到系统根目录的错误配置。通过排除依赖问题并对外提供第三方 jar 包时，可以避免出现此类问题。

正文

一、问题是怎么发现的

最近有个 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 包内。

作者：京东零售 曹志飞

来源：京东云开发者社区