Logback-04-Appender
Appender
Appender 是什么
Logback将记录事件的任务委托给称为appender的组件。
Appenders必须实现 ch.qos.logback.core.Appender
接口。
该界面的显着方法总结如下:
public interface Appender extends LifeCycle, ContextAware, FilterAttachable {
public String getName();
public void setName(String name);
void doAppend(E event);
}
Appenders最终负责输出日志记录事件。
但是,他们可以将事件的实际格式委派给布局或编码器对象。每个布局/编码器与一个且仅一个appender相关联,称为拥有的appender。
一些appender具有内置或固定的事件格式。因此,它们不需要也没有布局/编码器。
例如,SocketAppender只是在通过线路传输之前序列化记录事件。
AppenderBase
ch.qos.logback.core.AppenderBase
类是实现Appender接口的抽象类。
它提供了所有appender共享的基本功能,例如获取或设置其名称,激活状态,布局和过滤器的方法。
它是带有logback的所有appender的超类。虽然是一个抽象类,但AppenderBase实际上在Append接口中实现了doAppend()方法。
也许讨论AppenderBase类的最清晰的方法是提供实际源代码的摘录。
public synchronized void doAppend(E eventObject) {
// prevent re-entry.
if (guard) {
return;
}
try {
guard = true;
if (!this.started) {
if (statusRepeatCount++
%-4relative [%thread] %-5level %logger{35} - %msg %n
FileAppender
FileAppender是OutputStreamAppender的子类,它将日志事件追加到文件中。
目标文件由“文件”选项指定。 如果文件已存在,则根据append属性的值将其附加到或截断。
属性
- append
boolean 类型
如果为true,则在现有文件的末尾附加事件。
否则,如果append为false,则截断任何现有文件。默认情况下,append选项设置为true。
- encoder
Encoder请参见OutputStreamAppender属性。
- file
String 类型
要写入的文件的名称。
如果该文件不存在,则创建该文件。
在MS Windows平台上,用户经常忘记逃避反斜杠。
例如,值 c:\temp\test.log
不太可能被正确解释,因为'\t'是解释为单个制表符(\u0009
)的转义序列。
正确的值可以指定为 c/temp/test.log
,也可以指定为 c\\temp\\test.log
。
“文件”选项没有默认值。
如果文件的父目录不存在,FileAppender将自动创建它,包括任何必要但不存在的父目录。
- prudent
boolean 类型
在谨慎模式下,FileAppender将安全地写入指定的文件,即使存在运行在不同JVM中的其他FileAppender实例,也可能在不同的主机上运行。
prudent模式的默认值为false。
尽管存在一些限制,但谨慎模式可与RollingFileAppender结合使用。
谨慎模式意味着append属性自动设置为true。
谨慎更依赖于独占文件锁。实验表明,文件锁定大约是编写日志记录事件的三倍(x3)。在写入位于本地硬盘上的文件的“普通”PC上,当谨慎模式关闭时,编写单个日志记录事件大约需要10微秒。当谨慎模式打开时,输出单个记录事件大约需要30微秒。这意味着当谨慎模式关闭时记录吞吐量为每秒100'000个事件,而谨慎模式下每秒记录大约33'000个事件。
谨慎模式有效地序列化写入同一文件的所有JVM之间的I/O操作。因此,随着竞争访问文件的JVM数量的增加,每个I/O操作引起的延迟也会增加。只要I/O操作的总数大约为每秒20个日志请求,对性能的影响应该可以忽略不计。每秒生成100个或更多I/O操作的应用程序可以看到对性能的影响,应避免使用谨慎模式。
联网文件锁当日志文件位于网络文件系统上时,审慎模式的成本会更高。同样重要的是,网络文件系统上的文件锁定有时会受到强烈偏见,使得当前拥有锁定的进程会在其释放时立即重新获得锁定。因此,当一个进程占用日志文件的锁定时,其他进程将等待锁定到出现死锁的点。
谨慎模式的影响很大程度上取决于网络速度以及操作系统实现细节。
我们提供了一个名为FileLockSimulator的非常小的应用程序,它可以帮助您模拟环境中谨慎模式的行为。
默认情况下,每个日志事件都会立即刷新到基础输出流。
这种默认方法更安全,因为如果应用程序在没有正确关闭appender的情况下退出,则日志事件不会丢失。
但是,为了显着增加日志记录吞吐量,您可能希望将immediateFlush属性设置为false。
下面是FileAppender的配置文件示例:
testFile.log
true
true
%-4relative [%thread] %-5level %logger{35} - %msg%n
独一无二的文件名称
唯一命名的文件(按时间戳)
在应用程序开发阶段或在短期应用程序的情况下,例如, 批量应用程序,最好在每次新的应用程序启动时创建一个新的日志文件。
借助``元素,这很容易做到。 这是一个例子。
log-${bySecond}.txt
%logger{35} - %msg%n
timestamp元素采用两个必需属性key和datePattern以及一个可选的timeReference属性。
key属性是键的名称,在该键下,时间戳可作为变量用于后续配置元素。
datePattern属性表示用于将当前时间(解析配置文件)转换为字符串的日期模式。
日期模式应遵循SimpleDateFormat中定义的约定。
timeReference属性表示时间戳的时间参考。
默认值是配置文件的解释/解析时间,即当前时间。
但是,在某些情况下,使用上下文出生时间作为时间参考可能是有用的。
这可以通过将timeReference属性设置为“contextBirth”来完成。
RollingFileAppender
RollingFileAppender扩展了FileAppender,具有翻转日志文件的功能。
例如,RollingFileAppender可以记录到名为log.txt文件的文件,并且一旦满足某个条件,就将其日志记录目标更改为另一个文件。
有两个与RollingFileAppender交互的重要子组件。
第一个RollingFileAppender子组件,即RollingPolicy(见下文)负责执行翻转所需的操作。
RollingFileAppender的第二个子组件,即TriggeringPolicy(见下文)将确定是否以及何时发生翻转。
因此,RollingPolicy负责什么和TriggeringPolicy负责什么时候。
作为任何用途,RollingFileAppender必须同时设置RollingPolicy和TriggeringPolicy。
但是,如果其RollingPolicy也实现了TriggeringPolicy接口,则只需要显式指定前者。
属性
- file
String请参见FileAppender属性。
- append
boolean请参阅FileAppender属性。
- encoder
Encoder请参见OutputStreamAppender属性。
- rollingPolicy
RollingPolicy 此选项是在发生翻转时指示RollingFileAppender的行为的组件。请参阅以下更多信息。
- triggeringPolicy
TriggeringPolicy此选项是告诉RollingFileAppender何时激活翻转过程的组件。请参阅以下更多信息。
谨慎模式下不支持prudent boolean FixedWindowRollingPolicy。
尽管有两个限制,RollingFileAppender与TimeBasedRollingPolicy一起支持谨慎模式。
在谨慎模式下,不支持也不允许文件压缩。 (当另一个JVM正在压缩文件时,我们不能将一个JVM写入文件。)
无法设置FileAppender的文件属性,必须将其留空。实际上,大多数操作系统不允许在另一个进程打开文件时重命名文件。
另请参见FileAppender的属性。
案例
RollingPolicy负责涉及文件移动和重命名的翻转过程。
RollingPolicy界面如下所示:
import ch.qos.logback.core.FileAppender;
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方法提供对其父级的引用。
TimeBasedRollingPolicy
TimeBasedRollingPolicy可能是最受欢迎的滚动策略。
它根据时间定义翻转策略,例如按天或按月。 TimeBasedRollingPolicy承担滚动和触发所述翻转的责任。
实际上,TimeBasedTriggeringPolicy实现了RollingPolicy和TriggeringPolicy接口。
TimeBasedRollingPolicy的配置采用一个必需的fileNamePattern属性和几个可选属性。
属性
fileNamePattern具有双重用途。首先,通过研究模式,logback计算请求的翻转周期。
其次,它计算每个存档文件的名称。请注意,两种不同的模式可以指定相同的周期。
模式yyyy-MM和yyyy @ MM都指定了每月翻转,尽管生成的存档文件将带有不同的名称。
通过设置file属性,您可以解除活动日志文件的位置和存档日志文件的位置。日志记录输出将定位到file属性指定的文件中。因此,活动日志文件的名称不会随时间而变化。但是,如果选择省略file属性,则将根据fileNamePattern的值为每个句点重新计算活动文件。通过保留文件选项未设置,可以避免在翻转期间存在引用日志文件的外部文件句柄时发生的文件重命名错误。
maxHistory属性控制要保留的最大归档文件数,删除旧文件。例如,如果您指定每月翻转,并将maxHistory设置为6,则将保留6个月的归档文件,其中包含超过6个月的文件。请注意,删除旧的归档日志文件后,将根据需要删除为日志文件归档而创建的所有文件夹。
由于各种技术原因,翻转不是时钟驱动的,而是取决于记录事件的到来。例如,在2002年3月8日,假设fileNamePattern设置为yyyy-MM-dd(每日翻转),则午夜之后第一个事件的到达将触发翻转。如果在午夜之后的23分47秒没有记录事件,那么翻转实际上将发生在3月9日00:23'47 AM而不是凌晨0:00。因此,根据事件的到达率,可能会以一些延迟触发翻转。但是,无论延迟如何,已知翻转算法是正确的,因为在某个时间段内生成的所有日志记录事件都将在限定该时间段的正确文件中输出。
案例
logFile.log
logFile.%d{yyyy-MM-dd}.log
30
3GB
%-4relative [%thread] %-5level %logger{35} - %msg%n
基于规模和时间的滚动政策
有时您可能希望按日期归档文件,但同时限制每个日志文件的大小,特别是如果后处理工具对日志文件施加大小限制。
为了满足此要求,logback随附SizeAndTimeBasedRollingPolicy。
请注意,TimeBasedRollingPolicy已允许限制归档日志文件的组合大小。
如果您只想限制日志存档的组合大小,那么上面描述的TimeBasedRollingPolicy和设置totalSizeCap属性应该足够了。
这是一个示例配置文件,演示了基于时间和大小的日志文件归档。
mylog.txt
mylog-%d{yyyy-MM-dd}.%i.txt
100MB
60
20GB
%msg%n
触发策略概述
TriggeringPolicy实现负责指示RollingFileAppender何时进行翻转。
TriggeringPolicy接口仅包含一个方法。
import java.io.File;
import ch.qos.logback.core.spi.LifeCycle;
public interface TriggeringPolicy extends LifeCycle {
public boolean isTriggeringEvent(final File activeFile, final event);
}
isTriggeringEvent() 方法将活动文件和当前正在处理的日志记录事件作为参数。
具体实现基于这些参数确定是否应该发生翻转。
最广泛使用的触发策略,即TimeBasedRollingPolicy也可以兼作滚动策略,之前已经与其他滚动策略一起讨论过。
SizeBasedTriggeringPolicy
SizeBasedTriggeringPolicy查看当前活动文件的大小。如果它大于指定的大小,它将发出拥有的RollingFileAppender信号,以触发现有活动文件的翻转。
SizeBasedTriggeringPolicy只接受一个参数,即maxFileSize,默认值为10 MB。
maxFileSize选项可以以字节,千字节,兆字节或千兆字节为单位,后缀数值为KB,MB和GB。例如,5000000,5000KB,5MB和2GB都是有效值,前三个是等效的。
下面是一个示例配置,当日志文件大小达到5MB时,RollingFileAppender与SizeBasedTriggeringPolicy一起触发翻转。
test.log
test.%i.log.zip
1
3
5MB
%-4relative [%thread] %-5level %logger{35} - %msg%n