跳至主要內容

Log4j2-06-log4j2 配置入门介绍

老马啸西风2016年5月21日大约 43 分钟Loglogapachelog4j2

配置

将日志请求插入到应用程序代码中需要进行大量的计划和工作。

观察表明，大约4%的代码专门用于日志记录。因此，即使是中等规模的应用程序也会在其代码中嵌入数千条日志记录语句。

考虑到它们的数量，必须管理这些日志语句，而不需要手动修改它们。

Log4j 2的配置可以通过以下四种方式之一完成:

  • 通过用XML、JSON、YAML或属性格式编写的配置文件。

  • 通过编程方式，创建一个ConfigurationFactory和Configuration实现。

  • 通过编程方式，调用Configuration接口中公开的api，将组件添加到默认配置中。

  • 以编程方式，通过调用内部Logger类上的方法。

本页主要关注通过配置文件配置Log4j。关于以编程方式配置Log4j的信息可以在扩展Log4j 2和程序化Log4j配置中找到。

所有可用的格式在功能上都是相同的。

例如，可以使用属性格式重写XML中的配置文件(反之亦然)，而不会损失任何功能。

但是，使用自然支持嵌套的格式可以更好地捕获Log4j配置的层次结构特性，因此XML、JSON和YAML文件通常更易于使用。

注意，这与Log4j 1不同。因此，公共Log4j 2 API不公开添加、修改或删除追加程序和过滤器的方法，也不公开以任何方式操纵配置的方法。

配置架构 Configuration Architecture

部分原因是首先添加了对XML的支持，所以Log4j的配置反映为树结构。

实际上，每种配置方言(包括ConfigurationBuilder)都会为每个配置元素生成一个Node。

节点是一个相当简单的结构，它包含一组属性、一组子节点和一个PluginType。

重要的是要注意，每个节点都必须有一个相应的插件，因为插件是实际执行节点所代表的工作的组件。

Log4j支持的每种文档类型都有一个ConfigurationFactory。工厂本身是一个Log4j插件，声明它支持的文件扩展名及其优先级。

属性的优先级最高，值为8，其次是yaml、json和xml。当执行自动配置时，Log4j将调用这些工厂中的每一个，以确定哪个(如果有的话)支持指定的配置文件格式。

如果找到一个，工厂将创建相应的Configuration对象，并将对配置数据的引用传递给它。

每个配置实现(如XMLConfiguration、YamlConfiguration、JsonConfiguration等)的主要任务都是将配置文本转换为Node树，通常是使用可用于该文档类型的任何工具解析文本。

应该注意的是，虽然大多数支持的文档类型本质上是树结构的，但Java属性语法不是。由于需要将语法转换为Node树，因此Log4j使用的Java属性语法要求所有属性遵循使树结构清晰的命名模式。

因此，Java Properties格式往往比使用其他文档类型更冗长。

创建了Node树后，将控制委托给AbstractConfiguration，后者使用Log4j的Plugin系统将节点转换为各自的Java对象，并提供所有公共功能。

仲裁者 Arbiters

在某些情况下，希望有一个可以在任何部署环境中使用的日志配置。

例如，可能需要在生产中使用与开发中不同的默认日志级别。另一种情况可能是本机运行时使用一种类型的appender，而部署到docker容器时使用另一种类型的appender。

处理这个问题的一种方法是使用Spring Cloud Config Server之类的工具，它可以感知环境，并为每个环境提供不同的文件。另一种选择是在配置中包含Arbiters。

Arbiters 仲裁者是一个Log4j插件，它的工作是确定是否应该在生成的配置中包含其他已配置的元素。

虽然所有其他“核心”插件都被设计为作为Log4j运行时逻辑的一部分执行，但Arbiters在Node树构建之后执行，但在树转换为配置之前执行。

仲裁者是一个节点本身，它总是在处理节点树之前从节点树中删除。

仲裁器所做的只是提供一个方法，该方法返回一个布尔值结果，该结果确定仲裁器的子节点是应该保留在配置中还是应该被修剪。

仲裁器可以出现在配置中允许元素的任何地方。

因此，仲裁者可以封装像单个属性声明或一整套appeners或logger一样简单的东西。仲裁者也可以嵌套，但是作为另一个仲裁者后代的仲裁者只有在祖先返回true时才会被评估。仲裁器的子元素必须是任何作为仲裁器父元素的有效元素。

这个例子显示了配置的两个仲裁器，根据env System属性的值是“dev”还是“prod”，它们将包括控制台Appender或列表Appender。

通常情况下，仲裁者是独立于其他仲裁者的。

也就是说，一个仲裁者的结果不会影响任何其他仲裁者。

当您只想使用一组选项中的一个时，这可能会很麻烦。

在这种情况下，可以使用一个名为“Select”的特殊插件。

Select下的每个元素都必须是仲裁者。第一个返回真值的仲裁者将被使用，而其他仲裁者将被忽略。如果没有Arbiter返回true，则可以使用默认配置元素配置DefaultArbiter。

DefaultArbiter是一个总是返回true的仲裁者，所以在Select之外使用它会导致它的配置元素总是被包含，就好像它不存在一样。

这个例子展示了一个仲裁者，它使用驻留在单独文件中的Javascript来确定是否包含控制台Appender。如果结果为false，则会包含一个List Appender。

原生Log4j包含SystemProperty仲裁者，它可以根据SystemProperty是否为非空或具有特定值来评估是否包含元素，一个ClassArbiter根据指定的类是否存在做出决定，以及一个ScriptArbiter根据配置它的脚本的结果做出决定。

对于Spring Boot用户，提供了一个名为SpringProfile的仲裁器。指定的概要文件由Spring的 Environment.acceptsProfiles() 方法评估，因此它支持的任何表达式都可以用作name属性。

当Spring配置文件为“dev”或“staging”时，这个例子将使用控制台Appender，当活动配置文件为“prod”时，这个例子将使用列表Appender。

自动配置 Automatic Configuration

Log4j能够在初始化期间自动配置自身。当Log4j启动时，它将找到所有的ConfigurationFactory插件，并按照从高到低的加权顺序排列它们。

在交付时，Log4j包含四个ConfigurationFactory实现:一个用于JSON，一个用于YAML，一个用于属性，一个用于XML。

  • Log4j将检查“log4j2”。如果设置了，将尝试使用与文件扩展名匹配的ConfigurationFactory加载配置。注意，这并不局限于本地文件系统上的某个位置，它可能包含一个URL。

  • 如果没有设置系统属性，那么propertiesconfigurationfactory将查找log4j2-test。类路径中的属性。

  • 如果没有找到这样的文件，YAML ConfigurationFactory将查找log4j2-test。Yaml或log4j2-test。类路径中的Yml。

  • 如果没有找到这样的文件，JSON ConfigurationFactory将查找log4j2-test。Json或log4j2-test。类路径中的JSN。

  • 如果没有找到这样的文件，XML ConfigurationFactory将在类路径中查找log4j2-test.xml。

  • 如果无法找到测试文件，那么ConfigurationFactory将查找log4j2。类路径上的属性。

  • 如果无法找到属性文件，YAML ConfigurationFactory将查找log4j2。Yaml或log4j2。类路径上的Yml。

  • 如果无法找到YAML文件，则JSON ConfigurationFactory将查找log4j2。Json或log4j2。类路径上的JSN。

  • 如果无法找到JSON文件，XML ConfigurationFactory将尝试在类路径上找到log4j2.xml。

  • 如果找不到配置文件，则使用DefaultConfiguration。这将导致日志记录输出到控制台。

一个名为MyApp的使用log4j的示例应用程序可以用来说明如何做到这一点。

import com.foo.Bar;
 
// Import log4j classes.
import org.apache.logging.log4j.Logger;
import org.apache.logging.log4j.LogManager;
 
public class MyApp {
 
    // Define a static logger variable so that it references the
    // Logger instance named "MyApp".
    private static final Logger logger = LogManager.getLogger(MyApp.class);
 
    public static void main(final String... args) {
 
        // Set up a simple configuration that logs on the console.
 
        logger.trace("Entering application.");
        Bar bar = new Bar();
        if (!bar.doIt()) {
            logger.error("Didn't do it.");
        }
        logger.trace("Exiting application.");
    }
}

MyApp首先导入log4j相关的类。然后，它定义了一个名为MyApp的静态记录器变量，该变量恰好是类的完全限定名。

MyApp使用在 com.foo.Bar 中定义的Bar类。

package com.foo;
import org.apache.logging.log4j.Logger;
import org.apache.logging.log4j.LogManager;
 
public class Bar {
  static final Logger logger = LogManager.getLogger(Bar.class.getName());
 
  public boolean doIt() {
    logger.entry();
    logger.error("Did it again!");
    return logger.exit(false);
  }
}

如果无法找到配置文件，Log4j将提供默认配置。DefaultConfiguration类中提供的默认配置将设置:

一个连接到根记录器的ConsoleAppender。

将PatternLayout设置为模式 "%d{HH:mm:ss.SSS} [%t] %-5level %logger{36} - %msg%n" 附加到控制台appender

注意，默认情况下，Log4j将根记录器分配给Level.ERROR。

MyApp的输出类似于:

17:13:01.540 [main] ERROR com.foo.Bar - Did it again!
17:13:01.540 [main] ERROR MyApp - Didn't do it.

如前所述，Log4j将首先尝试从配置文件配置自身。

相当于默认值的配置如下所示:

将上面的文件作为log4j2.xml放入类路径后，您将得到与上面列出的结果相同的结果。将根级别更改为trace将导致类似于以下结果:

17:13:01.540 [main] TRACE MyApp - Entering application.
17:13:01.540 [main] TRACE com.foo.Bar - entry
17:13:01.540 [main] ERROR com.foo.Bar - Did it again!
17:13:01.540 [main] TRACE com.foo.Bar - exit with (false)
17:13:01.540 [main] ERROR MyApp - Didn't do it.
17:13:01.540 [main] TRACE MyApp - Exiting application.

注意，使用默认配置时禁用状态日志记录。

来自URI的配置

当log4j2。configurationFile引用URL, Log4j将首先确定URL是否使用文件协议引用文件。

如果是这样，Log4j将验证文件URL是否有效，并按照前面描述的继续处理。

如果它包含一个协议而不是文件，那么Log4j将检查log4j2.Configuration的值。

allowedProtocols系统属性。如果提供的列表包含指定的协议，那么Log4j将使用URI来定位指定的配置文件。

否则将抛出异常并记录错误消息。如果没有为system属性提供值，它将默认为“https, file, jar”。

可以通过将系统属性值设置为“_none”来阻止使用除“file”之外的任何协议。此值将是一个无效的协议，因此不能与可能存在的任何自定义协议冲突。

Log4j支持访问需要身份验证的远程url。Log4j支持开箱即用的基本身份验证。如果“log4j2.Configuration. conf”用户名和log4j2.Configuration。

指定密码，这些值将用于执行身份验证。如果密码是加密的，可以通过在log4j2.Configuration中指定完全限定类名来提供自定义密码解密器。

password解密系统属性。可以通过设置log4j2.Configuration来使用自定义AuthenticationProvider。

authenticationProvider系统属性设置为提供程序的完全限定类名。

可加性 Additivity

也许需要从com.foo.Bar之外的所有内容中消除所有TRACE输出。

仅仅更改日志级别是无法完成任务的。

相反，解决方案是在配置中添加一个新的记录器定义:

使用此配置，将记录来自com.foo.Bar的所有日志事件，而只记录来自所有其他组件的错误事件。

在前面的示例中，来自com.foo.Bar的所有事件仍然被写入控制台。这是因为com.foo.Bar的记录器没有配置任何appender，而它的父记录器配置了。

实际上，下面的配置

结果如下：

17:13:01.540 [main] TRACE com.foo.Bar - entry
17:13:01.540 [main] TRACE com.foo.Bar - entry
17:13:01.540 [main] ERROR com.foo.Bar - Did it again!
17:13:01.540 [main] TRACE com.foo.Bar - exit (false)
17:13:01.540 [main] TRACE com.foo.Bar - exit (false)
17:13:01.540 [main] ERROR MyApp - Didn't do it.

注意，来自 com.foo.Bar 的跟踪消息出现了两次。

这是因为首先使用与logger com.foo.Bar 关联的appender，它将第一个实例写入控制台。

接下来， com.foo.Bar 的父类，在本例中是根记录器，被引用。

然后将事件传递给其附加程序，该附加程序也写入控制台，从而产生第二个实例。

这被称为可加性。虽然加法可以是一个非常方便的功能(如在前面的第一个示例中，不需要配置appender引用)，但在许多情况下，这种行为被认为是不可取的，因此可以通过将日志记录器上的additivity属性设置为false来禁用它:

一旦事件到达将其相加性设置为false的记录器，该事件将不会传递给它的任何父记录器，无论它们的相加性设置如何。

自动重新配置 Automatic Reconfiguration

当从文件配置时，Log4j能够自动检测对配置文件的更改并重新配置自身。

如果在配置元素上指定了monitorInterval属性并将其设置为非零值，那么在下一次评估和/或记录日志事件时将检查该文件，并且自上次检查以来已经过了monitorInterval。

下面的示例显示了如何配置属性，以便在至少30秒之后才检查配置文件是否有更改。

最小间隔为5秒。

当从文件配置时，Log4j能够自动检测对配置文件的更改并重新配置自身。

如果在配置元素上指定了monitorInterval属性并将其设置为非零值，那么在下一次评估和/或记录日志事件时将检查该文件，并且自上次检查以来已经过了monitorInterval。

下面的示例显示了如何配置属性，以便在至少30秒之后才检查配置文件是否有更改。最小间隔为5秒。



...

Chainsaw可以自动处理您的日志文件(发布appender配置)

Log4j提供了为所有基于文件的追加器以及基于套接字的追加器“发布”追加器配置细节的能力。例如，对于基于文件的appender，文件中的文件位置和模式布局包含在广告中。Chainsaw和其他外部系统可以发现这些广告，并使用这些信息智能地处理日志文件。

广告公开的机制以及广告格式是特定于每个Advertiser实现的。想要与特定的广告人实现工作的外部系统必须了解如何定位广告配置以及广告的格式。例如，一个'database' Advertiser可能在一个数据库表中存储配置细节。外部系统可以读取该数据库表，以便发现文件位置和文件格式。

Log4j提供了一个Advertiser实现，一个'multicastdns' Advertiser，它使用JmDNS库通过IP多播发布appender配置细节。

Chainsaw自动发现log4j的multicastdns生成的广告，并在Chainsaw的Zeroconf选项卡中显示这些发现的广告(如果jmdns库在Chainsaw的类路径中)。要开始解析和跟踪广告中提供的日志文件，只需双击Chainsaw的Zeroconf选项卡中的广告条目。目前，Chainsaw只支持FileAppender广告。

通告一个appender配置:

将JmDNS库从JmDNS GitHub Releases中添加到应用程序类路径中
将配置元素的'advertiser'属性设置为'multicastdns'
将appender元素的'advertise'属性设置为'true'
如果发布基于fileappender的配置，则将appender元素上的'advertiseURI'属性设置为适当的URI
基于fileappender的配置需要在appender上指定一个额外的'advertiseURI'属性。'advertiseURI'属性为Chainsaw提供了如何访问文件的信息。例如，链锯可以通过ssh/sftp远程访问文件，指定Commons VFS (https://commons.apache.org/proper/commons-vfs/) sftp:// URI;如果通过web服务器访问文件，可以使用http:// URI;如果从本地运行的链锯实例访问文件，可以指定file:// URI。

下面是一个启用广告的appender配置示例，本地运行的Chainsaw可以使用它来自动跟踪日志文件(注意file://advertiseuri):

请注意，您必须将JmDns库从https://jmdns.sourceforge.net添加到您的应用程序类路径中，以便使用'multicastdns'广告器进行广告(advertiser)



...


  
  ...

配置语法 Configuration Syntax

从2.9版本开始，出于安全原因，Log4j不处理XML文件中的DTD。如

果希望将配置拆分到多个文件中，请使用XInclude或Composite configuration。

正如前面的示例以及后面的示例所示，Log4j允许您轻松地重新定义日志记录行为，而无需修改应用程序。

可以禁用应用程序的某些部分的日志记录，只在满足特定条件时记录日志，例如为特定用户执行的操作，将输出路由到Flume或日志报告系统等。要做到这一点，需要理解配置文件的语法。

XML文件中的配置元素接受以下几个属性:

Attribute NameDescription
advertiser(可选)广告插件名称，用于发布单个FileAppender或SocketAppender配置。提供的唯一广告插件是“multicastdns”。
dest标准输出为"err"，标准输出为"out"，文件路径或URL。
monitorInterval在检查文件配置是否发生更改之前必须经过的最小时间(以秒为单位)。
name配置名称
packages不赞成使用packages属性，并将在Log4j 3.0中删除。应该使用Log4j注释处理器处理插件。一个逗号分隔的包名称列表，用于搜索插件。每个类加载器只加载插件一次，因此更改此值可能不会对重新配置产生任何影响。
schema标识类装入器定位用于验证配置的XML Schema的位置。仅当strict设置为true时有效。如果没有设置，则不会进行模式验证。
shutdownHook指定在JVM关闭时Log4j是否应该自动关闭。默认情况下，关机钩子是启用的，但可以通过将此属性设置为“disable”来禁用。
shutdownTimeout指定JVM关闭时appender和后台任务关闭的毫秒数。默认值为零，这意味着每个appender使用其默认超时，并且不等待后台任务。并不是所有的appender都会遵守这一点，这是一个暗示，而不是绝对保证关闭过程不会花费更长时间。将此值设置得太低会增加丢失尚未写入最终目的地的未完成日志事件的风险。看到LoggerContext。停止(长,java.util.concurrent.TimeUnit)。(如果shutdownHook设置为“disable”，则不使用。)
status应该记录到控制台的内部Log4j事件的级别。该属性的有效值为off、trace、debug、info、warn、error、fatal和all。Log4j将把有关初始化、滚动和其他内部操作的详细信息记录到状态记录器中。如果需要对log4j进行故障排除，设置status="trace"是您可以使用的首批工具之一。(或者，设置系统属性Log4j2 .debug也会将内部Log4j2日志记录打印到控制台，包括在找到配置文件之前发生的内部日志记录。)
strict允许使用严格的XML格式。在JSON配置中不支持。
verbose在加载插件时启用诊断信息。

使用JSON配置

除了XML之外，还可以使用JSON配置Log4j。JSON格式与简明的XML格式非常相似。

每个键代表一个插件的名称，与它相关联的键/值对是它的属性。如果一个键包含的值超过一个简单值，那么它本身就是从属插件。

在下面的例子中，ThresholdFilter, Console和PatternLayout都是插件，而Console插件将为其名称属性分配一个STDOUT值，ThresholdFilter将分配一个调试级别。

{ "configuration": { "status": "error", "name": "RoutingTest",
                     "packages": "org.apache.logging.log4j.test",
      "properties": {
        "property": { "name": "filename",
                      "value" : "target/rolling1/rollingtest-$${sd:type}.log" }
      },
    "ThresholdFilter": { "level": "debug" },
    "appenders": {
      "Console": { "name": "STDOUT",
        "PatternLayout": { "pattern": "%m%n" },
        "ThresholdFilter": { "level": "debug" }
      },
      "Routing": { "name": "Routing",
        "Routes": { "pattern": "$${sd:type}",
          "Route": [
            {
              "RollingFile": {
                "name": "Rolling-${sd:type}", "fileName": "${filename}",
                "filePattern": "target/rolling1/test1-${sd:type}.%i.log.gz",
                "PatternLayout": {"pattern": "%d %p %c{1.} [%t] %m%n"},
                "SizeBasedTriggeringPolicy": { "size": "500" }
              }
            },
            { "AppenderRef": "STDOUT", "key": "Audit"}
          ]
        }
      }
    },
    "loggers": {
      "logger": { "name": "EventLogger", "level": "info", "additivity": "false",
                  "AppenderRef": { "ref": "Routing" }},
      "root": { "level": "error", "AppenderRef": { "ref": "STDOUT" }}
    }
  }
}

注意，在RoutingAppender中，Route元素被声明为一个数组。这是有效的，因为每个数组元素都是一个Route组件。

这对于appenders和filters这样的元素不起作用，因为每个元素在简洁格式中都有不同的名称。

如果每个追加器或筛选器声明了一个名为“type”的属性，其中包含追加器的类型，则追加器和筛选器可以定义为数组元素。

下面的示例说明了这一点，以及如何将多个日志记录器声明为一个数组。

{ "configuration": { "status": "debug", "name": "RoutingTest",
                      "packages": "org.apache.logging.log4j.test",
      "properties": {
        "property": { "name": "filename",
                      "value" : "target/rolling1/rollingtest-$${sd:type}.log" }
      },
    "ThresholdFilter": { "level": "debug" },
    "appenders": {
      "appender": [
         { "type": "Console", "name": "STDOUT", "PatternLayout": { "pattern": "%m%n" }, "ThresholdFilter": { "level": "debug" }},
         { "type": "Routing",  "name": "Routing",
          "Routes": { "pattern": "$${sd:type}",
            "Route": [
              {
                "RollingFile": {
                  "name": "Rolling-${sd:type}", "fileName": "${filename}",
                  "filePattern": "target/rolling1/test1-${sd:type}.%i.log.gz",
                  "PatternLayout": {"pattern": "%d %p %c{1.} [%t] %m%n"},
                  "SizeBasedTriggeringPolicy": { "size": "500" }
                }
              },
              { "AppenderRef": "STDOUT", "key": "Audit"}
            ]
          }
        }
      ]
    },
    "loggers": {
      "logger": [
        { "name": "EventLogger", "level": "info", "additivity": "false",
          "AppenderRef": { "ref": "Routing" }},
        { "name": "com.foo.bar", "level": "error", "additivity": "false",
          "AppenderRef": { "ref": "STDOUT" }}
      ],
      "root": { "level": "error", "AppenderRef": { "ref": "STDOUT" }}
    }
  }
}

使用YAML配置

Log4j还支持将YAML用于配置文件。该结构遵循与XML和YAML配置格式相同的模式。

例如:

Configuration:
  status: warn
  name: YAMLConfigTest
  properties:
    property:
      name: filename
      value: target/test-yaml.log
  thresholdFilter:
    level: debug
  appenders:
    Console:
      name: STDOUT
      target: SYSTEM_OUT
      PatternLayout:
        Pattern: "%m%n"
    File:
      name: File
      fileName: ${filename}
      PatternLayout:
        Pattern: "%d %p %C{1.} [%t] %m%n"
      Filters:
        ThresholdFilter:
          level: error
 
  Loggers:
    logger:
      -
        name: org.apache.logging.log4j.test1
        level: debug
        additivity: false
        ThreadContextMapFilter:
          KeyValuePair:
            key: test
            value: 123
        AppenderRef:
          ref: STDOUT
      -
        name: org.apache.logging.log4j.test2
        level: debug
        additivity: false
        AppenderRef:
          ref: File
    Root:
      level: error
      AppenderRef:
        ref: STDOUT

属性文件的配置

从2.4版开始，Log4j现在支持通过属性文件进行配置。注意，属性语法与Log4j 1中使用的语法不同。与XML和JSON配置一样，属性配置根据插件和插件的属性来定义配置。

在2.6版本之前，属性配置要求您在具有这些名称的属性中以逗号分隔的列表列出追加器、过滤器和记录器的标识符。然后，每个组件都将被定义在以component.开头的属性集中。标识符不必与所定义的组件的名称匹配，但必须唯一地标识作为组件一部分的所有属性和子组件。如果标识符列表不存在，则标识符不得包含'.'。每个单独的组件必须有一个指定的“type”属性来标识该组件的插件类型。

从2.6版本开始，不再需要这个标识符列表，因为名称在第一次使用时被推断出来，但是如果希望使用更复杂的标识，仍然必须使用该列表。如果列表存在，它将被使用。

与基本组件不同，在创建子组件时，不能指定包含标识符列表的元素。相反，您必须定义包装器元素及其类型，如下面的滚动文件附加程序中的策略定义所示。然后定义包装器元素下面的每个子组件，就像下面定义TimeBasedTriggeringPolicy和SizeBasedTriggeringPolicy一样。

从2.17.2版本开始，rootLogger和logger。可以指定关键属性来设置要为该记录器创建的级别和零个或多个追加器引用。级别引用和追加引用由逗号分隔，逗号周围有可选的空白字符。下面的示例演示了在读取属性配置时如何展开简写。

appender.stdout.type = Console
# ... other appender properties
appender.file.type = File
# ... other appender properties
logger.app = INFO, stdout, file
logger.app.name = com.example.app
 
# is equivalent to:
# appender.stdout.type = Console
# appender.stdout.name = stdout
# ...
appender.file.type = File
appender.file.name = file
# ...
logger.app.name = com.example.app
logger.app.level = INFO
logger.app.appenderRef.$1.ref = stdout
logger.app.appenderRef.$2.ref = file

属性配置文件支持advertiser、monitorInterval、name、packages、shutdownHook、shutdownTimeout、status、verbose和dest属性。

有关这些属性的定义，请参见配置语法。

status = error
dest = err
name = PropertiesConfig
 
property.filename = target/rolling/rollingtest.log
 
filter.threshold.type = ThresholdFilter
filter.threshold.level = debug
 
appender.console.type = Console
appender.console.name = STDOUT
appender.console.layout.type = PatternLayout
appender.console.layout.pattern = %m%n
appender.console.filter.threshold.type = ThresholdFilter
appender.console.filter.threshold.level = error
 
appender.rolling.type = RollingFile
appender.rolling.name = RollingFile
appender.rolling.fileName = ${filename}
appender.rolling.filePattern = target/rolling2/test1-%d{MM-dd-yy-HH-mm-ss}-%i.log.gz
appender.rolling.layout.type = PatternLayout
appender.rolling.layout.pattern = %d %p %C{1.} [%t] %m%n
appender.rolling.policies.type = Policies
appender.rolling.policies.time.type = TimeBasedTriggeringPolicy
appender.rolling.policies.time.interval = 2
appender.rolling.policies.time.modulate = true
appender.rolling.policies.size.type = SizeBasedTriggeringPolicy
appender.rolling.policies.size.size=100MB
appender.rolling.strategy.type = DefaultRolloverStrategy
appender.rolling.strategy.max = 5
 
logger.rolling = debug, RollingFile
logger.rolling.name = com.example.my.app
logger.rolling.additivity = false
 
rootLogger = info, STDOUT
 
# or using a grouping element:
# rootLogger.level = info
# rootLogger.appenderRef.stdout.ref = STDOUT

配置 Logger

在尝试配置日志记录器之前，了解它们在Log4j中的工作方式至关重要。

如果需要更多信息，请参考Log4j架构。在不理解这些概念的情况下尝试配置Log4j将导致挫折。

使用logger元素配置LoggerConfig。logger元素必须指定一个name属性，通常指定一个level属性，还可以指定一个additivity属性。该级别可以配置为TRACE、DEBUG、INFO、WARN、ERROR、ALL或OFF。

如果没有指定级别，则默认为ERROR。可加性属性的值可以为true或false。如果省略该属性，将使用默认值true。

捕获位置信息(类名、文件名、方法名和调用者的行号)可能很慢。Log4j试图通过减少堆栈的大小来优化这一点，堆栈必须遍历才能找到日志方法的调用者。它通过确定可能被访问的任何组件是否需要位置信息来实现这一点。如果将日志记录器配置在trace或debug这样的级别，并期望在Appender引用或Appender上过滤大多数日志，那么即使日志事件将被丢弃，Log4j也会计算位置信息，这可能会导致性能问题。要禁用此行为，可以在LoggerConfig上将inclelocation属性设置为false。这将导致Log4j延迟计算位置信息，直到绝对必要的时候。

LoggerConfig(包括根LoggerConfig)可以配置一些属性，这些属性将被添加到从ThreadContextMap复制的属性中。这些属性可以被Appenders, Filters, Layouts等引用，就像它们是ThreadContext Map的一部分一样。属性可以包含变量，这些变量可以在解析配置时解析，也可以在记录每个事件时动态解析。有关使用变量的更多信息，请参见属性替换。

LoggerConfig也可以配置一个或多个AppenderRef元素。引用的每个appender都将与指定的LoggerConfig相关联。如果在LoggerConfig上配置了多个appender，则在处理日志事件时调用其中的每个appender。

每个配置都必须有一个根日志记录器。如果没有配置，将使用缺省的根LoggerConfig，它的级别为ERROR，并附加了一个控制台附加程序。

根记录器和其他记录器之间的主要区别是

  1. 根日志记录器没有name属性。

  2. 根日志记录器不支持additivity属性，因为它没有父属性。

配置输出源

可以使用特定的appender插件名称来配置appender，也可以使用appender元素和包含appender插件名称的type属性来配置appender。

此外，每个追加器必须有一个指定值的name属性，该值在追加器集合中是唯一的。如前一节所述，日志记录器将使用该名称来引用appender。

大多数appeners还支持要配置的布局(同样可以使用特定布局插件的名称作为元素来指定，或者使用“layout”作为元素名称以及包含布局插件名称的type属性)。

各种appender将包含其他属性或元素，这些属性或元素是它们正常工作所必需的。

配置过滤器

Log4j允许在以下4个地方指定过滤器:

  • 与appender、logger和properties元素处于同一级别。这些过滤器可以在事件传递给LoggerConfig之前接受或拒绝事件。

  • 在记录器元素中。这些过滤器可以接受或拒绝特定记录器的事件。

  • 在appender元素中。这些筛选器可以阻止或导致事件由附加程序处理。

  • 在追加引用元素中。这些过滤器用于确定Logger是否应该将事件路由到appender。

虽然只能配置一个过滤器元素，但该元素可以是表示CompositeFilter的过滤器元素。

filters元素允许在其中配置任意数量的过滤器元素。下面的例子展示了如何在ConsoleAppender上配置多个过滤器。



  
    target/test.log
  
  
 
  
    
      
    
    
      
      
      
        
        
      
    
    
      
        %d %p %C{1.} [%t] %m%n
      
    
  
 
  
    
      
        
      
      
    
 
    
      ${sys:user.name}

属性替换 Property Substitution

Log4j 2支持在配置中指定令牌作为对其他地方定义的属性的引用。

其中一些属性将在解释配置文件时解析，而其他属性可能会传递给组件，在运行时对其进行评估。

为了实现这一点，Log4j使用Apache Commons Lang的StrSubstitutor和StrLookup类的变体。

以类似于Ant或Maven的方式，这允许使用配置本身中声明的属性解析声明为 ${name} 的变量。

例如，下面的示例显示了作为属性声明的滚动文件附加程序的文件名。



  
    target/rolling1/rollingtest-$${sd:type}.log
  
  
 
  
    
      
      
    
    
      
        
          
            
              %d %p %c{1.} [%t] %m%n

虽然这很有用，但是属性可以从更多的地方产生。为了适应这一点，Log4j还支持语法 ${prefix:name}，其中前缀标识告诉Log4j应该在特定上下文中计算变量名。

有关更多详细信息，请参阅查找手册页。

Log4j内置的上下文是:

PrefixContext
base64Base64编码的数据。格式为 ${base64:Base64_encoded_data}。例如: ${base64:SGVsbG8gV29ybGQhCg==} 产生Hello World!
bundle资源包。格式为${bundle:BundleName:BundleKey}。包名遵循包命名约定，例如:${bundle:com.domain.Messages:MyKey}。
ctxThread Context Map (MDC) 线程上下文
date使用指定格式插入当前日期和/或时间
env系统环境变量。格式为${env:ENV_NAME}和${env:ENV_NAME:-default_value}。
jndi默认JNDI上下文中设置的值。(需要系统属性log4j2。enablejndillookup设置为true。)
jvmrunargs通过JMX访问的JVM输入参数，但不是主参数;看到RuntimeMXBean.getInputArguments()。Android上不可用。
log4jLog4j配置属性。表达式${log4j:configLocation}和${log4j:configParentLocation}分别提供了log4j配置文件及其父文件夹的绝对路径。
main使用MapLookup.setMainArguments(String[])设置的值
mapA value from a MapMessage
sdStructuredDataMessage中的值。键“id”将返回StructuredDataId的名称，但不包含企业编号。键“type”将返回消息类型。其他键将从Map中检索单个元素。
sys系统属性。格式为 ${sys:some.property} 和 ${sys:some.property:-default_value}。

默认属性

可以在配置文件中声明默认的属性映射，方法是直接在configuration元素之后、在任何logger、Filters、Appenders等声明之前放置Properties元素。

如果无法在指定的查找中找到该值，则将使用默认属性映射中的值。默认映射预先填充了“hostName”的值，这是当前系统的主机名或IP地址，“contextName”with是当前日志上下文的值。查看本节中使用Properties元素的许多地方的示例。

默认属性也可以通过使用语法 ${lookupName:key:-defaultValue} 在查找中指定。

在某些情况下，键可能包含一个前导 -。

在这种情况下，必须包含转义字符，例如 ${main:\--file:-app.properties}。

这将使用mainmaploulookup查找名为——file的键。如果没有找到关键字，那么app.properties将被用作默认值。

启用消息模式查找

处理消息(默认情况下)不使用查找，例如，如果您定义了 FOO_BAR ，

那么 logger.info("${foo.bar}") 将输出 ${foo.bar}。而不是FOO_BAR。

您可以通过使用 %m{lookups} 定义消息模式来启用消息模式查找。

查找具有多个前导'$'字符的变量

StrLookup处理的一个有趣特性是，当每次解析变量时用多个前导“$”字符声明变量引用时，前导“$”被简单地删除。

在前面的例子中，“Routes”元素能够在运行时解析该变量。为此，将前缀值指定为具有两个前导'$'字符的变量。

当第一次处理配置文件时，第一个'$'字符被删除。

因此，当Routes元素在运行时求值时，变量声明“${sd:type}”会导致检查事件是否存在StructuredDataMessage，如果存在，则将其type属性的值用作路由键。并非所有元素都支持在运行时解析变量。

这样做的组件将在其文档中专门调用它。

如果在与前缀关联的查找中没有找到键的值，则将使用配置文件中属性声明中与该键关联的值。如果没有找到值，则将变量声明作为值返回。默认值可以通过以下方式在配置中声明:



  
    Audit
  
  ...

作为脚注，值得指出的是，在处理配置时，也不会计算RollingFile appender声明中的变量。

这仅仅是因为整个RollingFile元素的解析被延迟到匹配发生时。更多信息请参见RoutingAppender。

脚本 Scripts

Log4j为在其某些组件中使用的JSR 223脚本语言提供了支持。可以使用任何支持JSR 223脚本引擎的语言。语言和绑定的列表可以在脚本引擎网站上找到。

然而，这里列出的一些语言，如JavaScript、Groovy和Beanshell，直接支持JSR 223脚本框架，只需要安装该语言的jar。

从Log4j 2.17.2开始，支持的语言必须在log4j2.Script中指定为逗号分隔的列表。enablellanguages系统属性。

支持使用脚本的组件是通过允许在其上配置 、 或 `` 元素来实现的。

脚本元素包含脚本的名称、脚本的语言和脚本文本。scriptFile元素包含脚本的名称、位置、语言、字符集，以及是否应该监视该文件的更改。

scriptRef元素包含在 `` 配置元素中定义的脚本的名称。脚本的名称用于存储脚本及其ScriptEngine，因此每次需要运行脚本时都可以快速找到它。

虽然该名称不是必需的，但提供它将有助于在脚本运行时调试问题。语言必须在脚本元素上提供，并且必须指定出现在下一节中描述的Configuration状态日志中的语言名称之一。

如果没有在scriptFile元素上指定语言，那么语言将由脚本路径的文件扩展名决定。如果请求文件监视，则只有在配置元素上指定了非零monitorInterval时才启用它。该间隔将用于检查文件中的更改。

如果Configuration元素上的status属性被设置为DEBUG，那么当前安装的脚本引擎列表及其属性将被列出。

尽管有些引擎可能会说它们不是线程安全的，但Log4j会采取措施，确保如果引擎宣布它不是线程安全的，脚本将以线程安全的方式运行。

2015-09-27 16:13:22,925 main DEBUG Installed script engines
2015-09-27 16:13:22,963 main DEBUG AppleScriptEngine Version: 1.1, Language: AppleScript, Threading: Not Thread Safe,
            Compile: false, Names: {AppleScriptEngine, AppleScript, OSA}
2015-09-27 16:13:22,983 main DEBUG Groovy Scripting Engine Version: 2.0, Language: Groovy, Threading: MULTITHREADED,
            Compile: true, Names: {groovy, Groovy}
2015-09-27 16:13:23,030 main DEBUG BeanShell Engine Version: 1.0, Language: BeanShell, Threading: MULTITHREADED,
            Compile: true, Names: {beanshell, bsh, java}
2015-09-27 16:13:23,039 main DEBUG Mozilla Rhino Version: 1.7 release 3 PRERELEASE, Language: ECMAScript, Threading: MULTITHREADED,
            Compile: true, Names: {js, rhino, JavaScript, javascript, ECMAScript, ecmascript}

当脚本执行时，将为它们提供一组变量，这些变量将允许它们完成期望执行的任何任务。有关脚本可用的变量列表，请参阅各个组件的文档。

支持脚本的组件期望将返回值传递回调用Java代码。

对于一些脚本语言来说，这不是问题，但是Javascript不允许返回语句，除非它在函数中。

但是，Javascript将返回脚本中执行的最后一条语句的值。因此，如下所示的代码将产生期望的行为。

var result;
if (logEvent.getLoggerName().equals("JavascriptNoLocation")) {
    result = "NoLocation";
} else if (logEvent.getMarker() != null && logEvent.getMarker().isInstanceOf("FLOW")) {
    result = "Flow";
}
result;

关于 Beanshell 的特别提示

如果JSR 223脚本引擎支持编译它们的脚本，就应该标识它们支持Compilable接口。Beanshell这样做。

但是，无论何时调用编译方法，它都会抛出错误(而不是异常)。Log4j捕捉到这一点，但是当它尝试编译每个Beanshell脚本时，将记录如下所示的警告。然后在每次执行时解释所有Beanshell脚本。

2015-09-27 16:13:23,095 main DEBUG Script BeanShellSelector is compilable
2015-09-27 16:13:23,096 main WARN Error compiling script java.lang.Error: unimplemented
            at bsh.engine.BshScriptEngine.compile(BshScriptEngine.java:175)
            at bsh.engine.BshScriptEngine.compile(BshScriptEngine.java:154)
            at org.apache.logging.log4j.core.script.ScriptManager$MainScriptRunner.(ScriptManager.java:125)
            at org.apache.logging.log4j.core.script.ScriptManager.addScript(ScriptManager.java:94)

XInclude

XML配置文件可以使用XInclude包含其他文件。

下面是一个示例log4j2.xml文件，其中包括另外两个文件:



  
    xinclude-demo.log

log4j-xinclude-appenders.xml:



  
    
  
  
    
      %d %p %C{1.} [%t] %m%n

log4j-xinclude-loggers.xml:

组合配置

Log4j允许使用多个配置文件，方法是将它们指定为Log4j上以逗号分隔的文件路径列表。

或者，当使用url时，通过添加次要配置位置作为名为“override”的查询参数。可以通过指定一个实现log4j上的MergeStrategy接口的类来控制合并逻辑。

mergeStrategy财产。默认的合并策略将使用以下规则合并文件:

1） 全局配置属性聚合在一起，在以后的配置中替换以前的配置，但有以下例外:

将使用最高的状态级别
将使用大于0的最小monitorInterval
包之间用逗号连接

2） 聚合来自所有配置的属性。重复的属性将替换以前配置中的属性。

3） 如果定义了多个过滤器，则在CompositeFilter下聚合过滤器。由于筛选器没有命名，因此可能存在重复项。

4）脚本和ScriptFile引用被聚合。重复的定义将替换以前配置中的定义。

5） appender是聚合的。具有相同名称的Appender将被后续配置中的Appender替换，包括Appender的所有子组件。

6）记录器都是聚合的。日志记录器属性被单独合并，重复的属性被以后的配置中的属性所替换。Logger上的Appender引用被聚合，重复的引用将被后续配置中的引用替换。如果定义了多个过滤器，则Logger上的过滤器将聚合在CompositeFilter下。由于筛选器没有命名，因此可能存在重复项。Appender引用下的过滤器取决于它们的父Appender引用是保留还是丢弃。

Status Messages

给不耐烦的人的故障排除提示:

从log4j-2.9开始，如果系统属性log4j2.debug定义为空或其值等于true(忽略大小写)，log4j2将把所有内部日志打印到控制台。

在log4j-2.9之前，有两个地方可以控制内部日志记录:

在找到配置之前，可以使用系统属性org.apache.logging.log4j.simplelog.StatusLogger.level控制状态记录器级别。
找到配置后，可以在配置文件中使用"status"属性控制状态记录器级别，例如: configuration status="trace" 。

正如我们希望能够诊断应用程序中的问题一样，经常需要能够诊断日志配置或已配置组件中的问题。由于没有配置日志记录，因此在初始化期间不能使用“正常”日志记录。

此外，appender中的正常日志记录可能会创建无限递归，Log4j将检测到这种递归事件，并导致递归事件被忽略。

为了满足这种需求，Log4j 2 API包含了一个StatusLogger。

组件声明StatusLogger的实例如下:

正如我们希望能够诊断应用程序中的问题一样，经常需要能够诊断日志配置或已配置组件中的问题。

由于没有配置日志记录，因此在初始化期间不能使用“正常”日志记录。

此外，appender中的正常日志记录可能会创建无限递归，Log4j将检测到这种递归事件，并导致递归事件被忽略。

为了满足这种需求，Log4j 2 API包含了一个StatusLogger。

组件声明StatusLogger的实例如下:

protected final static Logger logger = StatusLogger.getLogger();

由于StatusLogger实现了Log4j 2 API的Logger接口，因此可以使用所有正常的Logger方法。

在配置Log4j时，有时需要查看生成的状态事件。这可以通过向配置元素添加状态属性来实现，也可以通过设置“Log4jDefaultStatusLevel”系统属性来提供默认值。

status属性的取值为trace、debug、info、warn、error和fatal。

下面的配置将状态属性设置为 debug。



  
    target/rolling1/rollingtest-$${sd:type}.log
  
  
 
  
    
      
      
    
    
      
        
          
            
              %d %p %c{1.} [%t] %m%n

启动时：

2011-11-23 17:08:00,769 DEBUG Generated plugins in 0.003374000 seconds
2011-11-23 17:08:00,789 DEBUG Calling createProperty on class org.apache.logging.log4j.core.config.Property for element property with params(name="filename", value="target/rolling1/rollingtest-${sd:type}.log")
2011-11-23 17:08:00,792 DEBUG Calling configureSubstitutor on class org.apache.logging.log4j.core.config.PropertiesPlugin for element properties with params(properties={filename=target/rolling1/rollingtest-${sd:type}.log})
2011-11-23 17:08:00,794 DEBUG Generated plugins in 0.001362000 seconds
2011-11-23 17:08:00,797 DEBUG Calling createFilter on class org.apache.logging.log4j.core.filter.ThresholdFilter for element ThresholdFilter with params(level="debug", onMatch="null", onMismatch="null")
2011-11-23 17:08:00,800 DEBUG Calling createLayout on class org.apache.logging.log4j.core.layout.PatternLayout for element PatternLayout with params(pattern="%m%n", Configuration(RoutingTest), null, charset="null")
2011-11-23 17:08:00,802 DEBUG Generated plugins in 0.001349000 seconds
2011-11-23 17:08:00,804 DEBUG Calling createAppender on class org.apache.logging.log4j.core.appender.ConsoleAppender for element Console with params(PatternLayout(%m%n), null, target="null", name="STDOUT", ignoreExceptions="null")
2011-11-23 17:08:00,804 DEBUG Calling createFilter on class org.apache.logging.log4j.core.filter.ThresholdFilter for element ThresholdFilter with params(level="debug", onMatch="null", onMismatch="null")
2011-11-23 17:08:00,813 DEBUG Calling createRoute on class org.apache.logging.log4j.core.appender.routing.Route for element Route with params(AppenderRef="null", key="null", Node=Route)
2011-11-23 17:08:00,823 DEBUG Calling createRoute on class org.apache.logging.log4j.core.appender.routing.Route for element Route with params(AppenderRef="STDOUT", key="Audit", Node=Route)
2011-11-23 17:08:00,825 DEBUG Calling createRoutes on class org.apache.logging.log4j.core.appender.routing.Routes for element Routes with params(pattern="${sd:type}", routes={Route(type=dynamic default), Route(type=static Reference=STDOUT key='Audit')})
2011-11-23 17:08:00,827 DEBUG Calling createAppender on class org.apache.logging.log4j.core.appender.routing.RoutingAppender for element Routing with params(name="Routing", ignoreExceptions="null", Routes({Route(type=dynamic default),Route(type=static Reference=STDOUT key='Audit')}), Configuration(RoutingTest), null, null)
2011-11-23 17:08:00,827 DEBUG Calling createAppenders on class org.apache.logging.log4j.core.config.AppendersPlugin for element appenders with params(appenders={STDOUT, Routing})
2011-11-23 17:08:00,828 DEBUG Calling createAppenderRef on class org.apache.logging.log4j.core.config.plugins.AppenderRefPlugin for element AppenderRef with params(ref="Routing")
2011-11-23 17:08:00,829 DEBUG Calling createLogger on class org.apache.logging.log4j.core.config.LoggerConfig for element logger with params(additivity="false", level="info", name="EventLogger", AppenderRef={Routing}, null)
2011-11-23 17:08:00,830 DEBUG Calling createAppenderRef on class org.apache.logging.log4j.core.config.plugins.AppenderRefPlugin for element AppenderRef with params(ref="STDOUT")
2011-11-23 17:08:00,831 DEBUG Calling createLogger on class org.apache.logging.log4j.core.config.LoggerConfig$RootLogger for element root with params(additivity="null", level="error", AppenderRef={STDOUT}, null)
2011-11-23 17:08:00,833 DEBUG Calling createLoggers on class org.apache.logging.log4j.core.config.LoggersPlugin for element loggers with params(loggers={EventLogger, root})
2011-11-23 17:08:00,834 DEBUG Reconfiguration completed
2011-11-23 17:08:00,846 DEBUG Calling createLayout on class org.apache.logging.log4j.core.layout.PatternLayout for element PatternLayout with params(pattern="%d %p %c{1.} [%t] %m%n", Configuration(RoutingTest), null, charset="null")
2011-11-23 17:08:00,849 DEBUG Calling createPolicy on class org.apache.logging.log4j.core.appender.rolling.SizeBasedTriggeringPolicy for element SizeBasedTriggeringPolicy with params(size="500")
2011-11-23 17:08:00,851 DEBUG Calling createAppender on class org.apache.logging.log4j.core.appender.RollingFileAppender for element RollingFile with params(fileName="target/rolling1/rollingtest-Unknown.log", filePattern="target/rolling1/test1-Unknown.%i.log.gz", append="null", name="Rolling-Unknown", bufferedIO="null", immediateFlush="null", SizeBasedTriggeringPolicy(SizeBasedTriggeringPolicy(size=500)), null, PatternLayout(%d %p %c{1.} [%t] %m%n), null, ignoreExceptions="null")
2011-11-23 17:08:00,858 DEBUG Generated plugins in 0.002014000 seconds
2011-11-23 17:08:00,889 DEBUG Reconfiguration started for context sun.misc.Launcher$AppClassLoader@37b90b39
2011-11-23 17:08:00,890 DEBUG Generated plugins in 0.001355000 seconds
2011-11-23 17:08:00,959 DEBUG Generated plugins in 0.001239000 seconds
2011-11-23 17:08:00,961 DEBUG Generated plugins in 0.001197000 seconds
2011-11-23 17:08:00,965 WARN No Loggers were configured, using default
2011-11-23 17:08:00,976 DEBUG Reconfiguration completed

如果将status属性设置为error，则只会向控制台写入错误消息。

这使得排除配置错误成为可能。

例如，如果将上面的配置更改为将状态设置为error，并且记录器声明为:

下面的错误信息将会产生：

2011-11-24 23:21:25,517 ERROR Unable to locate appender Routng for logger EventLogger

应用程序可能希望将状态输出定向到其他目的地。这可以通过将dest属性设置为“err”来实现，以将输出发送到stderr或文件位置或URL。

这也可以通过确保配置状态设置为OFF，然后以编程方式配置应用程序来实现，例如:

StatusConsoleListener listener = new StatusConsoleListener(Level.ERROR);
StatusLogger.getLogger().registerListener(listener);

在Maven中测试

Maven可以在构建周期内运行单元测试和功能测试。

默认情况下，放置在src/test/resources中的任何文件都会自动复制到target/test-classes中，并在执行任何测试期间包含在类路径中。

因此，将log4j2-test.xml放入该目录将导致使用它而不是log4j2.xml或log4j2。可能存在的Json。

因此，在测试期间可以使用不同于在生产中使用的日志配置。

Log4j 2广泛使用的第二种方法是设置Log4j。在junit测试类中使用@BeforeClass注释的方法中的configurationFile属性。这将允许在测试期间使用任意命名的文件。

第三种方法(也被Log4j 2广泛使用)是使用LoggerContextRule JUnit测试规则，它为测试提供了额外的便利方法。

这需要将log4j-core test-jar依赖项添加到测试范围依赖项中。例如:

public class AwesomeTest {
    @Rule
    public LoggerContextRule init = new LoggerContextRule("MyTestConfig.xml");
 
    @Test
    public void testSomeAwesomeFeature() {
        final LoggerContext ctx = init.getLoggerContext();
        final Logger logger = init.getLogger("org.apache.logging.log4j.my.awesome.test.logger");
        final Configuration cfg = init.getConfiguration();
        final ListAppender app = init.getListAppender("List");
        logger.warn("Test message");
        final List events = app.getEvents();
        // etc.
    }
}

系统属性

Log4j文档引用了许多系统属性，这些属性可用于控制Log4j 2行为的各个方面。

下表列出了这些属性以及它们的默认值和它们所控制的内容的描述。

属性名称中的任何空格都是用于视觉流的，应该删除。

请注意，从Log4j 2.10开始，所有系统属性名称都已标准化，以遵循一致的命名方案。

虽然旧的属性名称仍然支持向后兼容，但建议更新配置以使用新样式。该系统是可扩展的，并通过PropertySource接口启用。

可以通过Java SE中的标准ServiceLoader机制添加其他属性源类。

属性可以被具有较低数字优先级的源覆盖 例如…(-100在100之前)。以下资源默认都是可用的:

属性资源优先级和描述

source优先级desc
Spring Boot Properties-100只有当Java应用程序使用Spring Boot并且存在log4j-spring模块时，才启用此属性源。它使用Spring环境来解析属性。
System Properties0所有属性都可以使用正常的系统属性模式进行设置。它们在常用的属性源中具有最低的数值优先级，并且可以覆盖属性文件或环境变量。如果是log4j2.system。properties文件在类路径上可用，其内容在Log4j启动时被导入Java系统属性。
log4j2.component.properties200在类路径中包含这个文件可以作为提供属性作为系统属性的替代方法。这是具有最高数字优先级的属性源，可用于提供系统管理员可以覆盖的默认值。

以下是可用的全局配置属性列表。请注意，与配置文件中可用的配置设置不同，每个JVM进程只能设置一次。

Log4j 2 global configuration properties

“属性名称”列包含属性文件和系统属性中使用的名称;环境变量为等效环境变量;和Legacy Property Name用于2.10之前的名称。

参考资料

https://logging.apache.org/log4j/2.x/manual/configuration.html

贡献者

binbin.hou
我是老马，期待与你的下次重逢
Copyright © 2025 老马啸西风