Log4j2日志保留策略实战：如何配置1MB文件大小+7天自动清理（附完整XML示例）

Log4j2日志保留策略实战：如何配置1MB文件大小+7天自动清理（附完整XML示例）

最近在帮一个朋友优化他们团队的Java应用时，遇到了一个非常典型的问题：测试环境的服务器磁盘隔三差五就被日志文件塞满，导致应用报警甚至服务中断。开发同学每次都得手动登录服务器，rm -rf 一堆历史日志文件，既繁琐又容易误删。这让我意识到，一个健壮的日志滚动与清理策略，对于任何需要长期稳定运行的应用来说，都不是“锦上添花”，而是“雪中送炭”的必备配置。尤其对于资源相对有限的中小型项目团队，自动化日志管理能省去大量运维心力，让开发者更专注于业务逻辑本身。

今天，我们就深入Log4j2的配置腹地，抛开那些简单的按天切割，来实战一套组合拳策略：严格控制单个日志文件大小（如1MB），同时按时间（如7天）自动清理历史归档文件。我会用一个完整的、可直接复用的XML配置示例，带你一步步拆解每个参数的含义与陷阱，确保你配置一次，就能高枕无忧。

1. 理解核心：为什么需要组合策略？

在开始动手写配置之前，我们得先想明白，单纯的按天滚动或者按大小滚动，为什么常常不够用。

想象一个中等流量的API服务。如果只配置“按天滚动”，那么在某一天如果突发大量请求或出现异常循环，可能会产生一个体积巨大的日志文件（比如几个GB）。这不仅会瞬间占满磁盘，在排查问题时，打开和搜索这个大文件也会异常缓慢。反之，如果只配置“按大小滚动”（比如达到1MB就切分），那么运行一段时间后，你可能会发现磁盘上堆积了成千上万个1MB的小文件，虽然单个不大，但总量依然可能撑爆磁盘，并且文件数量过多也会影响文件系统的性能。

因此，一个理想的策略是 “大小与时间双重管控”：

• 大小触发滚动：确保单个日志文件不会无限膨胀，保持可管理性。
• 时间触发滚动：作为兜底，保证即使流量很低，每天也能产生一个新的日志文件，方便按天归档和查看。
• 基于时间的自动清理：定期删除过期的历史归档文件，从根本上解决磁盘空间问题。

Log4j2的 RollingRandomAccessFile Appender 配合 Policies 和 DefaultRolloverStrategy，完美支持这种组合策略。下面我们就进入实战环节。

2. 构建你的Log4j2.xml配置文件骨架

我们将从一个最精简的、功能完整的 log4j2.xml 配置文件开始。请将其放置在你的项目资源目录下（如 src/main/resources/）。

<?xml version="1.0" encoding="UTF-8"?>
<Configuration status="WARN" monitorInterval="30">
    <Properties>
        <Property name="LOG_PATTERN">%d{yyyy-MM-dd HH:mm:ss.SSS} [%t] %-5level %logger{36} - %msg%n</Property>
        <Property name="LOG_HOME">./logs</Property>
        <Property name="APP_NAME">my-application</Property>
    </Properties>

    <Appenders>
        <!-- 控制台输出，用于开发调试 -->
        <Console name="Console" target="SYSTEM_OUT">
            <PatternLayout pattern="${LOG_PATTERN}"/>
        </Console>

        <!-- 核心：支持滚动的文件日志Appender -->
        <RollingRandomAccessFile
                name="RollingFile"
                fileName="${LOG_HOME}/${APP_NAME}.log"
                filePattern="${LOG_HOME}/archive/$${date:yyyy-MM}/${APP_NAME}-%d{yy