logback：SizeAndTimeBasedRollingPolicy不删除4位“％i”的文件

Question

我们在产品中使用SizeAndTimeBasedRollingPolicy / SizeAndTimeBasedFNATP（logback 1.1.3）。这是从logback配置文件中剪切：

<appender name="SERVER_FILE"
    class="ch.qos.logback.core.rolling.RollingFileAppender">
    <file>${MY_LOGS}/myabc.log</file>
    <append>true</append>
    <!-- 
        Roll log file on both time (per day) and size (250mb). Gzip on roll.
    -->
    <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
        <!-- location and name of rolled log files -->
        <fileNamePattern>${MY_LOGS}/myabc-%d{yyyy-MM-dd}.%i.gz</fileNamePattern>
        <!-- keep 30 days worth of history -->
        <maxHistory>30</maxHistory>
        <timeBasedFileNamingAndTriggeringPolicy
            class="ch.qos.logback.core.rolling.SizeAndTimeBasedFNATP">
            <!-- whenever the file size reaches 250MB, roll it -->
            <maxFileSize>250MB</maxFileSize>
        </timeBasedFileNamingAndTriggeringPolicy>
    </rollingPolicy>
    <encoder>
        <pattern>%d{yyyy-MM-dd'T'HH:mm:ss.SSS} [%thread] %-5level %logger{24} [%C{1}.%M]</pattern>
    </encoder>
</appender>

生成的日志文件具有以下名称：myabc-2016-11-21.0.gz，myabc-2016-11-21.1.gz，myabc-2016-11-21.2.gz等。

问题是如果日志文件的扩展名（％i）超过3位数，则30天后它不会被删除（maxHistory）。例如，myabc-2016-11-21.0.gz会在30天后被删除，但myabc-2016-11-21.1000.gz不会被删除。

是否有任何其他appender /配置我需要添加到logback配置文件中以确保删除超过3位数的文件也会被删除或者它是否是logback中的错误？

[我尝试过使用logback 1.1.7，但这没有帮助]

Answer 1

我有同样的问题，看了回溯源代码（版本1.2.3）

package - ch.qos.logback.core.rolling.helper

并找到了这条线buf.append("(\\d{1,3})");

因此它被硬编码为1-3位整数，其中1000超过此间隔，索引超过1000的新日志文件不会替换旧的日志文件，而是继续附加到文件系统。

Answer 2

这是logback中的一个错误。这是jira，这是建议的修复（PR）。

Answer 3

此问题已在1.3.0-alpha1中修复 你可以在这里查看提交

https://github.com/qos-ch/logback/commit/f264607fb450

他们改变了

buf.append("(\\d{1,3})");

至

buf.append("(\\d+)");

和这里的官方新闻 https://logback.qos.ch/news.html

TimeBasedArchiveRemover现在能够处理超过999的索引。这修复了Diego Furtado报告的LOGBACK-1175，他也提供了相关的PR。