Log4j2添加CronTriggeringPolicy后滚动文件时间戳变全0问题

问题原因 #

• fileName配置不符合设计规范：你直接在当前写入的日志文件名fileName中使用${date:yyyy-MM-dd_HH:mm:ss:SSS}插值，这个变量是配置初始化时一次性计算的静态值，当Cron触发滚动时，Log4j2无法正确关联上一个滚动周期的实际时间，只能默认用当前日期的起始时间（00:00:00.000）填充filePattern中的%d占位符，就出现了时分秒毫秒全0的问题。
• 版本兼容问题：Log4j2 2.14.1版本本身存在CronTriggeringPolicy与其他滚动策略（SizeBased、OnStartup）混用时的时间计算bug，Cron策略会错误覆盖滚动时间的计算逻辑，优先使用Cron窗口的起始时间作为滚动文件的时间戳，多策略共存时逻辑冲突进一步加剧了时间戳异常。
• 压缩后缀配置错误：你将.gz后缀直接加到了fileName上，而RollingFile的fileName对应的是当前正在写入的未压缩文件，压缩动作是滚动时才执行的，这个错误配置也会干扰滚动时的文件名解析逻辑。

修复方案 #

首先修改RollingFile配置修正错误项：

<?xml version="1.0" encoding="UTF-8"?>
<Configuration status="INFO">
    <Appenders>
        <!-- fileName改为固定未压缩文件名，去掉静态时间戳和gz后缀 -->
        <RollingFile fileName="data/appname.log" filePattern="data/appname-%d{yyyy-MM-dd_HH:mm:ss.SSS}.%03i.gz" name="AppAppender">
            <PatternLayout>
                <pattern>%-6p %d{yyyy-MM-dd HH:mm:ss.SSS} %c{1}: %m%n
                </pattern>
            </PatternLayout>
            <Policies>
                <OnStartupTriggeringPolicy/>
                <SizeBasedTriggeringPolicy size="10MB"/>
                <!-- 增加evaluateOnStartup属性避免启动时时间计算异常 -->
                <CronTriggeringPolicy schedule="*/5 * * * *" evaluateOnStartup="true"/>
            </Policies>
            <DefaultRolloverStrategy>
                <Delete basePath="data/" maxDepth="2">
                    <IfFileName glob="*appname-*.gz"/>
                    <!-- 测试完成后将age改为14d即可实现删除2周以上旧日志的需求 -->
                    <IfLastModified age="1d"/>
                </Delete>
            </DefaultRolloverStrategy>
        </RollingFile>
        <Console name="console" target="SYSTEM_OUT">
            <PatternLayout pattern="[%-5level] %d{yyyy-MM-dd HH:mm:ss.SSS} [%t] %c{1} - %msg%n"/>
        </Console>
    </Appenders>
    <Loggers>
        <Logger additivity="false" name="com.app.Test">
            <AppenderRef ref="AppAppender"/>
        </Logger>
    </Loggers>
</Configuration>

如果修改配置后问题仍存在，建议将Log4j2版本升级到2.17.2及以上稳定版，该版本已修复CronTriggeringPolicy的时间计算相关bug，同时也修复了多个高危安全漏洞，更适合生产环境使用。

内容的提问来源于stack exchange，提问作者Shrey Shrivastava