Log4j疯狂写日志问题排查 | 京东云技术团队

一、问题是怎么发现的

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

作者:京东零售 曹志飞

来源:京东云开发者社区

相关推荐
实名上网宋凯宣8 小时前
Django
后端·python·django
天河归来9 小时前
第三方接口不稳定,如何让核心任务继续完成
java·大数据
Knight_AL9 小时前
Java 文件下载时文件名中的 `#` 被转换成 `%23`?一次 URL 编码与解码问题排查
java·开发语言
利威尔xu10 小时前
Go IM 源码实战(14):本地缓存快 3000 倍,失效却难 10 倍
后端·缓存·微服务·面试·golang
逃逸线LOF10 小时前
Ribbon负载均衡原理(Irule组件、源码分析)
后端·spring cloud·ribbon
砚底藏山河10 小时前
python量化自定义周期 K 线合成
java·开发语言·数据库·python·金融
慢云智慧空间10 小时前
从设备智能到空间理解,空间智能终端解决方案商如何重新定义行业标准
后端
利威尔xu11 小时前
Go IM 源码实战(13):30 个会话只有 2 个红点,未读数错在三条路径
redis·后端·微服务·面试·golang
猿究院_夏燊11 小时前
MySQL 的四种隔离级别
java·数据库·mysql
薛定谔的猫-菜鸟程序员11 小时前
软件架构设计师开发资料大全(从入门到精通)
后端·python·系统架构·flask·架构设计师