Why is my logback rolling policy keeping more than maxHistory files?
When using a TimeBasedRollingPolicy in Logback, it seems to be fairly common that it doesn’t operate as expected. One setting in particular seems to be a bit misleading — maxHistory.
For example, consider the following policy:
<rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
<fileNamePattern>/logs/api-%d{yyyy-MM-dd}.%i.log.json.gz
</fileNamePattern>
<timeBasedFileNamingAndTriggeringPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedFNATP">
<maxFileSize>10MB</maxFileSize>
</timeBasedFileNamingAndTriggeringPolicy>
<maxHistory>10</maxHistory>
</rollingPolicy>The expectation seems to be that:
- the log will roll at the end of the day (correct)
- the log will roll if it reaches 10MB in size (correct)
- only 10 historical log files will be retained (NOT correct)
This is a *Time*BasedRollingPolicy, and maxHistory does not apply to the number of log files. It applies to the amount of time for which log files will be retained. The documentation is a bit misleading, especially if you have a short attention span. It states:
The optional maxHistory property controls the maximum number of archive files to keep, asynchronously deleting older files.
So… a maxHistory of 10 should mean that 10 is the maximum number of archive files to keep… right? Well, no. Keep reading the next sentence:
For example, if you specify monthly rollover, and set maxHistory to 6, then 6 months worth of archives files will be kept with files older than 6 months deleted.
Perhaps “controls the maximum number of archive files to keep” should be replaced with “controls how long archive files are kept”.
To avoid a misbehaving application from filling up all of your disk capacity, please consider also specifying the totalSizeCap setting as well, which the documentation describes as follows:
The optional totalSizeCap property controls the total size of all archive files.
Alternatively, there is SizeAndTimeBasedRollingPolicy that you could consider.
