Log4j Filepattern не работает при срабатывании SizeBasedTriggeringPolicy - PullRequest
Новая
       14

Log4j Filepattern не работает при срабатывании SizeBasedTriggeringPolicy

0 голосов
/ 14 апреля 2020

У нас есть проблемы с нашей конфигурацией log4j2, которую мы взяли почти напрямую из https://www.baeldung.com/java-logging-rolling-file-appenders раздела 4.4: 

<RollingFile name="roll-by-time-and-size"
  fileName="target/log4j2/roll-by-time-and-size/app.log"
  filePattern="target/log4j2/roll-by-time-and-size/app.%d{MM-dd-yyyy-HH-mm-ss.SSS}.%i.log.gz"
  ignoreExceptions="false">
    <PatternLayout>
        <Pattern>%d{yyyy-MM-dd HH:mm:ss} %p %m%n</Pattern>
    </PatternLayout>
    <Policies>
        <SizeBasedTriggeringPolicy size="5 KB" />
        <TimeBasedTriggeringPolicy interval="5000000" />
    </Policies>
    <DefaultRolloverStrategy>
        <Delete basePath="." maxDepth="2">
            <IfFileName glob="target/log4j2/roll-by-time-and-size/app.*.log.gz" />
            <IfLastModified age="20d" />
        </Delete>
    </DefaultRolloverStrategy>
</RollingFile>

Если я уменьшу интервал, чтобы убедиться, что он Скользя на основе времени, это помещает правильное текущее время в имя файла. Но если я увеличу интервал до 5000 или чего-то еще и позволю попадать в SizeBasedTriggeringPolicy, отметка времени будет всегда одинаковой, и единственное, что изменяется в индексе в конце файла.

Это проблема для нас, потому что у нас есть задача cron, которая перемещает и переносит файлы в удаленную точку монтирования. Это означает, что в следующий раз, когда log4j достигнет политики запуска, основанной на размере, индекс будет сброшен до 1, отметка времени в имени файла будет такой же, даже если это не должно быть (почему ??), и наша задача cron попытается переместиться файл, но это будет то же имя файла, что и другой файл, который он уже переместил.

Использование последней версии весеннего загрузочного стартера log4j2 (на данный момент)

Это ошибка или предполагаемое поведение. Это не имеет особого смысла как предполагаемое поведение, но если так, что мы должны сделать, чтобы решить эту проблему?

1 Ответ

1 голос
/ 24 апреля 2020

Кажется, что политики работают так, как указано в документации. Я протестировал его в приложении Spring Boot 2.2.6.RELEASE с: 

<dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-log4j2</artifactId>
</dependency>

Затем я использовал следующие зависимости вместо стартера, чтобы убедиться, что я использую последние версии: 

<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-jcl</artifactId>
    <version>5.2.5.RELEASE</version>
</dependency>
<dependency>
    <groupId>org.apache.logging.log4j</groupId>
    <artifactId>log4j-api</artifactId>
    <version>2.13.2</version>
</dependency>
<dependency>
    <groupId>org.apache.logging.log4j</groupId>
    <artifactId>log4j-core</artifactId>
    <version>2.13.2</version>
</dependency>

В обоих случаях Политика запуска на основе размера изменяет метку времени в именах файлов только при использовании без Политики запуска на основе времени.

Из документации :

В сочетании с политикой запуска по времени шаблон файла должен содержать% i, иначе целевой файл будет перезаписываться при каждом переключении, поскольку политика запуска SizeBased не приведет к изменению значения метки времени в имени файла. , При использовании без политики, основанной на времени, политика запуска по размеру будет вызывать изменение значения метки времени.

Каждый раз, когда политика TimeBasedTriggering запускает ролловер, создается файл с новой меткой времени в своем имени. При следующем обращении к Политике запуска SizeBased она использует метку времени из последнего файла и изменяет только часть% i.

Поскольку вы не можете изменить способ, которым Политика SizeBasedTriggerin определяет индекс, кажется, что единственным очевидным решением является изменение задания cron, чтобы не перемещать файл с последней отметкой времени и индексом . Этого должно быть достаточно, чтобы решить вашу проблему.

...