Question about SizeAndTimeBasedRollingPolicy
Hello all, I've got a question about the SizeAndTimeBasedRollingPolicy. What I would like to achieve is a guaranteed upper boundary for the disk space used by log files and archives. I was happy to find the related option "totalSizeCap" for SizeAndTimeBasedRollingPolicy which seemed to help, but it turns out that this cap is applied only to files older than the time-based rollover trigger (in my case, a new day). The same seems to be the case for "maxHistory", it doesn't constrain the count of files created on the current day. So it is possible that, in worst case, a lot of files are created and flush disk space. Are there any ideas how to solve that? I read about FixedWindowRollingPolicy, but I need day based rollover. Here's my non-working approach so far: <appender name="FILE_DEFAULT" class="ch.qos.logback.core.rolling.RollingFileAppender"> <file>events.log</file> <encoder><Pattern>${defaultPattern}</Pattern></encoder> <rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy"> <fileNamePattern>events_%d{yyyy-MM-dd}_%i.zip</fileNamePattern> <maxFileSize>1MB</maxFileSize> <maxHistory>5</maxHistory> <totalSizeCap>10MB</totalSizeCap> </rollingPolicy> </appender> I'm looking forward to any responses. Have a nice weekend! Simon Erhardt Senior Software Architect Befine Solutions AG - The Cryptshare company
Hi Simon, I think simply removing the "file" property will go a long way to a solution. -- Ceki On 4/8/2016 17:03, Simon.Erhardt@befine-solutions.com wrote:
Hello all,
I've got a question about the SizeAndTimeBasedRollingPolicy. What I would like to achieve is a guaranteed upper boundary for the disk space used by log files and archives. I was happy to find the related option "totalSizeCap" for SizeAndTimeBasedRollingPolicy which seemed to help, but it turns out that this cap is applied only to files older than the time-based rollover trigger (in my case, a new day). The same seems to be the case for "maxHistory", it doesn't constrain the count of files created on the current day. So it is possible that, in worst case, a lot of files are created and flush disk space.
Are there any ideas how to solve that? I read about FixedWindowRollingPolicy, but I need day based rollover. Here's my non-working approach so far:
<appender name="FILE_DEFAULT" class="ch.qos.logback.core.rolling.RollingFileAppender"> <file>events.log</file> <encoder><Pattern>${defaultPattern}</Pattern></encoder> <rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy"> <fileNamePattern>events_%d{yyyy-MM-dd}_%i.zip</fileNamePattern> <maxFileSize>1MB</maxFileSize> <maxHistory>5</maxHistory> <totalSizeCap>10MB</totalSizeCap> </rollingPolicy> </appender>
I'm looking forward to any responses. Have a nice weekend!
Simon Erhardt* *Senior Software Architect Befine Solutions AG - The Cryptshare company
_______________________________________________ logback-user mailing list logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
Hi Ceki, thank you for the fast reply. When I remove the file property, the currently active log file is named according to the fileNamePattern, but besides that, appearantly nothing changes. I still have archive files of today with a total size exceeding totalSizeCap. Any other ideas? Or do have to implement a custom rollingPolicy? Simon From: Ceki Gulcu <ceki@qos.ch> To: logback-user@qos.ch Date: 08.04.2016 20:04 Subject: Re: [logback-user] Question about SizeAndTimeBasedRollingPolicy Sent by: "logback-user" <logback-user-bounces@qos.ch> Hi Simon, I think simply removing the "file" property will go a long way to a solution. -- Ceki On 4/8/2016 17:03, Simon.Erhardt@befine-solutions.com wrote:
Hello all,
I've got a question about the SizeAndTimeBasedRollingPolicy. What I would like to achieve is a guaranteed upper boundary for the disk space used by log files and archives. I was happy to find the related option "totalSizeCap" for SizeAndTimeBasedRollingPolicy which seemed to help, but it turns out that this cap is applied only to files older than the time-based rollover trigger (in my case, a new day). The same seems to be the case for "maxHistory", it doesn't constrain the count of files created on the current day. So it is possible that, in worst case, a lot of files are created and flush disk space.
Are there any ideas how to solve that? I read about FixedWindowRollingPolicy, but I need day based rollover. Here's my non-working approach so far:
<appender name="FILE_DEFAULT" class="ch.qos.logback.core.rolling.RollingFileAppender"> <file>events.log</file> <encoder><Pattern>${defaultPattern}</Pattern></encoder> <rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy"> <fileNamePattern>events_%d{yyyy-MM-dd}_%i.zip</fileNamePattern> <maxFileSize>1MB</maxFileSize> <maxHistory>5</maxHistory> <totalSizeCap>10MB</totalSizeCap> </rollingPolicy> </appender>
I'm looking forward to any responses. Have a nice weekend!
Simon Erhardt* *Senior Software Architect Befine Solutions AG - The Cryptshare company
_______________________________________________ logback-user mailing list logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
_______________________________________________ logback-user mailing list logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
participants (2)
-
Ceki Gulcu -
Simon.Erhardt＠befine-solutions.com