一、问题是怎么发现的
最近有个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包内。
作者:京东零售 曹志飞
来源:京东云开发者社区