Appender是负责写记录事件的组件。Appender 必须实现接口“ch.qos.logback.core.Appender”。该接口的重要方法总结以下:java
package ch.qos.logback.core; import ch.qos.logback.core.spi.ContextAware; import ch.qos.logback.core.spi.FilterAttachable; import ch.qos.logback.core.spi.LifeCycle; public interface Appender<E> extends LifeCycle, ContextAware, FilterAttachable { public String getName(); public void setName(String name); void doAppend(E event); }
Appender 接口里的多数方法都是 getter 和 setting。值得注意的是 doAppend()方法,它惟一的参数是类型E的对象。类型E的实际类型视 logback模块的不一样而不一样。在 logback-classic模块里,E 多是“ILoggingEvent”类型;在 logback-access 模块里,E 多是“AccessEvent”类型。doAppend()方法也许是 logback 框架里最重要的方法,它负责以适当的格式将记录事件输出到合适的设备。
Appender 是被命名的实体。由于有名字,因此能被引用。Appender 接口扩展了FilterAttachable 接口,所以 appender 实例可被关联一个或多个过滤器。
Appender 是最终负责输出记录事件的组件。然而,它们能够把实际格式化的任务委托给Layout或Encoder对象。每一个layout/encoder都关联到一个且仅一个appender。有些appender有内置的或固定的事件格式,所以它们不须要也没有 layout/encoder。例如,SocketAppender在发送记录事件以前只是简单地对其进行序列化。算法
类 ch.qos.logback.core.AppenderBase 是实现了 Appender 接口的抽象类。AppenderBase提供全部 appender 共享的基本功能,好比设置/获取名字的方法,其活动状态和过滤器。
AppenderBase 是 loback 里全部 appender 的超类。尽管是抽象类,AppenderBase 实际上实现了 Appender 接口的 doAppend()方法。代码更能说明问题:安全
public synchronized void doAppend(E eventObject) { // prevent re-entry. if (guard) { return; } try { guard = true; if (!this.started) { if (statusRepeatCount++ < ALLOWED_REPEATS) { addStatus(new WarnStatus( "Attempted to append to non started appender [" + name + "].", this)); } return; } if (getFilterChainDecision(eventObject) == FilterReply.DENY) { return; } // ok, we now invoke derived class' implementation of append this.append(eventObject); } catch (Exception e) { if (exceptionCount++ < ALLOWED_REPEATS) { addError("Appender [" + name + "] failed to append.", e); } } finally { guard = false; } }
这里的 doAppend()方法的实现是同步的,确保不一样线程对同一个 appender 的记录是线程安全的。
这里进行的同步并不老是合适的,logback 带了与 AppenderBase 很是类似的类ch.qos.logback.core.UnsynchronizedAppenderBase,以后会讨论它。
doAppend()方法作的第一件事就是检查“guard”是否为 true。若是是,则当即退出方法。
若是未设置“guard”,紧接下来的语句就把它设为 true。“guard”确保 doAppend()方法不会递归调用本身。
以后的语句里,咱们检查“started”字段是否为 true。若是不是,doAppend()会发出一条警告信息而后返回。换句话说,appender 一旦关闭后,就没法再向它写入。Appender 对象实现 LifeCycle 接口,意味着它们实现了 start()、stop()和 isStarted()方法。对 appender 的全部属性都设值后,Joran 调用 start()方法让 appender 激活本身的属性。Appender 也许会启动失败,好比由于找不到某些属性,或者由于不一样属性之间互相引用。例如,假设文件建立是截断模式,那么,FileAppender 在 Append 选项没肯定以前不能做用于 File 选项。这种显式激活步骤确保 appender 在属性值被肯定以后才能使用属性。
若是 appender 不能启动或者已经被中止,则会经过 logback 的内部状态管理系统发出一条警告消息。尝试几回后,为了不内部状态系统被同一条警告消息所淹没,doAppend()方法将中止发出这些警告消息。
接着的 if 语句检查关联的过滤器的结果。根据过滤器链的判断结果,事件被拒绝或接受。若是过滤器链没有结果,则事件被默认接受。
doAppend()方法而后调用派生类的append()方法,此方法真正把事件增长到合适的设备。
最后,释放 guard,容许下一个 doAppend()调用。
在本手册中,术语“选项(option)”或“属性(property)”表示用 JavaBeans 内省机制经过 setter 和 getter 方法动态引用的属性(attribute)。app
Logback-core 是其余 logback 模块的基础。通常来讲,logback-core 里的模块须要一些细微的定制。不过在下面的几节理里,咱们将讲述几个直接可使用的 appender。框架
OutputStreamAppender 把事件添加到 java.io.OutputStream。该类提供其余 appender 所需的基本服务。用户一般不直接实例化 OutputStreamAppender 对象。因为 java.io.OutputStream通常没法被方便地映射到字符串,因此没法在配置文件里指定目标 OutputStream 对象。简而言之,你不能在配置文件里配置 OutputStreamAppender。但这不是说 OutputStreamAppender没有配置属性。它的属性以下。工具
属性名 | 类型 | 描述 |
encoder | Encoder | 决定把事件写入到底层 OutputStreamAppender 的方式。 |
OutputStreamAppender 是另外三个 appender 的超类:ConsoleAppender、FileAppender及其直接子类 RollingFileAppender。下图演示了 OutputStreamAppender 和其子类的类图。
性能
ConsoleAppender把事件添加到控制台,更准确地说是System.out或 System.err,默认为前者。ConsoleAppender按照用户指定的encoder对事件进行格式化。System.out和System.err都是 java.io.PrintStream 类型,所以,它们被包裹在有缓冲 I/O 操做的 OutputStreamWriter 里。学习
属性名 | 类型 | 描述 |
encoder | Encoder | 参见 OutputStreamAppender 属性 |
target | String | 字 符 串 “ System.out ” 或 “ System.err ”。 默 认 为“System.out”。 |
下面是使用 ConsoleAppender 的配置示例。
示例:ConsoleAppender 配置
(logback-examples/src/main/java/chapters/appenders/conf/logback-Console.xml)this
<configuration> <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> <!--encoders are assigned the type ch.qos.logback.classic.encoder.PatternLayoutEncoder by default--> <encoder> <pattern>%-4relative [%thread] %-5level - %msg%n</pattern> </encoder> </appender> <root level="DEBUG"> <appender-ref ref="STDOUT" /> </root> </configuration>
FileAppender 是 OutputStreamAppender 的子类,把记录事件添加到文件。目标文件经过File 选项指定。若是文件已经存在,则根据 Append 属性追加或清空文件。操作系统
属性名 | 类型 | 描述 |
append | boolean | 若是 true,事件被追加到现存文件尾部。若是 false,清空现存文件。默认为 true。 |
encoder | Encoder | 参见 OutputStreamAppender 属性file String 被写入的文件名。若是文件不存在,则建立之。没有默认值。若是文件的父目录不存在,FileAppender 会自动建立各级不存在的目录。 |
prudent | boolean | 在 prudent 模式下,FileAppender 将安全地写入指定文件,即便其余 FileAppender 实例运行在不一样 JVM 上,好比运行在不一样主机上。prudent 默认值为 false。prudent 模式意味着 Append 属性自动设为 true。prudent 模式写记录事件时,大约消耗非 prudent 模式的三倍。在一台“普通”的 PC 上,向本地硬盘写文件,写一条记录事件,非 prudent 模式须要 10 微妙,prudent模式须要 30 微妙。也就是非 prudent 模式每秒记录100000 条事件,prudent 模式每秒 33000 条。不一样 JVM 写入同一个文件时,prudent 模式高效地排列 I/O 操做。因此,因为访问文件的 JVM 的数量增长,致使每次 I/O 操做都会有延迟。只要 I/O 操做的总数大约是 20 次记录请求/秒,就能够忽略对性能的影响。每秒 100 次或等屡次 I/O 操做会影响性能,此时应当避免prudent 模式。prudent 模式能够与 RollingFileAppender 联合使用,但有些限制。 |
下面是 FileAppender 的配置文件例子。
示例:FileAppender 配置
(logback-examples/src/main/java/chapters/appenders/conf/logback-fileAppender.xml)
<configuration> <appender name="FILE" class="ch.qos.logback.core.FileAppender"> <file>testFile.log</file> <append>true</append> <!-- encoders are assigned the type ch.qos.logback.classic.encoder.PatternLayoutEncoder by default --> <encoder> <pattern>%-4relative [%thread] %-5level %logger{35} - %msg%n </pattern> </encoder> </appender> <root level="DEBUG"> <appender-ref ref="FILE" /> </root> </configuration>
在程序开发期,或对于短生命期程序如批量程序,能够在个新程序启动时建立新记录文件。用
示例:用时间戳实现名称惟一的 FileAppender
(logback-examples/src/main/java/chapters/appenders/conf/logback-timestamp.xml)
<configuration> <!-- Insert the current time formatted as "yyyyMMdd'T'HHmmss" under the key "bySecond" into the logger context. This value will be available to all subsequent configuration elements. --> <timestamp key="bySecond" datePattern="yyyyMMdd'T'HHmmss" /> <appender name="FILE" class="ch.qos.logback.core.FileAppender"> <!-- use the previously created timestamp to create a uniquely named log file --> <file>log-${bySecond}.txt</file> <encoder> <pattern>%logger{35} - %msg%n</pattern> </encoder> </appender> <root level="DEBUG"> <appender-ref ref="FILE" /> </root> </configuration>
timestamp 元素有两个属性:key 和 datePattern。属性 key 是变量名,对余下的配置元素可用。属性 datePattern 表示把当前时间(解析配置文件的时间)转换成字符串时使用的日期模式,听从 java.text.SimpleDateFormat 里的约定。
RollingFileAppender 继承 FileAppender,可以滚动记录文件。例如,RollingFileAppender能先记录到文件“log.txt”,而后当符合某个条件时,变成记录到其余文件。RollingFileAppender 有两个与之互动的重要子组件。第一个是 RollingPolicy,负责滚动。
第二个是 TriggeringPolicy,决定是否以及什么时候进行滚动。因此,RollingPolicy 负责“什么”,TriggeringPolicy 负责“什么时候”。
要想 RollingFileAppender 起做用,必须同时设置 RollingPolicy 和 TriggeringPolicy。不过,若是 RollingPolicy 也实现了 TriggeringPolicy 接口,那么只须要设置 RollingPolicy。
下面是 RollingFileAppender 的可用属性。
属性名 | 类型 | 描述 |
file | String | 参加 FileAppender 属性 |
append | boolean | 参加 FileAppender 属性 |
encoder | Encoder | 参见 OutputStreamAppender 属性 |
rollingPolicy | RollingPolicy | 当发生滚动时,决定 RollingFileAppender 的行为。 |
triggeringPolicy | TriggeringPolicy | 告知 RollingFileAppender 什么时候激活滚动。 |
prudent | boolean | prudent 模式下不支持 FixedWindowRollingPolicy。RollingFileAppender 支 持 prudent与TimeBasedRollingPolicy 的联合使用,但有两个限制:1. 在 prudent 模式,不支持也不容许文件压缩(不能在一个 JVM 压缩文件时,让另外一个 JVM 写文件)。2. 不能设置 FileAppender 的 file 属性,必须留空。实际上,多数操做系统不容许当一个进程打开文件时又重命名该文件。参加 FileAppender 属性。 |
RollingPolicy 负责滚动步骤,涉及文件移动和重命名。
RollingPolicy 接口以下:
package ch.qos.logback.core.rolling; import ch.qos.logback.core.FileAppender; import ch.qos.logback.core.rolling.helper.CompressionMode; import ch.qos.logback.core.spi.LifeCycle; public interface RollingPolicy extends LifeCycle { public void rollover() throws RolloverFailure; public String getActiveFileName(); public CompressionMode getCompressionMode(); public void setParent(FileAppender appender); }
rollover 方法完成对当前记录文件的归档工做。getActiveFileName()方法计算当前记录文件(写实时记录的地方)的文件名。如 getCompressionMode()方法名所示,RollingPolicy 也负责决定压缩模式。最后,RollingPolicy 经过 setParent()方法获得一个对其父的引用。
当发生滚动时,FixedWindowRollingPolicy 根据以下固定窗口(window)算法重命名文件。
选项“fileNamePattern”表明归档(滚动)记录文件的文件名模式。该选项是必需的,且必需在模式的某处包含标志“%i”。
下面是 FixedWindowRollingPolicy 的可用属性。
属性名 | 类型 | 描述 |
minIndex | int | 窗口索引的最小值 |
maxIndex | int | 窗口索引的最大值 |
fileNamePattern | String | 例如,对于最小值和最大值分别是 1 和 3 的文件名模式“MyLogFile%i.log”,会产生归档文件 MyLogFile1.log、MyLogFile2.log 和 MyLogFile3.log。该 属 性 还 可 以 指 定 文 件 压 缩 选 项 。 例 如“MyLogFile%i.log.zip”表示归档文件必须用 zip 格式进行压缩;还支持“.gz”格式。 |
因为固定窗口滚动策略须要的文件重命名操做与窗口大小同样多,因此强烈建议不要使用太大的窗口大小。当用户指定过大的窗口大小时,当前的代码会自动将窗口大小设为 12。让咱们来看固定窗口滚动策略的一个更具体的例子。假设“minIndex”是 1, “maxIndex”是 3,“fileNamePatter”是“foo%i.log”。
滚动文件数量 | 活动输出 |
0 | foo.log |
1 | foo.log |
2 | foo.log |
3 | foo.log |
4 | foo.log |
下面的配置文件演示了 RollingFileAppender 和 FixedWindowRollingPolicy。注意“file”选项是必需的,即便它与“fileNamePattern”选项有部分重叠信息。
示例:使用 FixedWindowRollingPolicy 的 RollingFileAppender 的示例配置
(logback-examples/src/main/java/chapters/appenders/conf/logback-RollingFixedWindow.xml)
<configuration> <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender"> <file>testFile.log</file> <rollingPolicy class="ch.qos.logback.core.rolling.FixedWindowRollingPolicy"> <fileNamePattern>testFile.%i.log.zip</fileNamePattern> <minIndex>1</minIndex> <maxIndex>3</maxIndex> </rollingPolicy> <triggeringPolicy class="ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy"> <maxFileSize>5MB</maxFileSize> </triggeringPolicy> <encoder> <pattern>%-4relative [%thread] %-5level %logger{35} - %msg%n </pattern> </encoder> </appender> <root level="DEBUG"> <appender-ref ref="FILE" /> </root> </configuration>
TimeBasedRollingPolicy 或许是最受流行的滚动策略。它根据时间来制定滚动策略,例如 根 据 日 或 月 。TimeBasedRollingPolicy 既 负 责 滚 动 也 负 责 触 发 滚 动 。 实 际 上 ,TimeBasedRollingPolicy 同时实现了 RollingPolicy 接口和 TriggeringPolicy 接口。
TimeBasedRollingPolicy 有两个属性:必需的“fileNamePattern”和可选的“maxHistory”。
属性名 | 类型 | 描述 |
fileNamePattern | String | 必需。定义滚动(归档)记录文件的名字。其值应当包含文件名及“%d”格式转换符。“%d”能够包含一个java.text.SimpleDateFormat 指定的日期时间模式。若是没有指定日期时间模式,则默认为 yyyy-MM-dd。RollingFileAppender(TimeBasedRollingPolicy 之父)的“file”选项无关紧要。经过设置“file”属性,能够为活动文件和归档文件指定不一样的位置。当前记录老是被指向由“file”属性指定的文件。若是有“file”属性,则活动文件的名字不会改变。而若是没有“file”属性,则活动文件的名字会根据“fileNamePattern”的值每隔一段时间就从新计算一次。下面的例子会解释这点。“ %d{} ” 里 的 日 期 时 间 模 式 遵 循java.text.SimpleDateFormat 的约定。在 FileNamePattern或日期时间模式里的前置“/”或后置“”会被看成目录分隔符。 |
maxHistory | int | 控制被保留的归档文件的最大数量,超出数量就删除旧文件。例如,假设每个月滚动,且 maxHistory 是 6,则只保留最近 6 个月的归档文件,删除以前的文件。注意当删除旧归档文件时,那些为了归档而建立的目录也会被删除。 |
下面是 fileNamePattern 的部分值及其做用。
fileNamePattern | 滚动计划 | 示例 |
/wombat/foo.%d | 天天滚动(在午夜)。由于%d没有指定日期时间格式,因此使用默认的yyyy-MM-dd,即天天滚动。 | 未设置 file 属性:在 2006 年11 月 23 日,记录会输出到文件/wombat/foo.2006-11-23。在午夜及以后的 24 日,输出到文件/wombat/foo.2006-11-24。设 置 file 属 性 为/wombat/foo.txt:活动记录文件 总 是 /wombat/foo.txt.。 在2006 年 11 月 23 日,记录会输出到文件/wombat/foo.txt。在午夜,/wombat/foo.txt 被重命 名 为/wombat/foo.2006-11-23,建立新的/wombat/foo.txt,以后的24 日 , 输 出 到 文 件/wombat/foo.txt。 |
/wombat/%d{yyyy/MM}/foo.txt | 每个月初滚动 | 未设置 file 属性:在 2006 年10 月,记录会输出到文件/wombat/2006/10/foo.txt 。 在10 月 31 日午夜及 11 月,输出到文件/wombat/2006/11/foo.txt。设 置 file 属 性 为/wombat/foo.txt:活动记录文件 总 是 /wombat/foo.txt.。 在2006 年 10 月,记录会输出到文件/wombat/foo.txt。在 10月31 日午夜,/wombat/foo.txt被 重 命 名 为/wombat/2006/10/foo.txt,建立新的/wombat/foo.txt,以后的1 个 月 , 输 出 到 文 件/wombat/foo.txt。在 11 月 30日的午夜,/wombat/foo.txt 被重 命 名 为/wombat/2006/11/foo.txt,依此类推 |
/wombat/foo.%d{yyyy-ww}.log | 每周初滚动。 | 注意每周的第一天是星期几取 决 于 地 区(locale)同前,只是滚动发生在每周的开头。 |
/wombat/foo.%d{yyyy-MM-dd_HH}.log | 每小时滚动 | 同前,只是滚动发生在每小时的开头 |
/wombat/foo.%d{yyyy-MM-dd_HH-mm}.log | 每分钟滚动 | 同前,只是滚动发生在每分钟的开头。 |
全部“”和“/”都被解释为目录分隔符。任何须要的目录都会被建立。因此你能够轻松地把记录文件放到不一样的目录。
正如 FixedWindowRollingPolicy,TimeBasedRollingPolicy 支持自动压缩文件。若是“fileNamePattern”选项以“.gz”或“.zip”结尾,就表示须要压缩。
属性名 | 类型 | 描述 |
/wombat/foo.%d.gz | 天天滚动(在午夜),归档文件被自动压缩为GZIP 文件。 | 未设置 file 属性:在 2006 年 11 月 23 日,记录会输出到 文 件 /wombat/Foo.2006-11-23 。 在 午 夜 ,/wombat/foo.txt 被压缩为/wombat/foo.2009-11-23.gz,以后的 24 日,输出到文件/wombat/foo.2006-11-24。设置 file 属性为/wombat/foo.txt:活动记录文件老是/wombat/foo.txt.。在 2006 年 11 月 23 日,记录会输出到 文 件 /wombat/foo.txt 。 在 午 夜 , 在 午 夜 ,/wombat/foo.txt 被压缩为/wombat/foo.2009-11-23.gz,建立新的/wombat/foo.txt,以后的 24 日,输出到文件/wombat/foo.txt。 |
属性“fileNamePattern”有两个目的。一是,经过学习模式,logback 计算滚动周期。二是,计算每一个归档文件的名称。注意,能够为两种不一样的模式指定同一个周期。模式 yyyy-MM和 yyyy@MM 都表示每个月滚动,但它们的归档文件名不一样。
经过设置“file”属性,你能够为活动记录文件和归档记录文件指定不一样的位置。记录输出会被指向“file”属性指定的文件,因此活动文件的名字不会改变。然而,若是没有“file”
属性,则活动文件的名字会根据“fileNamePattern”的值每隔一段时间就从新计算一次。
属性“maxHistory”控制被保留的归档文件的最大数量,超出数量就删除旧文件。例如,假设每个月滚动,且 maxHistory 是 6,则只保留最近 6 个月的归档文件,删除以前的文件。注意当删除旧归档文件时,那些为了归档而建立的目录也会被删除。
出于某些技术缘由,滚动不是时钟驱动,而是按照记录事件的到达时间。好比,在 2002年 3 月 8 日,假设“fileNamePattern”是“yyyy-MM-dd”(每日滚动),则午夜事后的第一个记录事件会触发滚动。若是,好比说直到 0 点 23 分 47 秒以前都没有记录事件,那么滚动发生的实际时间是 3 月 9 日 0 点 23 分 47 秒,而不是 0 点 0 分。所以,根据事件到达的频率,滚动或许会被延时触发。不过,在某个时期内产生的全部记录事件都被输出到划分该时期的正确的文件,从这个角度看,虽然有延迟,滚动算法仍然是正确的。
下面是 RollingFileAppender 和 TimeBasedRollingPolicy 合做的例子。
示例:使用 TimeBasedRollingPolicy 的 RollingFileAppender 的配置例子
(logback-examples/src/main/java/chapters/appenders/conf/logback-RollingTimeBased.xml)
<configuration> <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender"> <file>logFile.log</file> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <!-- daily rollover --> <fileNamePattern>logFile.%d{yyyy-MM-dd}.log</fileNamePattern> <!-- keep 30 days worth of history --> <maxHistory>30</maxHistory> </rollingPolicy> <encoder> <pattern>%-4relative [%thread] %-5level %logger{35} - %msg%n </pattern> </encoder> </appender> <root level="DEBUG"> <appender-ref ref="FILE" /> </root> </configuration>
下面是在 prudent 模式下,使用 TimeBasedRollingPolicy 的 RollingFileAppender 的配置
例子。
示例:使用 TimeBasedRollingPolicy 的 RollingFileAppender 的配置例子
(logback-examples/src/main/java/chapters/appenders/conf/logback-PrudentTimeBasedRollin
g.xml)
<configuration> <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender"> <!-- Support multiple-JVMs writing to the same log file --> <prudent>true</prudent> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <fileNamePattern>logFile.%d{yyyy-MM-dd}.log</fileNamePattern> <maxHistory>30</maxHistory> </rollingPolicy> <encoder> <pattern>%-4relative [%thread] %-5level %logger{35} - %msg%n </pattern> </encoder> </appender> <root level="DEBUG"> <appender-ref ref="FILE" /> </root> </configuration>
有时你也许想按照日期进行归档的同时限制每一个记录文件的大小,特别是当后处理工具
对记录 文件大 小有 限制时 。Logback 为 此提 供了 SizeAndTimeBasedFNATP ,它是
TimeBasedRollingPolicy 的子组件,FNATP 表明“文件命名和触发策略”。
下面的例子演示了基于大小和时间的记录文件归档。
示例:SizeAndTimeBasedFNATP 配置
(logback-examples/src/main/java/chapters/appenders/conf/logback-sizeAndTime.xml)
<configuration> <appender name="ROLLING" class="ch.qos.logback.core.rolling.RollingFileAppender"> <file>mylog.txt</file> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <!-- rollover daily --> <fileNamePattern>mylog-%d{yyyy-MM-dd}.%i.txt</fileNamePattern> <timeBasedFileNamingAndTriggeringPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedFNATP"> <!-- or whenever the file size reaches 100MB --> <maxFileSize>100MB</maxFileSize> </timeBasedFileNamingAndTriggeringPolicy> </rollingPolicy> <encoder> <pattern>%msg%n</pattern> </encoder> </appender> <root level="debug"> <appender-ref ref="ROLLING" /> </root> </configuration>
注意“%d”后面的“%i”。在当前时间周期结束以前,每当当前记录文件达到“maxFileSize”时,就会用递增索引归档,索引从 0 开始。
基于大小和时间的归档支持删除旧归档文件。你须要用“maxHistory”属性指定要保留的周期的数量。当程序中止并重启时,记录会从正确的位置继续,即当前周期的最大索引。
TriggeringPolicy 负责指示 RollingFileAppender 在何时滚动。
TriggeringPolicy 接口只有一个方法。
package ch.qos.logback.core.rolling; import java.io.File; import ch.qos.logback.core.spi.LifeCycle; public interface TriggeringPolicy<E> extends LifeCycle { public boolean isTriggeringEvent(final File activeFile, final E event); }
isTriggeringEvent()方法有两个参数,一个是归档文件,一个是当前正被处理的记录事件。
该方法的具体实现根据这两个参数来决定是否进行滚动。
使用最普遍的触发策略是 TimeBasedRollingPolicy,它也是一个滚动策略,上节已讲过。
查看当前活动文件的大小。若是超过指定大小,SizeBasedTriggeringPolicy 会告诉RollingFileAppender 去触发当前活动文件的滚动。
SizeBasedTriggeringPolicy 只有一个参数:maxFileSize,默认值是 10MB。
根据数字后面不一样的后缀,“maxFileSize”能够是 bytes、KB、MB或 GB。好比 5000000,5000KB、5MB和 2GB都是合法值,且前三个等价。
下面是 RollingFileAppender 与 SizeBasedTriggeringPolicy 合做的配置例子,当记录文件的大小超过 5MB后,会触发滚动。
示例:使用 SizeBasedTriggeringPolicy 的 RollingFileAppender 的配置
(logback-examples/src/main/java/chapters/appenders/conf/logback-RollingSizeBased.xml)
<configuration> <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender"> <file>test.log</file> <rollingPolicy class="ch.qos.logback.core.rolling.FixedWindowRollingPolicy"> <fileNamePattern>test.%i.log.zip</fileNamePattern> <minIndex>1</minIndex> <maxIndex>3</maxIndex> </rollingPolicy> <triggeringPolicy class="ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy"> <maxFileSize>5MB</maxFileSize> </triggeringPolicy> <encoder> <pattern>%-4relative [%thread] %-5level %logger{35} - %msg%n </pattern> </encoder> </appender> <root level="DEBUG"> <appender-ref ref="FILE" /> </root> </configuration>