database.adoc

Database appenders

Log4j Core provides multiple appenders to send log events directly to your database.

Common concerns

Column mapping

Since relational databases and some NoSQL databases split data into columns, Log4j Core provides a reusable ColumnMapping configuration element to allow specifying the content of each column.

The Column Mapping element supports the following configuration properties:

Table 1. ColumnMapping configuration attributes

Attribute	Type	Default value	Description
Required
name	String		The name of the column.
Optional
columnType	Class<?>	String	It specifies the Java type that will be stored in the column. If set to: org.apache.logging.log4j.util.ReadOnlyStringMap org.apache.logging.log4j.spi.ThreadContextMap The column will be filled with the contents of the log event’s context map. org.apache.logging.log4j.spi.ThreadContextStack The column will be filled with the contents of the log event’s context stack. java.util.Date The column will be filled with the log event’s timestamp. For any other value: The log event will be formatted using the nested Layout. The resulting String will be converted to the specified type using a TypeConverter. See the plugin reference for a list of available type converters.
type	Class<?>	String	Deprecated: since 2.21.0 use columnType instead.
literal	String		If set, the value will be added directly in the insert statement of the database-specific query language. Warning This value is added as-is, without any validation. Never use user-provided data to determine its value.
parameter	String		It specifies the database-specific parameter marker to use. Otherwise, the default parameter marker for the database language will be used. Warning This value is added as-is, without any validation. Never use user-provided data to determine its value.
pattern	String		This is a shortcut configuration attribute to set the nested Layout element to a PatternLayout instance with the specified pattern property.
source	String	name	It specifies which key of a MapMessage will be stored in the column. This attribute is used only if: The nested Layout element is a MessageLayout. The message being logged is a MapMessage

Table 2. ColumnMapping nested elements

Type	Multiplicity	Description
Layout	zero or one	Formats the value to store in the column. See manual/layouts.adoc for more information.

Plugin reference for ColumnMapping

An example column mapping might look like this:

XML

Snippet from an example {antora-examples-url}/manual/appenders/database/column-mapping.xml[log4j2.xml]

link:example$manual/appenders/database/column-mapping.xml[role=include]

JSON

Snippet from an example {antora-examples-url}/manual/appenders/database/column-mapping.json[log4j2.json]

link:example$manual/appenders/database/column-mapping.json[role=include]

YAML

Snippet from an example {antora-examples-url}/manual/appenders/database/column-mapping.yaml[log4j2.yaml]

link:example$manual/appenders/database/column-mapping.yaml[role=include]

Properties

Snippet from an example {antora-examples-url}/manual/appenders/database/column-mapping.properties[log4j2.properties]

link:example$manual/appenders/database/column-mapping.properties[role=include]

1. A database-specific expression is added literally to the INSERT statement.

2. A manual/pattern-layout.adoc with the specified pattern is used for these columns. The uuid column is additionally converted into a java.util.UUID before being sent to the JDBC driver.

3. Three special column types are replaced with the log event timestamp, context map, and context stack.

4. A manual/json-template-layout.adoc is used to format this column.

5. If the global layout of the appender returns a MapMessage, the value for key resourceId will be put into the resource column.

Cassandra Appender

partial$manual/appender-deprecation.adoc

The Cassandra Appender writes its output to an Apache Cassandra database. The appender supports the following configuration properties:

Table 3. Cassandra Appender configuration attributes

Attribute	Type	Default value	Description
Required
name	String		The name of the Appender.
Optional
batched	boolean	false	Whether to use batch statements to write log messages to Cassandra.
batchType	BatchStatement.Type	LOGGED	The batch type to use when using batched writes.
bufferSize	int	0	The number of log messages to buffer or batch before writing. If 0, buffering is disabled.
clusterName	String		The name of the Cassandra cluster to connect to.
ignoreExceptions	boolean	true	If false, logging exception will be forwarded to the caller of the logging statement. Otherwise, they will be ignored.
keyspace	String		The name of the keyspace containing the table that log messages will be written to.
password	String		The password to use (along with the username) to connect to Cassandra.
table	String		The name of the table to write log messages to.
useClockForTimestampGenerator	boolean	false	Whether to use the configured org.apache.logging.log4j.core.util.Clock as a timestamp generator.
username	String		The username to use to connect to Cassandra. By default, no username or password is used.
useTls	boolean	true	Whether to use TLS/SSL to connect to Cassandra. This is false by default.

Table 4. Cassandra Appender nested elements

Type	Multiplicity	Description
Filter	zero or one	Allows filtering log events just before they are formatted and sent. See also appender filtering stage.
ColumnMapping	one or more	A list of column mapping configurations. The following database-specific restrictions apply: the name attribute must be a valid CQL identifier. the literal attribute must be a valid CQL term. the parameter attribute has a fixed value of ?.
SocketAddress	one or more	A list of Cassandra node addresses to connect to. If absent, localhost:9042 will be used. See Socket Addresses for the configuration syntax.

Additional runtime dependencies are required for using the Cassandra Appender:

partial$components/log4j-cassandra.adoc

{plugin-reference-marker} Plugin reference for Cassandra

Socket Addresses

The address of the Cassandra server is specified using the SocketAddress element, which supports the following configuration options:

Table 5. SocketAddress configuration attributes

Attribute	Type	Default value	Description
host	InetAddress	localhost	The host to connect to.
port	int	0	The port to connect to.

{plugin-reference-marker} Plugin reference for SocketAddress

Configuration examples

Here is an example Cassandra Appender configuration:

XML

Snippet from an example {antora-examples-url}/manual/appenders/database/cassandra.xml[log4j2.xml]

link:example$manual/appenders/database/cassandra.xml[role=include]

JSON

Snippet from an example {antora-examples-url}/manual/appenders/database/cassandra.json[log4j2.json]

link:example$manual/appenders/database/cassandra.json[role=include]

YAML

Snippet from an example {antora-examples-url}/manual/appenders/database/cassandra.yaml[log4j2.yaml]

link:example$manual/appenders/database/cassandra.yaml[role=include]

Properties

Snippet from an example {antora-examples-url}/manual/appenders/database/cassandra.properties[log4j2.properties]

link:example$manual/appenders/database/cassandra.properties[role=include]

1. Enables buffering. Messages are sent in batches of 10.

2. Multiple server addresses can be used.

3. An example of column mapping. See Column mapping for more details.

The example above uses the following table schema:

link:example$manual/appenders/database/cassandra.sql[role=include]

JDBC Appender

The JDBCAppender writes log events to a relational database table using standard JDBC. It can be configured to get JDBC connections from different connection sources.

If batch statements are supported by the configured JDBC driver and bufferSize is configured to be a positive number, then log events will be batched.

Note	The appender gets a new connection for each batch of log events. The connection source must be backed by a connection pool, otherwise the performance will suffer greatly.

Table 6. JDBC Appender configuration attributes

Attribute	Type	Default value	Description
Required
name	String		The name of the Appender.
tableName	String		The name of the table to use.
Optional
bufferSize	int	0	The number of log messages to batch before writing. If 0, batching is disabled.
ignoreExceptions	boolean	true	If false, logging exception will be forwarded to the caller of the logging statement. Otherwise, they will be ignored.
immediateFail	boolean	false	When set to true, log events will not wait to try to reconnect and will fail immediately if the JDBC resources are not available.
reconnectIntervalMillis	long	5000	If set to a value greater than 0, after an error, the JdbcDatabaseManager will attempt to reconnect to the database after waiting the specified number of milliseconds. If the reconnecting fails then an exception will be thrown and can be caught by the application if ignoreExceptions is set to false.

Table 7. JDBC Appender nested elements

Type	Multiplicity	Description
Filter	zero or one	Allows filtering log events just before they are formatted and sent. See also appender filtering stage.
ColumnMapping	zero or more	A list of column mapping configurations. The following database-specific restrictions apply: the name attribute must be a valid SQL identifier. the literal attribute must be a valid SQL term. the parameter attribute must be a valid SQL term containing a ? placeholder. Required, unless ColumnConfig is used.
ColumnConfig	zero or more	Deprecated: an older mechanism to define column mappings. {plugin-reference-marker} Plugin reference for ColumnConfig
ConnectionSource	one	It specifies how to retrieve JDBC Connection objects. See Connection Sources for more details.
Layout	zero or one	An optional Layout<? extends Message> implementation that formats a log event as log Message. If supplied MapMessages will be treated in a special way. See Map Message handling for more details.

{plugin-reference-marker} Plugin reference for JDBC

Connection Sources

When configuring the JDBC Appender, you must specify an implementation of ConnectionSource that the appender will use to get Connection objects.

{plugin-reference-marker} Plugin reference for ConnectionSource

The following connection sources are available out-of-the-box:

DataSource

This connection source uses JNDI to locate a JDBC DataSource.

Important

As of Log4j 2.17.0 you need to enable the DataSource connection source explicitly by setting the log4j2.enableJndiJdbc configuration property to true.

Table 8. DataSource configuration attributes

Attribute	Type	Default value	Description
jndiName	Name		It specifies the JNDI name of a JDBC DataSource. Only the java: JNDI protocol is supported. Required

{plugin-reference-marker} Plugin reference for DataSource

ConnectionFactory

This connection source can use any factory method. The method must:

• Be public and static.

• Have an empty parameter list.

• Return either Connection or DataSource.

Table 9. ConnectionFactory configuration attributes

Attribute	Type	Default value	Description
class	Class<?>		The fully qualified class name of the class containing the factory method. Required
method	String		The name of the factory method. Required

{plugin-reference-marker} Plugin reference for ConnectionFactory

DriverManager

This connection source uses DriverManager to directly create connections using a JDBC Driver.

Tip	This configuration source is useful during development, but we don’t recommend it in production. Unless the JDBC driver provides connection pooling, the performance of the appender will suffer. See PoolingDriver for a variant of this connection source that uses a connection pool.

Table 10. DriverManager configuration attributes

Attribute	Type	Default value	Description
connectionString	String		The driver-specific JDBC connection string. Required
driverClassName	String	autodetected	The fully qualified class name of the JDBC driver to use. JDBC 4.0 drivers can be automatically detected by DriverManager. See DriverManager for more details.
userName	String		The username to use to connect to the database.
password	String		The password to use to connect to the database.

Table 11. DriverManager nested elements

Type	Multiplicity	Description
Property	zero or more	A list of key/value pairs to pass to DriverManager. If supplied, the userName and password attributes will be ignored.

{plugin-reference-marker} Plugin reference for DriverManager

PoolingDriver

The PoolingDriver uses Apache Commons DBCP 2 to configure a JDBC connection pool.

Table 12. PoolingDriver configuration attributes

Attribute	Type	Default value	Description
connectionString	String		The driver-specific JDBC connection string. Required
driverClassName	String	autodetected	The fully qualified class name of the JDBC driver to use. JDBC 4.0 drivers can be automatically detected by DriverManager. See DriverManager for more details.
userName	String		The username to use to connect to the database.
password	String		The password to use to connect to the database.
poolName	String	example

Table 13. PoolingDriver nested elements

Type	Multiplicity	Description
Property	zero or more	A list of key/value pairs to pass to DriverManager. If supplied, the userName and password attributes will be ignored.
PoolableConnectionFactory	zero or one	Allows finely tuning the configuration of the DBCP 2 connection pool. The available parameters are the same as those provided by DBCP 2. See DBCP 2 configuration for more details. {plugin-reference-marker} Plugin reference for PoolableConnectionFactory

Additional runtime dependencies are required for using PoolingDriver:

partial$components/log4j-jdbc-dbcp2.adoc

{plugin-reference-marker} Plugin reference for PoolingDriver

Map Message handling

If the optional nested element of type Layout<? Extends Message> is provided, log events containing messages of type MapMessage will be treated specially. For each column mapping (except those containing literals) the source attribute will be used as key to the value in MapMessage that will be stored in column name.

Configuration examples

Here is an example JDBC Appender configuration:

XML

Snippet from an example {antora-examples-url}/manual/appenders/database/jdbc.xml[log4j2.xml]

link:example$manual/appenders/database/jdbc.xml[role=include]

JSON

Snippet from an example {antora-examples-url}/manual/appenders/database/jdbc.json[log4j2.json]

link:example$manual/appenders/database/jdbc.json[role=include]

YAML

Snippet from an example {antora-examples-url}/manual/appenders/database/jdbc.yaml[log4j2.yaml]

link:example$manual/appenders/database/jdbc.yaml[role=include]

Properties

Snippet from an example {antora-examples-url}/manual/appenders/database/jdbc.properties[log4j2.properties]

link:example$manual/appenders/database/jdbc.properties[role=include]

1. Enables buffering. Messages are sent in batches of 10.

2. A JNDI data source is used.

3. An example of column mapping. See Column mapping for more details.

The example above uses the following table schema:

link:example$manual/appenders/database/jdbc.sql[role=include]

JPA Appender

partial$manual/appender-deprecation.adoc

The JPA Appender writes log events to a relational database table using the Jakarta Persistence API 2.2. To use the appender, you need to:

• configure your JPA persistence unit. See Persistence configuration below.

• configure the JPA Appender. See Appender configuration below.

Important

Due to breaking changes in the underlying API, the JPA Appender cannot be used with Jakarta Persistence API 3.0 or later.

Persistence configuration

To store log events using JPA, you need to implement a JPA Entity that extends the AbstractLogEventWrapperEntity class. To help you with the implementation, Log4j provides a BasicLogEventEntity class that only lacks an identity field.

A simple AbstractLogEventWrapperEntity implementation might look like:

Snippet from a {antora-examples-url}/manual/appenders/database/LogEventEntity.java[LogEventEntity.java]

link:example$manual/appenders/database/LogEventEntity.java[role=include]

For performance reasons, we recommend creating a separate persistence unit for logging. This allows you to optimize the unit for logging purposes. The definition of the persistence unit should look like the example below:

link:example$manual/appenders/database/persistence.xml[role=include]

1. Specify you JPA provider.

2. A non-JTA source should be used for performance.

3. If your log event entity extends BasicLogEventEntity, you need to declare these converters.

4. Declare your log event entity.

5. Cache sharing should be set to NONE.

Appender configuration

The JPA appender supports these configuration options:

Table 14. JPA Appender configuration attributes

Attribute	Type	Default value	Description
Required
name	String		The name of the Appender.
tableName	String		The name of the table to use.
persistenceUnitName	String		The name of the persistence unit to use.
entityClassName	Class<?>		The fully qualified name of the entity class to use. The type must extend AbstractLogEventWrapperEntity.
Optional
bufferSize	int	0	The number of log messages to batch before writing. If 0, batching is disabled.
ignoreExceptions	boolean	true	If false, logging exception will be forwarded to the caller of the logging statement. Otherwise, they will be ignored.

Table 15. JPA Appender nested elements

Type	Multiplicity	Description
Filter	zero or one	Allows filtering log events just before they are formatted and sent. See also appender filtering stage.

Additional runtime dependencies are required for using the JPA Appender:

partial$components/log4j-jpa.adoc

{plugin-reference-marker} Plugin reference for JPA

Configuration examples

Using the persistence unit from section Persistence configuration, the JPA appender can be easily configured as:

XML

Snippet from an example {antora-examples-url}/manual/appenders/database/jpa.xml[log4j2.xml]

link:example$manual/appenders/database/jpa.xml[role=include]

JSON

Snippet from an example {antora-examples-url}/manual/appenders/database/jpa.json[log4j2.json]

link:example$manual/appenders/database/jpa.json[role=include]

YAML

Snippet from an example {antora-examples-url}/manual/appenders/database/jpa.yaml[log4j2.yaml]

link:example$manual/appenders/database/jpa.yaml[role=include]

Properties

Snippet from an example {antora-examples-url}/manual/appenders/database/jpa.properties[log4j2.properties]

link:example$manual/appenders/database/jpa.properties[role=include]

NoSQL Appender

The NoSQL Appender writes log events to a document-oriented NoSQL database using an internal lightweight provider interface. It supports the following configuration options:

Table 16. NoSQL Appender configuration attributes

Attribute	Type	Default value	Description
Required
name	String		The name of the Appender.
Optional
bufferSize	int	0	The number of log messages to batch before writing to the database. If 0, batching is disabled.
ignoreExceptions	boolean	true	If false, logging exception will be forwarded to the caller of the logging statement. Otherwise, they will be ignored.

Table 17. NoSQL Appender nested elements

Type	Multiplicity	Description
Filter	zero or one	Allows filtering log events just before they are formatted and sent. See also appender filtering stage.
KeyValuePair	Zero or more	Adds a simple key/value field to the NoSQL object. The value attribute of the pair supports runtime property substitution using the current event as context.
Layout	zero or one	An optional Layout<? extends MapMessage> implementation that formats a log event as MapMessage. See Formatting for more details.

{plugin-reference-marker} Plugin reference for NoSQL

Formatting

This appender transforms log events into NoSQL documents in two ways:

• If the optional Layout configuration element is provided, the MapMessage returned by the layout will be converted into its NoSQL document.

• Otherwise, a default conversion will be applied. You enhance the format with additional top level key/value pairs using nested KeyValuePair configuration elements.

  Click to see an example of default log event formatting

  link:example$manual/appenders/database/nosql-log-event.json[role=include]

Providers

The NoSQL Appender only handles the conversion of log events into NoSQL documents, and it delegates database-specific tasks to a NoSQL provider. NoSQL providers are Log4j plugins that implement the NoSqlProvider interface. Log4j Core currently provides the following providers:

• Multiple providers for different versions of the MongoDB database. See MongoDB Providers below for more details.

• A provider for the Apache CouchDB database. See Apache CouchDB provider below for more details.

MongoDB Providers

Starting with version 2.11.0, Log4j supplies providers for the MongoDB NoSQL database engine, based on the MongoDB synchronous Java driver. The choice of the provider to use depends on:

• the major version of the MongoDB Java driver your application uses: Log4j supports all major versions starting from version 2.

• the type of driver API used: either the Legacy API or the Modern API. See MongoDB documentation for the difference between APIs.

Note

The list of dependencies of your application provides a hint as to which driver API your application is using. If your application contains any one of these dependencies, it might use the Legacy API: org.mongodb:mongo-java-driver org.mongodb:mongodb-driver-legacy If you application only uses org.mongodb:mongodb-driver-sync, it uses the Modern API.

Warning

The version of the MongoDB Java driver is not the same as the version of the MongoDB server. See MongoDB compatibility matrix for more information.

In order to use a Log4j MongoDB appender you need to add the following dependencies to your application:

Table 18. MongoDB providers compatibility table

Driver version	Driver API	Log4j artifact	Notes
2.x	Legacy	log4j-mongodb2	Reached end-of-support. Last released version: 2.12.4
3.x	Legacy	log4j-mongodb3	Reached end-of-support. Last released version: 2.23.1
4.x	Modern	log4j-mongodb4
5.x or later	Modern	log4j-mongodb

Tip	If you are note sure, which implementation to choose, log4j-mongodb is the recommended choice.

MongoDb Provider (current)

The MongoDb provider is based on the current version of the MongoDB Java driver. It supports the following configuration options:

Table 19. MongoDb Provider configuration attributes

Attribute	Type	Default value	Description
connection	Connection String		It specifies the connection URI used to reach the server. Required
databaseName	string		It specifies the name of the database for the appender to use. The database name can also be specified in the connection URI. If both are provided, this databaseName attribute will be used. Required
collectionName	string		It specifies the name of the collection for the appender to use. For backward compatibility, the collection name can also be specified in the connection URI per ConnectionString of the MongoDB Java Driver. If both are provided, this collectionName attribute will be used. Required
capped	boolean	false	If true, a capped collection will be used.
collectionSize	long	512 MiB	It specifies the capped collection size of bytes.

Additional runtime dependencies are required to use the MongoDb provider:

partial$components/log4j-mongodb.adoc

{plugin-reference-marker} Plugin reference for MongoDb

MongoDb4 Provider (deprecated)

The log4j-mongodb4 module is deprecated in favor of the current MongoDB provider. It supports the following configuration attributes:

Table 20. MongoDb4 provider configuration attributes

Attribute	Type	Default value	Description
connection	ConnectionString		It specifies the connection URI used to reach the server. Required
capped	boolean	false	If true, a capped collection will be used.
collectionSize	long	512 MiB	It specifies the capped collection size of bytes.

Additional runtime dependencies are required to use the MongoDb4 provider:

partial$components/log4j-mongodb4.adoc

{plugin-reference-marker} Plugin reference for MongoDb4

Apache CouchDB provider

Warning

This provider is planned to be removed in the next major release! If you are using this library, please get in touch with the Log4j maintainers using the official support channels.

The CouchDb Provider allows using the NoSQL Appender with an Apache CouchDB database. The provider can be configured by:

• either providing some standard configuration attributes,

• or providing a factory method.

Table 21. CouchDb provider configuration attributes

Attribute	Type	Default value	Description
Standard configuration attributes
protocol	enumeration	http	It specifies the protocol to use to connect to the server. Can be one of: http https
server	String	localhost	The host name of the CouchDB server.
port	int	80 (http) 443 (https)	It specifies the TCP port to use.
databaseName	String		The name of the database to connect to.
username	String		The username for authentication.
password	String		The password for authentication.
Factory method configuration attributes
factoryClassName	Class<?>		The fully qualified class name that contains a factory method that returns either a CouchDbClient or CouchDbProperties object. The class must be public.
factoryMethodName	String		The name of the factory method. The method: Must be public and static. Have an empty parameter list. Returns either a CouchDbClient or CouchDbProperties object.

Additional runtime dependencies are required to use the CouchDb provider:

partial$components/log4j-couchdb.adoc

{plugin-reference-marker} Plugin reference for CouchDb

Configuration examples

To connect the NoSQL Appender to a MongoDB database, you only need to provide a connection string:

XML

Snippet from an example {antora-examples-url}/manual/appenders/database/nosql-mongo.xml[log4j2.xml]

link:example$manual/appenders/database/nosql-mongo.xml[role=include]

JSON

Snippet from an example {antora-examples-url}/manual/appenders/database/nosql-mongo.json[log4j2.json]

link:example$manual/appenders/database/nosql-mongo.json[role=include]

YAML

Snippet from an example {antora-examples-url}/manual/appenders/database/nosql-mongo.yaml[log4j2.yaml]

link:example$manual/appenders/database/nosql-mongo.yaml[role=include]

Properties

Snippet from an example {antora-examples-url}/manual/appenders/database/nosql-mongo.properties[log4j2.properties]

link:example$manual/appenders/database/nosql-mongo.properties[role=include]

Note

Make sure to not let org.bson, com.mongodb log to a MongoDB database on a DEBUG level, since that will cause recursive logging: XML Snippet from an example {antora-examples-url}/manual/appenders/database/nosql-mongo.xml[log4j2.xml] link:example$manual/appenders/database/nosql-mongo.xml[role=include] JSON Snippet from an example {antora-examples-url}/manual/appenders/database/nosql-mongo.json[log4j2.json] link:example$manual/appenders/database/nosql-mongo.json[role=include] YAML Snippet from an example {antora-examples-url}/manual/appenders/database/nosql-mongo.yaml[log4j2.yaml] link:example$manual/appenders/database/nosql-mongo.yaml[role=include] Properties Snippet from an example {antora-examples-url}/manual/appenders/database/nosql-mongo.properties[log4j2.properties] link:example$manual/appenders/database/nosql-mongo.properties[role=include] Remember to set the additivity configuration attribute to false.

A similar configuration for an Apache CouchDB database looks like:

XML

Snippet from an example {antora-examples-url}/manual/appenders/database/nosql-couch.xml[log4j2.xml]

link:example$manual/appenders/database/nosql-couch.xml[role=include]

JSON

Snippet from an example {antora-examples-url}/manual/appenders/database/nosql-couch.json[log4j2.json]

link:example$manual/appenders/database/nosql-couch.json[role=include]

YAML

Snippet from an example {antora-examples-url}/manual/appenders/database/nosql-couch.yaml[log4j2.yaml]

link:example$manual/appenders/database/nosql-couch.yaml[role=include]

Properties

Snippet from an example {antora-examples-url}/manual/appenders/database/nosql-couch.properties[log4j2.properties]

link:example$manual/appenders/database/nosql-couch.properties[role=include]

You can define additional fields to the NoSQL document using KeyValuePair elements, for example:

XML

Snippet from an example {antora-examples-url}/manual/appenders/database/nosql-mongo-keys.xml[log4j2.xml]

link:example$manual/appenders/database/nosql-mongo-keys.xml[role=include]

JSON

Snippet from an example {antora-examples-url}/manual/appenders/database/nosql-mongo-keys.json[log4j2.json]

link:example$manual/appenders/database/nosql-mongo-keys.json[role=include]

YAML

Snippet from an example {antora-examples-url}/manual/appenders/database/nosql-mongo-keys.yaml[log4j2.yaml]

link:example$manual/appenders/database/nosql-mongo-keys.yaml[role=include]

Properties

Snippet from an example {antora-examples-url}/manual/appenders/database/nosql-mongo-keys.properties[log4j2.properties]

link:example$manual/appenders/database/nosql-mongo-keys.properties[role=include]

1. This lookup is evaluated at configuration time and gives the time when Log4j was most recently reconfigured.

2. This lookup is evaluated at runtime and gives the current date. See runtime lookup evaluation for more details.