本篇文章分享Log4j疯狂写日志问题排查，对你有帮助的话记得收藏一下，看Java资料网收获更多编程知识

一、问题是怎么发现的

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

作者：京东零售 曹志飞

来源：京东云开发者社区

文章来源:https://www.cnblogs.com/jingdongkeji/p/17629102.html
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若内容造成侵权/违法违规/事实不符，请联系邮箱：jacktools123@163.com进行投诉反馈，一经查实，立即删除！