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不会被删除。

我是否需要添加到logback配置文件中的其他appender /配置，以确保删除超过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。

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

3 个答案: