Logback滚动策略索引到996后停止删除归档日志如何解决

问题根因 #

你遇到的是Logback内置SizeAndTimeBasedRollingPolicy的默认索引上限限制问题：

• 策略中%i的默认最大值为999，当同一个时间窗口内生成的日志分片数达到/接近999时，滚动逻辑无法生成更高索引值的文件，配套的按totalSizeCap、maxHistory执行的旧文件清理逻辑也会触发异常，无法正常删除过期归档，最终导致磁盘占用持续上涨。
• 你遇到的场景刚好是日志量激增（比如Kafka故障大量报错输出），分钟级时间窗口内短时间生成了超900个10MB分片，直接触达索引上限。

可行解决方案 #

方案1：调整索引上限参数（最简单快速） #

在你的rollingPolicy配置中新增<maxIndex>配置，将默认的999调整到更大值，比如按你的日志量预期调到10000：

<rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy">
    <fileNamePattern>${LOG_HOME}business-log-${APPLICATION_NAME}-${ROLLING_PATTERN}-%i.json</fileNamePattern>
    <maxFileSize>${BUSINESS_APPENDER_MAX_FILE_SIZE:-10MB}</maxFileSize>
    <totalSizeCap>${BUSINESS_APPENDER_TOTAL_SIZE_CAP:-50MB}</totalSizeCap>
    <maxHistory>${BUSINESS_APPENDER_MAX_HISTORY:-5}</maxHistory>
    <cleanHistoryOnStart>${BUSINESS_APPENDER_CLEAN_HISTORY_ON_START:-true}</cleanHistoryOnStart>
    <!-- 新增此行，调大索引最大值，可根据峰值日志量调整 -->
    <maxIndex>10000</maxIndex>
</rollingPolicy>

方案2：缩小单时间窗口的分片数量 #

如果你的ROLLING_PATTERN当前是分钟级，可以调整为更细粒度的时间窗口（比如到秒级yyyyMMdd-HHmmss），避免单个时间窗口内产生过多分片触达索引上限。

方案3：调整单文件大小阈值 #

如果业务允许，可以适当调大maxFileSize的数值，比如从10MB调整到20MB，减少相同日志量下的分片生成数量。

补充注意事项 #

如果日志量长期处于较高水平，建议同时配合OS层面的定时日志清理脚本做兜底，避免Logback自身逻辑异常导致磁盘打满。

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