登录:SizeAndTimeBasedRollingPolicy将totalSizeCap应用于maxHistory中的每一天 [英] Logback: SizeAndTimeBasedRollingPolicy applies totalSizeCap to each day in maxHistory

查看:569
本文介绍了登录:SizeAndTimeBasedRollingPolicy将totalSizeCap应用于maxHistory中的每一天的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

登录版本1.2.3

我想在我们的Logback配置文件(logback.xml)中使用SizeAndTimeBasedRollingPolicy,但是此时SizeAndTimeBasedRollingPolicy无法正常运行. ( https://logback.qos.ch/manual/appenders.html#SizeAndTimeBasedRollingPolicy)

I want to use a SizeAndTimeBasedRollingPolicy in our logback configuration file (logback.xml), but at this time the SizeAndTimeBasedRollingPolicy doesn't function as expected. (https://logback.qos.ch/manual/appenders.html#SizeAndTimeBasedRollingPolicy)

理想情况下,我希望保留日志的日期不迟于ex. 90天,每个文件不超过100MB,存档总大小为ex.总共10GB.

Ideally I want to keep logs dating back no later than ex. 90 days, each file no larger than 100MB and a total archive size of ex. 10GB in total.

目前,totalSizeCap应用于MaxHistory范围内的每个条目. 例

As it currently stands, the totalSizeCap is applied to each entry within the MaxHistory range. Ex.

<appender name="ROLLING" class="ch.qos.logback.core.rolling.RollingFileAppender">
    <file>mylog.txt</file>
    <rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy">
      <!-- rollover daily -->
      <fileNamePattern>mylog-%d{yyyy-MM-dd}.%i.txt</fileNamePattern>
       <!-- each file should be at most 100MB, keep 60 days worth of history, but at most 20GB -->
       <maxFileSize>100MB</maxFileSize>    
       <maxHistory>60</maxHistory>
       <totalSizeCap>1GB</totalSizeCap>
    </rollingPolicy>
    <encoder>
      <pattern>%msg%n</pattern>
    </encoder>
</appender>

上面的XML配置将创建跨越60天的日志,每天应用1GB的totalSizeCap.这将导致总存档大小为60GB,而不是预期的1GB.如果在一天中达到了totalSizeCap,则当天的日志将通过删除当天最旧的文件而开始翻转,这将在日志历史记录中造成间隙,这是我们所不希望的.解决此错误的方法是使用每年的滚动,而不是每天或每月的滚动,不幸的是,在使用SizeAndTimeBasedRollingPolicy时,每年的滚动不起作用.

The above XML configuration will create logs spanning over 60 days, applying a totalSizeCap of 1GB per day. This will lead to a total archive size of 60GB instead of the expected 1GB. If the totalSizeCap is reached during the day the day's logs will start to rollover by deleting the day's oldest files, this will create gaps within the log history, which we don't want. A work-around for this error was to use a yearly rollover, instead of daily or monthly rollover, unfortunately yearly rollover doesn't work when using a SizeAndTimeBasedRollingPolicy.

有人知道这个问题吗,这个问题已经解决,还是我在配置中做错了什么?

Does anyone know of this problem, has this been fixed, or am I doing something wrong in my configuration?

推荐答案

似乎您发现了一个错误!

It seems that you have found a bug!

日志中不应有任何空白.当达到totalSizeCap时,应删除最早的日志文件.当达到maxHistory时,应删除最早的日志文件.

There should be no gaps in the logs. When totalSizeCap is reached, the oldest log file should be deleted. When maxHistory reached, the oldest log file should be deleted.

不幸的是,由于未删除最早的文件,因此似乎在logback中存在一个错误,该错误会导致日志记录出现间隔.在此处查看演示: https://github.com/riskop/slf4j_logback_SizeAndTimeBasedRollingPolicy_problem

Unfortunately it seems that there is a bug in logback which causes gaps in the logging because not the oldest files are deleted. See demonstration here: https://github.com/riskop/slf4j_logback_SizeAndTimeBasedRollingPolicy_problem

我已经打开一个问题: https://jira.qos.ch/browse/LOGBACK-1361

I've opened an issue: https://jira.qos.ch/browse/LOGBACK-1361

根据Gülcü,它将在经典的logback 1.3.0中修复.

According to Gülcü it will be fixed in logback classic 1.3.0.

请注意,您可以在Logback的Jira上投票"该问题!

Note that you can "vote" the issue on logback's Jira!

这篇关于登录:SizeAndTimeBasedRollingPolicy将totalSizeCap应用于maxHistory中的每一天的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆