Description

Hi,
The rationale behind this request is that there is no way to limit the history of log files generated by the app causing a continuos increase of the storage needs. This can be really problematic for an uncountable number of cases.

Currently this setting:
quarkus.log.file.rotation.max-backup-index=n
sets the number of n files with the same suffix but it does not limit the history of files kept in the file system or the total size.

What I would propose is a mechanism that additionally can limit the history given in days and a size cap on the log directory.

Thank you

Implementation ideas

I pretty much like the idea how Logback worked out the issue with this descriptor of the FILE appender. I think it is very self-explanatory.

<appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
		<file>${LOG_ROOT}/${LOG_FILE_NAME}.log</file>
		<rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy">
			<fileNamePattern>${LOG_ROOT}/${LOG_FILE_NAME}-%d{yyyy-MM-dd}.%i.log.gz</fileNamePattern>
			<!-- each archived file's size will be max 10MB -->
			<maxFileSize>10MB</maxFileSize>    
			<!-- 30 days to keep -->
			<maxHistory>30</maxHistory>
			<!-- total size of all archive files, if total size > 100GB, it will delete old archived file -->
			<totalSizeCap>100GB</totalSizeCap>
		</rollingPolicy>
		<encoder>
			<pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern>
		</encoder>
	</appender>

So, very cool, there is a total cap of the used storage. It keeps tidy the history in days and it limits also the file size. Basically Quarkus now implements the first option of the above descriptor with the backup index.
If the total cap size is reached, then deletes the older files. If the total cap is not reached then deletes the older flle in the history.
I hope this make some sense to you.