Logback: SizeAndTimeBasedRollingPolicy non rispettando totalSizeCap

Question

Sto tentando di gestire il mio accesso in modo da eliminare i miei file di archivio archiviati più vecchi una volta raggiunto il limite di dimensioni cumulative totali o raggiunto il limite massimo di cronologia. Quando si utilizza lo SizeAndTimeBasedRollingPolicy in Logback 1.1.7, l'appender del file rolling continuerà a creare nuovi archivi nonostante superi il set totalSizeCap.

Ecco il mio file di logback.xml per riferimento:

<?xml version="1.0" encoding="UTF-8"?> 
<configuration> 
    <appender name="file" 
     class="ch.qos.logback.core.rolling.RollingFileAppender"> 

     <file>${USERPROFILE}/testlogs/test.log</file> 

     <rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy"> 
      <fileNamePattern> 
       ${USERPROFILE}/testlogs/%d{yyyy-MM-dd_HH}/test%i.log.zip 
      </fileNamePattern> 
      <maxHistory>7</maxHistory> 
      <maxFileSize>50KB</maxFileSize> 
      <totalSizeCap>200KB</totalSizeCap> 
     </rollingPolicy> 

     <encoder> 
      <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} %5p - %m%n</pattern> 
     </encoder> 

    </appender> 

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

È questo un bug in logback o non sono la configurazione del file appender di laminazione in modo corretto?

Answer 1

È un bug in Logback 1.1.7. Vedi: http://jira.qos.ch/browse/LOGBACK-1166

Ho controllato, totalSizeCap opere in Logback 1.1.8-SNAPSHOT.

Answer 2

Bene, anche la domanda è stata risolta, volevo postare il lavoro che abbiamo fatto fino a quando il bug è stato risolto in 1.1.8.

Il bug 1166 semplicemente non si applica totalSizeCap ai primi due unità di tempo, dipende dalla più piccola unità sul fileNamePattern che si sta utilizzando il che significa che per lo scenario non prenderà in considerazione i log delle prime due ore per totalSize capping.

La mia configurazione era in qualche modo simile agli esempi di siti di logback;

<rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> 
    <!-- daily rollover --> 
    <fileNamePattern>logFile.%d{yyyy-MM-dd}.log</fileNamePattern> 

    <!-- keep 30 days' worth of history capped at 3GB total size --> 
    <maxHistory>30</maxHistory> 
    <totalSizeCap>3GB</totalSizeCap> 

</rollingPolicy> 

Così abbiamo semplicemente passato da {yyyy-MM-dd} a {YYYY-MM-dd_HH} e ovviamente massimizzato l'maxHistory a 30 * 24. Così abbiamo fatto l'ultimo due ore s per non essere limitato invece di negli ultimi due giorni e per il nostro caso era omissibile. Naturalmente, i file di registro inizieranno a rollover in ogni ora, ma come ho detto è stato ok per il nostro caso unico.