Log4j2日志保留策略实战：如何设置1MB文件大小和7天自动清理

Log4j2日志保留策略实战：如何设置1MB文件大小和7天自动清理

日志管理，听起来像是运维的活儿，但哪个资深开发者没在凌晨被磁盘告警短信吵醒过？点开服务器一看，某个服务的日志目录已经悄无声息地吃掉了上百GB的空间。这不仅仅是磁盘空间的问题，海量的日志文件会让排查问题变得像大海捞针，严重拖慢开发调试和线上问题定位的效率。对于追求系统稳定性和可维护性的团队来说，一套清晰、自动的日志保留策略不是“锦上添花”，而是“雪中送炭”的工程实践。

本文将从一个实战派的角度，深入剖析如何利用Log4j2强大的RollingRandomAccessFile Appender，精细地控制日志文件的“生老病死”。我们不仅会实现“单个文件不超过1MB”和“最多保留7天日志”这两个核心目标，更会拆解其背后的配置逻辑，让你知其然，更知其所以然。无论你是正在为日志膨胀头疼的开发者，还是希望提前构建健壮日志体系的技术负责人，这里都有你需要的“操作手册”和“避坑指南”。

1. 理解Log4j2的滚动与删除机制

在动手写配置之前，我们得先搞清楚Log4j2是如何管理日志文件生命周期的。很多人对RollingFileAppender或RollingRandomAccessFileAppender（后者性能更优）有个模糊的概念：“就是日志满了换一个新文件”。这个理解只对了一半。实际上，这个过程分为两个核心阶段：滚动 和 清理。

滚动 指的是触发条件满足时，将当前正在写入的日志文件“归档”，并创建一个新的空日志文件继续写入。触发滚动的条件可以基于时间（例如每天零点）、文件大小（例如达到1MB），或者两者结合。

清理 则是在滚动发生之后，根据策略删除那些过于陈旧的归档日志文件，防止它们无限制堆积。这是一个独立的、可配置的步骤。

如果把日志系统比作一个档案馆：

• 当前日志文件：正在被档案员（应用程序）书写的记事本。
• 滚动：记事本写满了（或到了下班时间），档案员将其放入标明日期的档案盒（归档），并拿出一本新的空白记事本继续写。
• 归档文件：那些被放入档案盒的旧记事本（通常会被压缩以节省空间，如.log.gz）。
• 清理：档案管理员定期检查档案盒，将超过保存期限（如7天）的旧盒子整个丢弃。

Log4j2通过 Policies 来定义 何时滚动，通过 DefaultRolloverStrategy 中的 Delete 动作来定义 如何清理。理解这个分工是进行一切高级配置的基础。

1.1 核心组件拆解：Policies 与 Strategy

下面这个表格清晰地展示了这两个核心组件及其子元素的分工：