Блог

Мы используем 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, чтобы убедиться, что файлы с расширением более 3 цифр также удаляются, или это ошибка в logback?

[Я пробовал с logback 1.1.7, но это не помогло]

У меня такая же проблема, посмотрел исходный код logback (версия 1.2.3)

пакет — ch.qos.logback.core.rolling.помощник

и нашел эту строку buf.append("(\d{1,3})");

таким образом, он жестко закодирован в 1-3-значное целое число, где 1000 превышает этот интервал, и новые файлы журналов с индексом более 1000 не заменяют старые, а продолжают добавляться к файловой системе.

Это ошибка в logback. Вот jira и вот предлагаемое исправление (PR).

Эта проблема уже исправлена в 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. Это исправляет LOGBACK-1175, о котором сообщил Диего Фуртадо, который также предоставил соответствующий PR.