Logback: SizeAndTimeBasedRollingPolicy применяет totalSizeCap к каждому дню в maxHistory

Логбэк версии 1.2.3

Я хочу использовать SizeAndTimeBasedRollingPolicy в нашем файле конфигурации журнала (logback.xml), но в настоящее время SizeAndTimeBasedRollingPolicy не работает должным образом. (https://logback.qos.ch/manual/appenders.html#SizeAndTimeBasedRollingPolicy)

В идеале я хочу хранить журналы не позднее, чем ex. 90 дней, размер каждого файла не более 100 МБ и общий размер архива напр. всего 10гб.

В настоящее время totalSizeCap применяется к каждой записи в пределах диапазона MaxHistory. Бывший.

<appender name="ROLLING" class="ch.qos.logback.core.rolling.RollingFileAppender">
    <file>mylog.txt</file>
    <rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy">
      <!-- rollover daily -->
      <fileNamePattern>mylog-%d{yyyy-MM-dd}.%i.txt</fileNamePattern>
       <!-- each file should be at most 100MB, keep 60 days worth of history, but at most 20GB -->
       <maxFileSize>100MB</maxFileSize>    
       <maxHistory>60</maxHistory>
       <totalSizeCap>1GB</totalSizeCap>
    </rollingPolicy>
    <encoder>
      <pattern>%msg%n</pattern>
    </encoder>
</appender>

Вышеупомянутая конфигурация XML будет создавать журналы, охватывающие более 60 дней, применяя totalSizeCap 1 ГБ в день. Это приведет к тому, что общий размер архива составит 60 ГБ вместо ожидаемого 1 ГБ. Если totalSizeCap будет достигнут в течение дня, дневные журналы начнут обновляться путем удаления самых старых файлов за день, это создаст пробелы в истории журналов, чего мы не хотим. Обходной путь для этой ошибки заключался в использовании ежегодного переноса вместо ежедневного или ежемесячного переноса, к сожалению, годовой перенос не работает при использовании SizeAndTimeBasedRollingPolicy.

Кто-нибудь знает об этой проблеме, это было исправлено, или я делаю что-то не так в своей конфигурации?


logging logback logback-classic
person Iggydv    schedule 11.12.2017    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Кажется, вы нашли ошибку!

В логах не должно быть пробелов. При достижении totalSizeCap самый старый файл журнала следует удалить. При достижении maxHistory самый старый файл журнала следует удалить.

К сожалению, похоже, что в журнале есть ошибка, которая вызывает пробелы в журнале, потому что удаляются не самые старые файлы. См. демонстрацию здесь: https://github.com/riskop/slf4j_logback_SizeAndTimeBasedRollingPolicy_problem

Я открыл задачу: https://jira.qos.ch/browse/LOGBACK-1361

По словам Гюльку, это будет исправлено в версии logback classic 1.3.0.

Обратите внимание, что вы можете «проголосовать» за проблему в журнале Jira!

person riskop    schedule 12.12.2017
comment
Хотя мне кажется, что это не так. Если я, например, установлю MaxHistory на 1 (1 день) и totalsizeCap на 1 ГБ, тогда будет сохранено примерно 1 ГБ файлов размером 100 МБ за предыдущий день. В течение следующего дня файлы предыдущего дня не удаляются, а приложение добавляет только файлы с текущей датой. Это выглядит примерно так: core-2017-12-12.01.log ... core-2017-12-12.10.log core-2017-12-13.03.log ... core-2017-12-13.13.log, поскольку вы можете видеть, что добавление переворачивается в сегодняшних файлах журнала, но оставляет все в maxHistory нетронутым - person Iggydv; 13.12.2017
comment
Я думаю, что могу воспроизвести вашу проблему, по крайней мере, когда интервал прокатки очень короткий (прокрутка выполняется каждую секунду). Мой тест находится здесь: github.com/riskop/ Не могли бы вы проверить его в своей среде? Я пробовал это на xubuntu 16, openjdk8. - person riskop; 15.12.2017
comment
Я создал задачу для входа в систему: jira.qos.ch/browse/LOGBACK-1361 - person riskop; 15.12.2017
comment
Большое спасибо за создание темы! - person Iggydv; 18.12.2017
comment
Есть ли шанс исправить это в ветке 1.2.x? - person Sergei Rodionov; 14.03.2019
comment
@SergeiRodionov: я думаю, тебе следует спросить Чеки - person riskop; 14.03.2019
comment
Это было бы последнее, что у меня на уме. Я не хочу возлагать дополнительную нагрузку на сопровождающих OSS. Просто проветрить... - person Sergei Rodionov; 14.03.2019