java Logback：SizeAndTimeBasedRollingPolicy 不遵守 totalSizeCap
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/37014221/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Logback: SizeAndTimeBasedRollingPolicy not honoring totalSizeCap
提问by Brady Goldman
I'm trying to manage my logging in a way in which my oldest archived logfiles are deleted once they've either reached the total cumulative size limit or reached their maximum history limit. When using the SizeAndTimeBasedRollingPolicyin Logback 1.1.7, the rolling file appender will keep creating new archives in spite of exceeding the totalSizeCapset.
我正在尝试以一种方式管理我的日志记录，即一旦我最旧的存档日志文件达到总累积大小限制或达到其最大历史记录限制，它们就会被删除。当使用SizeAndTimeBasedRollingPolicy中的logback 1.1.7，滚动文件附加目的地将继续，尽管超出的创造新的档案totalSizeCap集。
Here's my logback.xml file for reference:
这是我的 logback.xml 文件以供参考：
<?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>
Is this a bug in logback or am I not configuring the rolling file appender correctly?
这是 logback 中的错误还是我没有正确配置滚动文件附加程序？
采纳答案by Alykoff Gali
It's bug in Logback 1.1.7. See: http://jira.qos.ch/browse/LOGBACK-1166
这是 Logback 1.1.7 中的错误。见：http: //jira.qos.ch/browse/LOGBACK-1166
I have checked, totalSizeCapworks in Logback 1.1.8-SNAPSHOT.
我检查过，totalSizeCap适用于 Logback 1.1.8-SNAPSHOT。
回答by Guillotine1789
Well even the question is answered, I wanted to post the work around that we made until the bug is fixed in 1.1.8.
好吧，即使问题得到了回答，我也想发布我们所做的工作，直到该错误在 1.1.8 中得到修复。
The bug 1166simply does not apply totalSizeCapto the first two time units, depends on the smallest unit on the fileNamePattern you are using which means for your scenario it will not consider the logs of the first two hours for totalSize capping.
该漏洞1166根本不适用totalSizeCap前两个时间单位，取决于最小单位上正在使用的方式为您的方案不会考虑的前两个小时，总计TOTALSIZE封盖日志的fileNamePattern。
My configuration was somehow like so-taken from logback site examples-;
我的配置有点像从 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>
<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>
So we simply switched from {yyyy-MM-dd}to {yyyy-MM-dd_HH}and of course maximized the maxHistory to 30*24. Thus we made the last two hours not to be capped instead of last two daysand for our case it was omittable. Of course, the log files will start to rollover in every hour but as I said it was ok for our unique case.
所以我们简单地从{yyyy-MM-dd}切换到{yyyy-MM-dd_HH}并且当然将 maxHistory 最大化到30*24。因此，我们将最后两个小时设为没有上限，而不是最后两天，对于我们的案例，它是可省略的。当然，日志文件每隔一小时就会开始翻转，但正如我所说，这对于我们的独特情况来说是可以的。
