Возврат в систему: опрокидывание не удаляет журналы с истекшим сроком действия

#logback

#возврат к журналу

Вопрос:

У меня RollingFileAppender есть архивирование журналов в файлы, подобные этому:
/data/work/logs/printPDF/logs/service/printPDF_2020-01/printPDF_2020-01-23_0.log.gz

К сожалению, он не удаляет старые архивы (как тот, который указан выше).

Кто-нибудь знает, что я делаю не так?

Ниже приведен отрывок из вывода консоли Startup Logback:

 - setting totalSizeCap to 20 GB
- Archive files will be limited to [100 MB] each.
- Will use gz compression
- Will use the pattern /data/work/logs/printPDF/logs/service/printPDF_%d{yyyy-MM, aux}/printPDF_%d{yyyy-MM-dd}_%i.log for the active file
- The date pattern is 'yyyy-MM-dd' from file name pattern '/data/work/logs/printPDF/logs/service/printPDF_%d{yyyy-MM, aux}/printPDF_%d{yyyy-MM-dd}_%i.log.gz'.
- Roll-over at midnight.
- Setting initial period to Tue Nov 10 05:31:17 MET 2020
- Cleaning on start up
- Assuming default type [ch.qos.logback.classic.encoder.PatternLayoutEncoder] for [encoder] property
- first clean up after appender initialization
- Multiple periods, i.e. 32 periods, seem to have elapsed. This is expected at application start.
- Active log file name: /data/work/logs/printPDF/printPDF.log
- File property is set to [/data/work/logs/printPDF/printPDF.log]
  

Как вы можете видеть из вывода консоли, он распознал шаблон ежедневных дат и ожидает опрокидывания в полночь.

Он завершается в полночь, но журналы с истекшим сроком действия не удаляются. Вот несколько имен файлов, которые не удалось удалить:

 /data/work/logs/printPDF/logs/service/printPDF_2020-01/printPDF_2020-01-23_0.log.gz
/data/work/logs/printPDF/logs/service/printPDF_2020-01/printPDF_2020-01-23_1.log.gz
/data/work/logs/printPDF/logs/service/printPDF_2020-02/printPDF_2020-02-28_0.log.gz
  

И вот тот, который он только что создал в полночь:

 /data/work/logs/printPDF/logs/service/printPDF_2020-11/printPDF_2020-11-10_0.log.gz
  

Вот logback.xml , который я рассчитываю сохранить на 90 дней:

 <configuration debug="true">
    <property name="SERVICE"  value="printPDF" />
    <property name="LOGDIR"   value="/data/work/logs/${SERVICE}" />

    <appender name="STDOUT"   class="ch.qos.logback.core.ConsoleAppender">
        <encoder>
            <pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern>
        </encoder>
    </appender>

    <appender name="RollingFile" class="ch.qos.logback.core.rolling.RollingFileAppender">
        <file>${LOGDIR}/${SERVICE}.log</file>
        <append>true</append>
        <rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy">
            <FileNamePattern>${LOGDIR}/logs/service/${SERVICE}_%d{yyyy-MM, aux}/${SERVICE}_%d{yyyy-MM-dd}_%i.log.gz</FileNamePattern>
            <maxHistory>90</maxHistory>
            <maxFileSize>100MB</maxFileSize>
            <totalSizeCap>20GB</totalSizeCap>
            <cleanHistoryOnStart>true</cleanHistoryOnStart>
        </rollingPolicy>
        <encoder>
            <Pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</Pattern>
        </encoder>
    </appender>

    <logger name="org.apache"     level="ERROR"/>
    <logger name="ch.qos.logback" level="INFO"/>

    <root level="INFO">
        <appender-ref  ref="STDOUT"/>
        <appender-ref  ref="RollingFile"/>
    </root>
</configuration>
  

Ответ №1:

вы используете ежемесячный ролловер: «%d{гггг-ММ}», поэтому maxhistory = 3 будет хранить журналы за три месяца.

Комментарии:

1. Извините, я обнаружил аргумент «aux» и исправил свой XML, но отредактировал публикацию выше вручную и ошибся. Теперь я опубликовал фактический используемый XML, в котором используется %d{гггг-ММ-дд}