以下内容翻译整理自logback官方手册，地址：logback官方手册

Appender 是什么？

Logback将编写日志事件的任务委托给称为appenders的组件。Appenders必须实现ch.qos.logback.core.Appender接口。该接口的主要方法总结如下：

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接口中的大多数方法都是setter和getter。只有doAppend()方法是例外的，它将一个类型为E的对象作为参数。E的实际类型将根据logback模块的不同而有所不同。在logback-classic模块中，E的类型是ILoggingEvent，在logback-access模块中，E的类型是AccessEvent。doAppend()方法是logback框架中最重要的方法。它负责将日志事件以适当的格式输出到适当的输出设备。

Appenders是可以被命名的。这确保了可以通过名称引用它们，这是脚本配置中很重要的一个特性。Appender接口扩展了FilterAttachable接口，可以将一个或多个过滤器附加到一个appender实例。过滤器将在下一章详细讨论。

Appenders负责最终输出日志事件。但是，它们可以将日志事件的格式化委托给一个Layout或一个Encoder对象。每个Layout/Encoder都与一个且仅与一个appender关联。有些appenders具有内置或固定的事件格式，因此，它们既不需要也没有Layout/Encoder。例如，SocketAppender只会在通过网络传输日志事件之前对它们进行序列化。

AppenderBase

ch.qos.logback.core.AppenderBase类是实现了Appender接口的一个抽象类。它提供了所有appenders共享的基础功能，例如获取或设置它们的名称、激活状态、布局和过滤器的方法。它是logback自带的所有appenders的超类。虽然是一个抽象类，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 the derived class's implementation of append
    this.append(eventObject);

  } finally {
    guard = false;
  }
}

这里实现的doAppend()是一个同步方法。因此，从不同的线程记录到相同的appender是线程安全的。当线程(例如T)执行doAppend()方法时，其他线程随后的调用将排队，直到T离开doAppend()方法，从而确保T对appender的独占访问。

由于这种同步并不总是合适的，所以logback又提供了一个ch.qos.logback.core.UnsynchronizedAppenderBase，和AppenderBase类非常类似。为了简洁起见，我们在本文档的其余部分只讨论UnsynchronizedAppenderBase。

doAppend()方法做的第一件事是检查守卫是否被设置为true。如果是，则立即退出。如果不是，则在下一个语句中将其设置为true。该保护确保doAppend()方法不会递归地调用自己。假设一个在append()方法之外调用的组件想要记录一些东西。它的调用可以直接指向刚才调用它的相同的追加器，从而导致无限循环和堆栈溢出。

在接下来的语句中，我们检查started字段是否为true。如果不是，doAppend()将发送一个警告消息并返回。换句话说，一旦一个appender被关闭了，就不可能再对它进行写入。Appender接口继承了LifeCycle接口，这意味着它的实现类也实现了start()、stop()和isStarted()方法。设置完appender的所有属性后，Joran是logback的配置框架，它会调用start()方法来通知appender激活其属性。根据其类型的不同，如果某些属性丢失或由于各种属性之间的干扰，appender可能启动失败。例如，考虑到文件创建依赖于截断模式，在Append选项的值被确定之前，FileAppender不能对它的File选项的值执行操作。显式激活步骤确保appender在其属性的值被知道后对其进行操作。

如果appender无法启动或已经停止，将通过logback的内部状态管理系统发出警告消息。经过多次尝试，为了避免同一警告消息的副本充斥内部状态系统，doAppend()方法将停止发出这些警告。

下一个if语句检查附加过滤器的结果。根据过滤器链产生的决策，可以拒绝或显式接受事件。在过滤器链没有做出决定的情况下，默认情况下接受事件。

然后doAppend()方法调用派生类的append()方法实现。此方法的实际工作是将执行将事件附加到适当设备。

最后，释放保护，以便允许随后的请求调用doAppend()方法。

Logback-core

logback -core是构建其他logback模块的基础。提供了几个定制的的appender。在接下来的几节中，我们将介绍这几个的appenders。

OutputStreamAppender

OutputStreamAppender追加事件到一个java.io.OutputStream。该类提供了其他appender构建的基础。用户通常不会直接实例化OutputStreamAppender对象，因为一般来说java.io.OutputStream类型不能方便地映射到字符串，因为无法在配置脚本中指定目标OutputStream对象。简单地说，您不能从配置文件配置OutputStreamAppender。然而，这并不意味着OutputStreamAppender缺乏可配置属性，下面将描述这些属性。

OutputStreamAppender是其他三个追加器的超类，也就是ConsoleAppender、FileAppender、RollingFileAppender的超类。下图展示了OutputStreamAppender及其子类的类图。

ConsoleAppender

ConsoleAppender，顾名思义，附加在控制台，或者更准确地说是System.out或者System.err。前者是默认目标。ConsoleAppender在用户指定的编码器的帮助下格式化事件。编码器将在下一章中讨论。这两个System.out和System.err的类型是java.io.PrintStream，因此，它们是被封装在OutputStreamWriter中的缓冲 I/O 操作。

下面是一个使用ConsoleAppender的示例配置。

<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 %logger{35} - %msg %n</pattern>
    </encoder>
  </appender>

  <root level="DEBUG">
    <appender-ref ref="STDOUT" />
  </root>
</configuration>

FileAppender

FileAppender是OutputStreamAppender的一个子类，追加日志事件到一个文件中，目标文件由File选项指定。如果文件已经存在，根据append属性的值，要么被追加，要么被截断。

默认情况下，每个日志事件都会立即刷新到底层输出流。从某种意义上说，如果应用程序在没有正确关闭appenders的情况下退出，日志事件不会丢失，这种默认方法更安全。但是，为了显著提高日志吞吐量，您可能需要将immediateFlush属性设置为false。下面是FileAppender配置文件的一个例子：

<configuration>

  <appender name="FILE" class="ch.qos.logback.core.FileAppender">
    <file>testFile.log</file>
    <append>true</append>
    <!-- 将immediateFlush设置为false，以获得更高的日志吞吐量 -->
    <immediateFlush>true</immediateFlush>
    <!-- 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>

唯一命名的文件(按时间戳)

在应用程序开发阶段或短期应用程序的情况下，例如，批量应用程序，最好在每次启动新的应用程序时创建一个新的日志文件。在<timestamp>元素的帮助下，这非常容易做到。下面是一个例子：

<configuration>

  <!-- 插入一个格式为"yyyyMMdd'T'HHmmss"的时间戳"bySecond"到日志记录器上下文。这个值将是可用于所有后续配置元素 -->
  <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，以及一个可选的timeReference属性。key属性的值是时间戳名称，后续配置元素可以通过引用该名称将时间戳作为变量。datePattern属性表示用于将当前时间转换为字符串的日期格式。日期模式应该遵循SimpleDateFormat中定义的约定。timeReference属性表示时间戳的时间引用。默认值是当前时间。然而，在某些情况下，可能需要使用上下文出生时间作为时间引用。这可以通过将timeReference属性设置为“contextBirth”来实现。如下所示：

<configuration>
  <timestamp key="bySecond" datePattern="yyyyMMdd'T'HHmmss" 
             timeReference="contextBirth"/>
  ...
</configuration>

RollingFileAppender

RollingFileAppender扩展了FileAppender，使其能够滚动日志文件。例如，RollingFileAppender可以将日志记录到一个名为log.txt的文件中，一旦满足某个条件，就将其日志记录目标更改为另一个文件。

RollingFileAppender有两个重要的子组件。第一个是RollingPolicy，负责滚动所需的操作。第二个子是TriggeringPolicy，负责什么时候进行触发滚动。

要想发挥任何作用，RollingFileAppender必须同时设置RollingPolicy和TriggeringPolicy。但是，如果它的RollingPolicy也实现TriggeringPolicy接口，那么只需要显式地指定前者。下面是RollingFileAppender的可用属性：

滚动策略概述

RollingPolicy负责包含文件移动和重命名的翻转过程。RollingPolicy接口如下所示：

package ch.qos.logback.core.rolling;  

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方法所示，滚动策略还负责确定压缩模式。最后，通过setParent方法向滚动策略提供对其父策略的引用。

TimeBasedRollingPolicy

TimeBasedRollingPolicy可能是最流行的滚动策略。它定义了一个基于时间的滚动策略，例如按天或按月。基于时间的滚转策略同时承担滚转和触发滚转的责任。实际上，TimeBasedTriggeringPolicy同时实现了RollingPolicy和TriggeringPolicy接口。TimeBasedRollingPolicy的配置采用一个强制性的fileNamePattern属性和几个可选属性。

下面是一些fileNamePattern值，并解释了它们的效果。

任何向前或向后斜杠字符都被解释为文件夹(目录)分隔符。任何需要的文件夹都将根据需要创建。因此，您可以轻松地将日志文件放在单独的文件夹中。

TimeBasedRollingPolicy支持自动文件压缩。如果fileNamePattern选项的值以.gz或.zip结尾，则启用此功能。

fileNamePattern有双重用途。首先，通过研究模式，logback计算请求的翻转周期。其次，它计算每个存档文件的名称。注意，两种不同的模式可以指定相同的周期性。模式yyyy-MM和yyyy@MM都指定了每月的滚动，尽管生成的归档文件将使用不同的名称。

通过设置file属性，您可以解耦活动日志文件的位置和存档日志文件的位置。日志输出将定向到file属性指定的文件中。因此，活动日志文件的名称不会随时间而更改。但是，如果您选择忽略file属性，然后根据fileNamePattern的值为每个周期重新计算活动文件。通过不设置file选项，您可以避免文件重命名错误，这些错误发生在存在外部文件句柄在滚转期间引用日志文件时。

由于各种技术原因，滚动不是时钟驱动的，而是取决于日志事件的到来。例如，在2002年3月8日，假设fileNamePattern设置为yyyy-MM-dd(每日翻转)，午夜后第一个事件的到来将触发翻转。如果在午夜之后的23分47秒内没有日志记录事件，那么翻转实际上将发生在3月9日凌晨00:23'47，而不是凌晨0:00。因此，根据事件的到达率，可能会触发一些延迟的滚动。但是，不管延迟如何，翻转算法是正确的，因为在某个时间段内生成的所有日志事件都将输出到分隔该时间段的正确文件中。

下面是RollingFileAppender与TimeBasedRollingPolicy的示例配置。

<configuration>
  <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
    <file>logFile.log</file>
    <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
      <!-- 每日翻转 -->
      <fileNamePattern>logFile.%d{yyyy-MM-dd}.log</fileNamePattern>

      <!-- 将30天的历史记录限制在3GB的总大小 -->
      <maxHistory>30</maxHistory>
      <totalSizeCap>3GB</totalSizeCap>

    </rollingPolicy>

    <encoder>
      <pattern>%-4relative [%thread] %-5level %logger{35} - %msg%n</pattern>
    </encoder>
  </appender> 

  <root level="DEBUG">
    <appender-ref ref="FILE" />
  </root>
</configuration>

下一个配置示例演示了在谨慎模式下使用与TimeBasedRollingPolicy关联的RollingFileAppender。

<configuration>
  <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
    <!-- 支持多个JVM写入同一个日志文件 -->
    <prudent>true</prudent>
    <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
      <fileNamePattern>logFile.%d{yyyy-MM-dd}.log</fileNamePattern>
      <maxHistory>30</maxHistory> 
      <totalSizeCap>3GB</totalSizeCap>
    </rollingPolicy>

    <encoder>
      <pattern>%-4relative [%thread] %-5level %logger{35} - %msg%n</pattern>
    </encoder>
  </appender> 

  <root level="DEBUG">
    <appender-ref ref="FILE" />
  </root>
</configuration>

SizeAndTimeBasedRollingPolicy

有时，您可能希望按日期归档文件，但同时限制每个日志文件的大小，特别是如果之后使用的处理工具对日志文件有大小限制时。为了满足这一需求，logback提供了SizeAndTimeBasedRollingPolicy。

注意，TimeBasedRollingPolicy已经允许限制归档日志文件的总体大小。如果只希望限制日志归档文件的总体大小，那么上面描述的TimeBasedRollingPolicy设置totalSizeCap属性应该就够用了。

下面是一个示例配置文件，演示了基于时间和单个文件大小的日志文件归档。

<configuration>
  <appender name="ROLLING" class="ch.qos.logback.core.rolling.RollingFileAppender">
    <file>mylog.txt</file>
    <rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy">
      <!-- 每日翻转 -->
      <fileNamePattern>mylog-%d{yyyy-MM-dd}.%i.txt</fileNamePattern>
       <!-- 每个文件最多100MB，保存60天的历史记录，但总大小最多20GB -->
       <maxFileSize>100MB</maxFileSize>    
       <maxHistory>60</maxHistory>
       <totalSizeCap>20GB</totalSizeCap>
    </rollingPolicy>
    <encoder>
      <pattern>%msg%n</pattern>
    </encoder>
  </appender>


  <root level="DEBUG">
    <appender-ref ref="ROLLING" />
  </root>

</configuration>

注意%d之外的%i转换符号。%i和%d转换符都是必需的，每次当前日志文件在当前时间段结束之前达到maxFileSize时，将使用一个递增索引(从0开始)对其进行归档。

基于大小和时间的存档支持删除旧的存档文件。您需要使用maxHistory属性指定要保存的周期数。当应用程序停止并重新启动时，日志将继续记录在正确的位置，即当前期间的最大索引号。

在1.1.7之前的版本中，这个文档提到了一个名为SizeAndTimeBasedFNATP的组件。但是，考虑到SizeAndTimeBasedFNATP配置结构比较简单，我们不再记录SizeAndTimeBasedFNATP。不过，使用SizeAndTimeBasedFNATP的早期配置文件将继续正常工作。实际上，SizeAndTimeBasedRollingPolicy是用SizeAndTimeBasedFNATP子组件实现的。

FixedWindowRollingPolicy

当滚动时，FixedWindowRollingPolicy根据下面描述的固定窗口算法重命名文件。fileNamePattern选项表示归档(滚动)日志文件的文件名模式。此选项是必需的，并且必须在模式中包含整数令牌%i。下面是FixedWindowRollingPolicy的可用属性。

由于固定窗口滚动策略需要的文件重命名操作与窗口大小一样多，因此强烈建议不要使用较大的窗口大小。当用户指定较大的值时，当前实现将自动将窗口大小减小到20。

让我们来看一个关于固定窗口翻转策略的更具体的例子。假设minIndex设置为1，maxIndex设置为3，fileNamePattern属性设置为foo%i.log。file属性被设置为foo.log。

下面的配置文件给出了一个配置RollingFileAppender和FixedWindowRollingPolicy的示例。注意，File选项是强制性的，即使它包含与fileNamePattern选项所传递的一些相同的信息。

<configuration>
  <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
    <file>test.log</file>

    <rollingPolicy class="ch.qos.logback.core.rolling.FixedWindowRollingPolicy">
      <fileNamePattern>tests.%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>

触发策略概述

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

SizeBasedTriggeringPolicy查看当前活动文件的大小。如果它的大小超过指定的大小，它将向拥有的RollingFileAppender发出信号，触发现有活动文件的翻转。

SizeBasedTriggeringPolicy只接受一个参数maxFileSize，默认值为10MB。

maxFileSize选项可以用字节、千字节、兆字节或千兆字节来指定，方法是分别用KB、MB和GB作为数字值的后缀。例如，5000000、5000KB、5MB和2GB都是有效值，前三个值是等价的。

下面是一个带有RollingFileAppender的示例配置，它与SizeBasedTriggeringPolicy一起在日志文件达到5MB时触发翻转。

<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>

Logback Classic

虽然日志事件在logback-core中是通用的，但在logback-classic中，它们始终是ILoggingEvent的实例。Logback-classic不过是一个专门处理ILoggingEvent实例的管道。

SocketAppender 和 SSLSocketAppender

到目前为止，所涉及的appenders只能记录日志到本地资源。相反，SocketAppender的设计目的是通过网络传输序列化的ILoggingEvent实例来记录日志到远程实体。当使用SocketAppender时，线路上的日志事件将以明文形式发送。然而，当使用SSLSocketAppender时，日志事件是通过安全通道传递的。

序列化事件的实际类型是LoggingEventVO，它实现了ILoggingEvent接口。然而，就日志事件而言，远程日志记录是非侵入性的。在反序列化后的接收端，可以像在本地生成一样记录事件。运行在不同机器上的多个SocketAppender实例可以将它们的日志输出定向到格式固定的中央日志服务器。SocketAppender不接受关联的layout，因为它将序列化的事件发送到远程服务器。SocketAppender运行在传输控制协议(TCP)层之上，TCP层提供了一个可靠的、有序的、流控制的端到端八位字节流。因此，如果远程服务器是可访问的，那么日志事件最终将到达那里。如果远程服务器关闭或无法访问，日志事件将被删除。当服务器恢复时，事件传输将透明地恢复。这种透明的重连接由一个连接器线程执行，该线程定期尝试连接到服务器。

日志事件由本机TCP实现自动缓冲。这意味着，如果到服务器的链接很慢，但是仍然比客户机生成事件的速度快，客户机将不会受到慢速网络连接的影响。但是，如果网络连接比事件生成的速度慢，那么客户机只能以网络速度前进。特别是在连接到服务器的网络连接关闭的极端情况下，客户机最终将被阻塞。或者，如果网络链接已打开，但服务器已关闭，则不会阻塞客户机，尽管日志事件将由于服务器不可用而丢失。

即使SocketAppender不再附加到任何日志程序，它也不会在连接器线程存在时被垃圾回收。连接器线程仅在与服务器的连接关闭时才存在。为了避免这种垃圾收集问题，您应该显式地关闭SocketAppender。长生命周期应用程序会创建/销毁许多SocketAppender实例，应该注意这个垃圾收集问题。大多数其他应用程序可以安全地忽略它。如果托管SocketAppender的JVM在SocketAppender关闭之前（显式关闭或垃圾收集之后关闭）退出，那么管道中可能会丢失未传输的数据。这是基于Windows系统的常见问题。为了避免丢失数据，通常可以显式地关闭SocketAppender()，或者在退出应用程序之前调用LoggerContext的stop()方法。

远程服务器由remoteHost和port属性标识。下表列出了SocketAppender属性。SSLSocketAppender支持许多额外的配置属性，这些属性将在“使用SSL”一节中详细介绍。

日志服务器选项

标准的Logback-Classic为服务器提供了两个选项，用于接收来自SocketAppender或SSLSocketAppender的日志事件。

• ServerSocketReceiver及其支持SSL-enabled程序的SSLServerSocketReceiver是接收器组件，可以在应用程序的logback.xml配置文件中配置这些组件，以便从远程套接字追加器接收事件。有关配置细节和使用示例，请参见接收器Receivers的介绍。
• SimpleSocketServer及其支持SSL-enabled程序的SimpleSSLSocketServer都提供了易于使用的独立Java应用程序，该应用程序的设计目的是配置并从shell的命令行接口运行。这些应用程序只是等待来自SocketAppender或SSLSocketAppender客户机的日志事件。每个接收到的事件都根据本地服务器策略进行日志记录。下面给出了使用示例。

使用 SimpleSocketServer

SimpleSocketServer应用程序接受两个命令行参数：port和configFile；其中port是要监听的端口，configFile是XML格式的配置脚本。

假设您在logback-examples/目录中，使用以下命令启动SimpleSocketServer：

java ch.qos.logback.classic.net.SimpleSocketServer 6000 \
  src/main/java/chapters/appenders/socket/server1.xml

这里6000是要监听的端口号，server1.xml是一个配置脚本，它向根日志记录器添加了一个ConsoleAppender和一个RollingFileAppender。启动SimpleSocketServer之后，您可以使用SocketAppender从多个客户机向它发送日志事件。与本手册相关的例子包括两个这样的客户端：chapters.appenders.SocketClient1和chapters.appenders.SocketClient2两个客户机都在等待用户在控制台上输入一行文本。文本被封装在一个debug级别的日志事件中，然后发送到远程服务器。这两个客户机在SocketAppender的配置上有所不同。SocketClient1以编程方式配置追加器，而SocketClient2需要配置文件。

假设SimpleSocketServer在本地主机上运行，您可以使用以下命令连接到它：

java chapters.appenders.socket.SocketClient1 localhost 6000

您键入的每一行都应该出现在上一步中启动的SimpleSocketServer的控制台。如果停止并重启SimpleSocketServer，客户机将透明地重新连接到新服务器实例，尽管断开连接时生成的事件将简单地(并且不可挽回地)丢失。

与SocketClient1不同，示例应用程序SocketClient2本身并不配置logback。它需要XML格式的配置文件。如下所示的配置文件client1.xml创建了一个SocketAppender并将其附加到根日志记录器。

<configuration>
          
  <appender name="SOCKET" class="ch.qos.logback.classic.net.SocketAppender">
    <remoteHost>${host}</remoteHost>
    <port>${port}</port>
    <reconnectionDelay>10000</reconnectionDelay>
    <includeCallerData>${includeCallerData}</includeCallerData>
  </appender>

  <root level="DEBUG">
    <appender-ref ref="SOCKET" />
  </root>  

</configuration>

注意，在上面的配置脚本中，remoteHost、port和includeCallerData 属性的值不是直接给出的，而是作为替代变量键给出的。变量的值可以指定为系统属性：

java -Dhost=localhost -Dport=6000 -DincludeCallerData=false \
  chapters.appenders.socket.SocketClient2 src/main/java/chapters/appenders/socket/client1.xml

该命令的结果应该与前面的SocketClient1示例类似。

请允许我们重复一遍，以强调日志事件的序列化不具有侵入性。反序列化事件与任何其他日志事件携带相同的信息。它可以像在本地生成一样进行操作；除了默认情况下序列化日志事件不包含调用方数据之外。这里有一个例子来说明这一点。首先，使用以下命令启动SimpleSocketServer：

 java ch.qos.logback.classic.net.SimpleSocketServer 6000 \
  src/main/java/chapters/appenders/socket/server2.xml

配置文件server2.xml创建一个ConsoleAppender，其布局输出调用者的文件名和行号以及其他信息。如果像以前一样使用配置文件client1.xml运行SocketClient2，你会注意到服务器端的输出将包含两个问号之间的括号，而不是文件名和行号的调用者：

2006-11-06 17:37:30,968 DEBUG [Thread-0] [?:?] chapters.appenders.socket.SocketClient2 - Hi

通过将includeCallerData选项设置为true，指示SocketAppender包含调用方数据，可以很容易地更改结果。使用下面的命令就可以了：

java -Dhost=localhost -Dport=6000 -DincludeCallerData=true \
  chapters.appenders.socket.SocketClient2 src/main/java/chapters/appenders/socket/client1.xml

由于反序列化事件可以与本地生成的事件以相同的方式处理，甚至可以将它们发送到另一台服务器进行进一步处理。作为练习，您可能希望设置两个服务器，其中第一个服务器将其接收到的事件从客户机传输到第二个服务器。

使用 SimpleSSLSocketServer

SimpleSSLSocketServer和SimpleSocketServer一样，也需要port和configFile命令行参数。此外，必须使用命令行中指定的系统属性为日志服务器的X.509凭证提供位置和密码。

假设您在logback-examples/目录中，使用以下命令启动SimpleSSLSocketServer：

java -Djavax.net.ssl.keyStore=src/main/java/chapters/appenders/socket/ssl/keystore.jks \
    -Djavax.net.ssl.keyStorePassword=changeit \
    ch.qos.logback.classic.net.SimpleSSLSocketServer 6000 \
    src/main/java/chapters/appenders/socket/ssl/server.xml

本例使用只适合于测试和实验的X.509凭据运行SimpleSSLSocketServer。在生产设置中使用SimpleSSLSocketServer之前，您应该获得一个适当的X.509凭据来标识您的日志服务器。有关详细信息，请参见"使用SSL"。

因为服务器配置在根元素上指定debug="true"，您将在服务器的启动日志中看到将要使用的SSL配置。这对于验证本地安全策略实现是否正确非常有用。

运行SimpleSSLSocketServer后，可以使用SSLSocketAppender连接到服务器。下面的示例显示了所需的appender配置：

<configuration debug="true">
          
  <appender name="SOCKET" class="ch.qos.logback.classic.net.SSLSocketAppender">
    <remoteHost>${host}</remoteHost>
    <port>${port}</port>
    <reconnectionDelay>10000</reconnectionDelay>
    <ssl>
      <trustStore>
        <location>${truststore}</location>
        <password>${password}</password>
      </trustStore>
    </ssl>
  </appender>

  <root level="DEBUG">
    <appender-ref ref="SOCKET" />
  </root>  

</configuration>

注意，与前面的示例一样，remoteHost、port的值是使用替换的变量键指定的。此外，请注意ssl属性及其嵌套的trustStore属性的存在，该属性指定存储的位置和密码。这个配置是必要的，因为我们的示例服务器使用的是自签名证书。有关SSLSocketAppender的SSL配置属性的更多信息，请参见“使用SSL”。

通过在命令行上指定替换变量值作为系统属性，我们可以使用这种配置运行客户机应用程序：

java -Dhost=localhost -Dport=6000 \
    -Dtruststore=file:src/main/java/chapters/appenders/socket/ssl/truststore.jks \
    -Dpassword=changeit \
    chapters.appenders.socket.SocketClient2 src/main/java/chapters/appenders/socket/ssl/client.xml

与前面的示例一样，您可以在客户机应用程序提示时输入一条消息，消息将被发送到日志服务器(现在通过一个安全通道)，并显示在控制台。

注意，命令行上给出的truststore属性指定一个文件URL，该URL标识可信任的存储位置。您还可以使用类路径URL，如“使用SSL”中所述。

正如我们前面在服务器启动时看到的，由于客户机配置在根元素上指定了debug="true"，客户机的启动日志记录包括SSL配置的详细信息，以帮助审查本地策略的一致性。

ServerSocketAppender 和 SSLServerSocketAppender

前面讨论的SocketAppender组件(及其支持ssl的对应组件)旨在允许应用程序通过网络连接到远程日志服务器，以便向服务器交付日志事件。

在某些情况下，让应用程序启动到远程日志服务器的连接可能不方便或不可行。对于这些情况，Logback提供ServerSocketAppender。

不启动到远程日志服务器的连接，ServerSocketAppender被动地监听TCP套接字，等待来自远程客户机的传入连接。提交到附加器的日志事件分布到每个连接的客户机。当没有客户机连接时发生的日志事件将被立即丢弃。

除了基本的ServerSocketAppender之外，Logback还提供了SSLServerSocketAppender，它使用一个安全加密的通道将日志事件分发给每个连接的客户机。此外，启用ssl的appender完全支持基于证书的相互认证，可以使用这种认证确保只有经过授权的客户端才能连接到appender来接收日志事件。

为在线路上传输而编码日志事件的方法与SocketAppender使用的方法相同；每个事件都是ILoggingEvent的序列化实例。只有连接启动的方向是相反的。SocketAppender在建立到日志服务器的连接时充当主动对等点，而ServerSocketAppender是被动的；它侦听来自客户机的传入连接。

ServerSocketAppender子类型仅用于Logback接收器组件。有关此组件类型的附加信息，请参见接收器。ServerSocketAppender支持以下配置属性：

下面的示例演示了一个使用ServerSocketAppender的配置：

<configuration debug="true">
  <appender name="SERVER" 
    class="ch.qos.logback.classic.net.server.ServerSocketAppender">
    <port>${port}</port>
    <includeCallerData>${includeCallerData}</includeCallerData>
  </appender>

  <root level="debug">
    <appender-ref ref="SERVER" />
  </root>  

</configuration>

注意，此配置与前面的示例不同，仅在为appender指定的类中使用ServerSocketAppender，并且在没有remoteHost属性的情况下——此appender被动地等待来自远程主机的入站连接，而不是打开到远程日志服务器的连接。

下面的示例演示了使用SSLServerSocketAppender的配置。

<configuration debug="true">
  <appender name="SERVER" 
    class="ch.qos.logback.classic.net.server.SSLServerSocketAppender">
    <port>${port}</port>
    <includeCallerData>${includeCallerData}</includeCallerData>
    <ssl>
      <keyStore>
        <location>${keystore}</location>
        <password>${password}</password>
      </keyStore>
    </ssl>
  </appender>

  <root level="debug">
    <appender-ref ref="SERVER" />
  </root>  

</configuration>

此配置与前一个配置之间的主要区别在于，appender的class属性标识了SSLServerSocketAppender类型，以及嵌套ssl元素的存在，在本例中，嵌套ssl元素指定了包含附加器X.509凭据的密钥存储库的配置。有关SSL配置属性的信息，请参阅“使用SSL”。

因为ServerSocketAppender子类型被设计用于与接收器组件一起使用，所以我们将接收器的章节提供使用示例。

SMTPAppender

SMTPAppender将日志事件累积到一个或多个固定大小的缓冲区中，并在发生用户指定的事件后通过电子邮件发送适当缓冲区的内容。SMTP电子邮件传输(发送)是异步执行的。默认情况下，电子邮件传输由级别错误的日志事件触发。此外，默认情况下，所有事件都使用一个缓冲区。

下表总结了SMTPAppender的各种性能。

未完待续。。。