cover_image

Log4j框架疯狂写日志,导致磁盘打满问题排查

应用研发 曹志飞 京东零售技术
2023年09月01日 12:02
问题是怎么发现的

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

END







往期回顾
RPA+智能问答实现微信端智能客服

一文了解电商大促系统的高可用保障思路-献给技术伙伴们

GPT-4助力数据分析:提升效率与洞察力的未来关键技术

商品推荐系统浅析

竞速榜实时离线对数方案演进介绍

一种轻量级定时任务实现

618技术揭秘|探究竞速榜页面核心前端技术

JDV背后的技术-助力618

一文帮你搞定H5、小程序、Taro长列表曝光埋点

618技术揭秘 - 大促弹窗搭投实践

ChatGPT的探索与实践-应用篇

618技术大揭秘:Switchquery秒级配置触达平台的设计与实现

如何从消失的异常堆栈定位线上问题

架构师日记-从技术角度揭露电商大促备战的奥秘

ElasticSearch - 批量更新bulk死锁问题排查

大促质量备战之三化战役:“常态化、精细化、一体化”

Java · 目录
上一篇谈JVM线程和内存参数合理性设置
继续滑动看下一个
京东零售技术
向上滑动看下一个