Configuring Logs¶
Introduction¶
All WSO2 products are shipped with Log4j2 logging capabilities, which generate server-side logs. The <MI_HOME>/conf/log4j2.properties
file governs how logging is performed by the server.
Java logging and Log4j2 integration
In addition to the logs from libraries that use Log4j2, all logs from libraries that use the Java logging framework are also visible in the same log files. That is, when Java logging is enabled in Carbon, only the Log4j2 appenders will write to the log files. If the Java Logging Handlers have logs, these logs will be delegated to the log events of the corresponding Log4j2 appenders. A Pub/Sub registry pattern implementation has been used in the latter mentioned scenario to plug the handlers and appenders. The following default log4j2 appenders in the log4j2.properties
file are used for this implementation:
org.wso2.carbon.logging.appenders.CarbonConsoleAppender
org.wso2.carbon.logging.appenders.CarbonDailyRollingFileAppender
There are three main components when configuring Log4j2: Loggers, Appenders, and Layouts.
Log4j2 loggers¶
logger.<LOGGER_NAME>.name = <COMPONENT_NAME>
logger.<LOGGER_NAME>.level = INFO
logger.<LOGGER_NAME>.additivity = false
logger.<LOGGER_NAME>.appenderRef.<APPENDER_NAME>.ref = <APPENDER_NAME>
The logger attributes are described below.
name | The name of the component (class) for which the logger is defined. That is, this logger is responsible for generating logs for the activities of the specified component. |
---|---|
level | Allows to configure level (threshold). After you specify the level for a certain logger, a log request for that logger will only be enabled if its level is equal or higher to the logger’s level. If a given logger is not assigned a level, then it inherits one from its closest ancestor with an assigned level. Refer to the hierarchy of levels given above. See descriptions of the available log levels. |
additivity | Allows to inherit all the appenders of the parent Logger if set as `true`. |
appenderRef.APPENDER_NAME.ref | This element is used to attach appenders to the logger. |
The loggers are then listed in the log4j2.properties
file using the logger name as shown below.
loggers = <LOGGER_NAME>, <LOGGER_NAME_1>, <LOGGER_NAME_2>,
Log4j2 Appenders¶
Log4j2 allows logging requests to print to multiple destinations. These output destinations are called 'Appenders'. All the defined appenders should be listed as shown below in the log4j2.properties
file.
Note
If the output destination is in another environment (such as a cloud storage), you need to use custom log appenders.
appenders = CARBON_CONSOLE, CARBON_LOGFILE, AUDIT_LOGFILE, ATOMIKOS_LOGFILE, CARBON_TRACE_LOGFILE, osgi, SERVICE_LOGFILE, API_LOGFILE, ERROR_LOGFILE, CORRELATION
Once the appenders are defined, a logger can refer the appender by using the appenderRef.APPENDER_NAME.ref
element. You can also attach several appenders to one logger. For example, see how the root logger is linked to three appenders. Also, see how other loggers in the log4j2.properties
file are configured to use appenders.
Configuring Log4j2 Logs¶
The list below shows some of the main loggers (excluding the root logger) that are configured by default in the Micro Integrator. Open the log4j2.properties
file to see the complete list.
loggers = SERVICE_LOGGER, API_LOGGER, AUDIT_LOG, correlation, trace-messages, org.apache.synapse.transport.http.headers, org.apache.synapse.transport.http.wire, httpclient.wire.header, httpclient.wire.content,
The above logger configurations are explained below.
Root Logs¶
Given below is the root logger that is configured by default for the Micro Integrator. All loggers that do not have specific appenders defined will refer the appenders from the root logger.
This logger generates INFO-level logs and prints them to three destinations as per the appenders linked to the logger. The appenderRef.<APPENDER_NAME>.ref
attribute is used for referring the appenders.
rootLogger.level = INFO
rootLogger.appenderRef.CARBON_CONSOLE.ref = CARBON_CONSOLE
rootLogger.appenderRef.CARBON_LOGFILE.ref = CARBON_LOGFILE
rootLogger.appenderRef.ERROR_LOGFILE.ref = ERROR_LOGFILE
Listed below are the default log destinations (appenders) used by the root logger:
-
CARBON_CONSOLE
: This is the consoleAppender that prints logs to the server's console. These logs are printed to thewso2carbon.log
file and thewso2error.log
file through the two appenders given below.# CARBON_CONSOLE is set to be a ConsoleAppender using a PatternLayout. appender.CARBON_CONSOLE.type = Console appender.CARBON_CONSOLE.name = CARBON_CONSOLE appender.CARBON_CONSOLE.layout.type = PatternLayout appender.CARBON_CONSOLE.layout.pattern = [%d] %5p {%c{1}} - %m%ex%n appender.CARBON_CONSOLE.filter.threshold.type = ThresholdFilter appender.CARBON_CONSOLE.filter.threshold.level = DEBUG
-
CARBON_LOGFILE
: This is a RollingFile appender that generates management logs of the server. Logs are printed to the<MI_HOME>/repository/logs/wso2carbon.log
.# CARBON_LOGFILE is set to be a DailyRollingFileAppender using a PatternLayout. appender.CARBON_LOGFILE.type = RollingFile appender.CARBON_LOGFILE.name = CARBON_LOGFILE appender.CARBON_LOGFILE.fileName = ${sys:carbon.home}/repository/logs/wso2carbon.log appender.CARBON_LOGFILE.filePattern = ${sys:carbon.home}/repository/logs/wso2carbon-%d{MM-dd-yyyy}.log appender.CARBON_LOGFILE.layout.type = PatternLayout appender.CARBON_LOGFILE.layout.pattern = [%d] %5p {%c} - %m%ex%n appender.CARBON_LOGFILE.policies.type = Policies appender.CARBON_LOGFILE.policies.time.type = TimeBasedTriggeringPolicy appender.CARBON_LOGFILE.policies.time.interval = 1 appender.CARBON_LOGFILE.policies.time.modulate = true appender.CARBON_LOGFILE.policies.size.type = SizeBasedTriggeringPolicy appender.CARBON_LOGFILE.policies.size.size=10MB appender.CARBON_LOGFILE.strategy.type = DefaultRolloverStrategy appender.CARBON_LOGFILE.strategy.max = 20 appender.CARBON_LOGFILE.filter.threshold.type = ThresholdFilter appender.CARBON_LOGFILE.filter.threshold.level = DEBUG
-
ERROR_LOGFILE
: This is a RollingFile appender that print the error logs to the<MI_HOME>/repository/logs/wso2error.log
file.# Appender config to SERVICE_APPENDER appender.ERROR_LOGFILE.type = RollingFile appender.ERROR_LOGFILE.name = ERROR_LOGFILE appender.ERROR_LOGFILE.fileName = ${sys:carbon.home}/repository/logs/wso2error.log appender.ERROR_LOGFILE.filePattern = ${sys:carbon.home}/repository/logs/wso2error-%d{MM-dd-yyyy}.log appender.ERROR_LOGFILE.layout.type = PatternLayout appender.ERROR_LOGFILE.layout.pattern = [%d] %5p {%c} - %m%ex%n appender.ERROR_LOGFILE.policies.type = Policies appender.ERROR_LOGFILE.policies.time.type = TimeBasedTriggeringPolicy appender.ERROR_LOGFILE.policies.time.interval = 1 appender.ERROR_LOGFILE.policies.time.modulate = true appender.ERROR_LOGFILE.policies.size.type = SizeBasedTriggeringPolicy appender.ERROR_LOGFILE.policies.size.size=10MB appender.ERROR_LOGFILE.strategy.type = DefaultRolloverStrategy appender.ERROR_LOGFILE.strategy.max = 20 appender.ERROR_LOGFILE.filter.threshold.type = ThresholdFilter appender.ERROR_LOGFILE.filter.threshold.level = WARN
Service Logs¶
This logger generates logs for services deployed in the Micro Integrator. It refers to the details in the SERVICE_LOGFILE
appender and prints logs to the <MI_HOME>/repository/logs/wso2-mi-service.log
file.
Note
If you want to have separate log files for individual services, you need to add loggers for each service and then specify appenders for the loggers. Note that the service name has to be suffixed to SERVICE_LOGGER
as follows:
logger.SERVICE_LOGGER.name = SERVICE_LOGGER.TestProxy
See the instructions on monitoring per-service logs.
logger.SERVICE_LOGGER.name= SERVICE_LOGGER
logger.SERVICE_LOGGER.level = INFO
logger.SERVICE_LOGGER.appenderRef.SERVICE_LOGFILE.ref = SERVICE_LOGFILE
logger.SERVICE_LOGGER.additivity = false
# Appender config to SERVICE_LOGFILE
appender.SERVICE_LOGFILE.type = RollingFile
appender.SERVICE_LOGFILE.name = SERVICE_LOGFILE
appender.SERVICE_LOGFILE.fileName = ${sys:carbon.home}/repository/logs/wso2-mi-service.log
appender.SERVICE_LOGFILE.filePattern = ${sys:carbon.home}/repository/logs/wso2-mi-service-%d{MM-dd-yyyy}.log
appender.SERVICE_LOGFILE.layout.type = PatternLayout
appender.SERVICE_LOGFILE.layout.pattern = [%d] %5p {%c} - %m%ex%n
appender.SERVICE_LOGFILE.policies.type = Policies
appender.SERVICE_LOGFILE.policies.size.type = SizeBasedTriggeringPolicy
appender.SERVICE_LOGFILE.policies.size.size=10MB
appender.SERVICE_LOGFILE.strategy.type = DefaultRolloverStrategy
appender.SERVICE_LOGFILE.strategy.max = 20
API Logs¶
This logger generates logs for APIs deployed in the Micro Integrator. It refers to the details in the API_LOGFILE
appender and prints logs to the <MI_HOME>/repository/logs/wso2-mi-api.log
file.
Note
If you want to have separate log files for individual APIs, you need to add loggers for each API and then specify appenders for the loggers. Note that the service name has to be suffixed to SERVICE_LOGGER
as follows:
logger.API_LOG.name=API_LOGGER.TestAPI
See the instructions on monitoring per-API logs.
logger.API_LOGGER.name= API_LOGGER
logger.API_LOGGER.level = INFO
logger.API_LOGGER.appenderRef.SERVICE_LOGFILE.ref = API_LOGFILE
logger.API_LOGGER.additivity = false
# Appender config to API_APPENDER
appender.API_LOGFILE.type = RollingFile
appender.API_LOGFILE.name = API_LOGFILE
appender.API_LOGFILE.fileName = ${sys:carbon.home}/repository/logs/wso2-mi-api.log
appender.API_LOGFILE.filePattern = ${sys:carbon.home}/repository/logs/wso2-mi-api-%d{MM-dd-yyyy}.log
appender.API_LOGFILE.layout.type = PatternLayout
appender.API_LOGFILE.layout.pattern = [%d] %5p {%c} - %m%ex%n
appender.API_LOGFILE.policies.type = Policies
appender.API_LOGFILE.policies.size.type = SizeBasedTriggeringPolicy
appender.API_LOGFILE.policies.size.size=10MB
appender.API_LOGFILE.strategy.type = DefaultRolloverStrategy
appender.API_LOGFILE.strategy.max = 20
Audit Logs¶
This is a RollingFile
appender that writes logs to the <MI_HOME>/repository/logs/audit.log
file. By default, the AUDIT_LOG
logger is configured to write logs using this appender.
logger.AUDIT_LOG.name = AUDIT_LOG
logger.AUDIT_LOG.level = INFO
logger.AUDIT_LOG.appenderRef.AUDIT_LOGFILE.ref = AUDIT_LOGFILE
logger.AUDIT_LOG.additivity = false
# Appender config to AUDIT_LOGFILE
appender.AUDIT_LOGFILE.type = RollingFile
appender.AUDIT_LOGFILE.name = AUDIT_LOGFILE
appender.AUDIT_LOGFILE.fileName = ${sys:carbon.home}/repository/logs/audit.log
appender.AUDIT_LOGFILE.filePattern = ${sys:carbon.home}/repository/logs/audit-%d{MM-dd-yyyy}.log
appender.AUDIT_LOGFILE.layout.type = PatternLayout
appender.AUDIT_LOGFILE.layout.pattern = [%d] %5p {%c} - %m%ex%n
appender.AUDIT_LOGFILE.policies.type = Policies
appender.AUDIT_LOGFILE.policies.time.type = TimeBasedTriggeringPolicy
appender.AUDIT_LOGFILE.policies.time.interval = 1
appender.AUDIT_LOGFILE.policies.time.modulate = true
appender.AUDIT_LOGFILE.policies.size.type = SizeBasedTriggeringPolicy
appender.AUDIT_LOGFILE.policies.size.size=10MB
appender.AUDIT_LOGFILE.strategy.type = DefaultRolloverStrategy
appender.AUDIT_LOGFILE.strategy.max = 20
appender.AUDIT_LOGFILE.filter.threshold.type = ThresholdFilter
appender.AUDIT_LOGFILE.filter.threshold.level = INFO
Correlations Logs¶
This logger generates correlation logs for monitoring individual HTTP requests from the point that a message is received by the Micro Integrator until the corresponding response message is sent back to the original message sender. It refers to the details in the CORRELATION
appender and prints logs to the <MI_HOME>/repository/logs/correlation.log
file.
Note
The maximum file size of the correlation log is set to 10MB in the following appender. That is, when the size of the file exceeds 10MB, a new log file is created. If required, you can change this file size.
logger.correlation.name = correlation
logger.correlation.level = INFO
logger.correlation.appenderRef.CORRELATION.ref = CORRELATION
logger.correlation.additivity = false
# Appender config to put correlation Log.
appender.CORRELATION.type = RollingFile
appender.CORRELATION.name = CORRELATION
appender.CORRELATION.fileName =${sys:carbon.home}/repository/logs/correlation.log
appender.CORRELATION.filePattern =${sys:carbon.home}/repository/logs/correlation-%d{MM-dd-yyyy}.log
appender.CORRELATION.layout.type = PatternLayout
appender.CORRELATION.layout.pattern = %d{yyyy-MM-dd HH:mm:ss,SSS}|%X{Correlation-ID}|%t|%m%n
appender.CORRELATION.policies.type = Policies
appender.CORRELATION.policies.time.type = TimeBasedTriggeringPolicy
appender.CORRELATION.policies.time.interval = 1
appender.CORRELATION.policies.time.modulate = true
appender.CORRELATION.policies.size.type = SizeBasedTriggeringPolicy
appender.CORRELATION.policies.size.size=10MB
appender.CORRELATION.strategy.type = DefaultRolloverStrategy
appender.CORRELATION.strategy.max = 20
appender.CORRELATION.filter.threshold.type = ThresholdFilter
appender.CORRELATION.filter.threshold.level = INFO
Additional configurations:
If required, you can change the default HTTP header (which is 'activity_id'), which is used to carry the Correlation ID, by adding the following property to the deployment.toml
file (stored in the <MI_HOME>/conf/
directory). Replace <correlation_id>
with a value of your choice.
[passthru_properties]
correlation_header_name="<correlation_id>"
Once you have configured this logger, see the instructions on monitoring correlation logs.
Message Tracing Logs¶
This is a RollingFile
appender that writes logs to the <MI_HOME>/repository/logs/wso2carbon-trace-messages.log
file. By default, the trace.messages
logger is configured to write logs using this appender.
logger.trace-messages.name = trace.messages
logger.trace-messages.level = TRACE
logger.trace-messages.appenderRef.CARBON_TRACE_LOGFILE.ref = CARBON_TRACE_LOGFILE
# Appender config to CARBON_TRACE_LOGFILE
appender.CARBON_TRACE_LOGFILE.type = RollingFile
appender.CARBON_TRACE_LOGFILE.name = CARBON_TRACE_LOGFILE
appender.CARBON_TRACE_LOGFILE.fileName = ${sys:carbon.home}/repository/logs/wso2carbon-trace-messages.log
appender.CARBON_TRACE_LOGFILE.filePattern = ${sys:carbon.home}/repository/logs/wso2carbon-trace-messages-%d{MM-dd-yyyy}.log
appender.CARBON_TRACE_LOGFILE.layout.type = PatternLayout
appender.CARBON_TRACE_LOGFILE.layout.pattern = [%d] %5p {%c} - %m%ex%n
appender.CARBON_TRACE_LOGFILE.policies.type = Policies
appender.CARBON_TRACE_LOGFILE.policies.time.type = TimeBasedTriggeringPolicy
appender.CARBON_TRACE_LOGFILE.policies.time.interval = 1
appender.CARBON_TRACE_LOGFILE.policies.time.modulate = true
appender.CARBON_TRACE_LOGFILE.policies.size.type = SizeBasedTriggeringPolicy
appender.CARBON_TRACE_LOGFILE.policies.size.size=10MB
appender.CARBON_TRACE_LOGFILE.strategy.type = DefaultRolloverStrategy
appender.CARBON_TRACE_LOGFILE.strategy.max = 20
Wire Logs and Header Logs¶
These logs are disabled by default by setting the log level to OFF
. You can enable these logs by changing the log level of the loggers to DEBUG
.
Info
It is not recommended to use these logs in production environments. Developers can enable them for testing and troubleshooting purposes. Note that appenders are not specified for these loggers, and therefore, the logs will be printed as specified for the root logger.
-
The following loggers configure wire logs for the PassThrough HTTP transport:
Tip
The Passthrough HTTP transport is the main transport that handles HTTP/HTTPS messages in the Micro Integrator.
# The following loggers are used to log HTTP headers and messages. logger.synapse-transport-http-headers.name=org.apache.synapse.transport.http.headers logger.synapse-transport-http-headers.level=OFF
logger.synapse-transport-http-wire.name=org.apache.synapse.transport.http.wire logger.synapse-transport-http-wire.level=OFF
-
The following loggers configure wire logs for the Callout mediator/MessageProcessor.
logger.httpclient-wire-header.name=httpclient.wire.header logger.httpclient-wire-header.level=OFF
logger.httpclient-wire-content.name=httpclient.wire.content logger.httpclient-wire-content.level=OFF
See the instructions on using wire logs to debug your integration solution during development.
Configuring HTTP Access Logs¶
Access logs related to service/API invocations are enabled by default in the Micro Integrator. Access logs for the PassThrough transport will record the request and the response on two separate log lines.
By default, access logs are printed to the http_acces_.log
file (stored in the <MI_HOME>/repository/logs
folder). If required, you can use the log4j2 configurations to print the access logs to other destinations. Simply apply the following logger with an appender.
- Logger Name: PassThroughAccess
- Logger Class: org.apache.synapse.transport.http.access
Customizing the Access Log format¶
You can customize the format of this access log by changing the following property values in the <MI_HOME>/conf/access-log.properties
configuration file. If this file does not exist in the product by default, you can create a new file.
-
Open the
access-log.properties
file and add the following properties.access_log_directory Add this property ONLY if you want to change the default location of the log file. By default, the product is configured to store access logs in the MI_HOME/repository/logs
directory.access_log_prefix access_log_suffix access_log_file_date_format access_log_pattern The attribute defines the format for the log pattern, which consists of the information fields from the requests and responses that should be logged. The pattern format is created using the following attributes:
-
A standard value to represent a particular string. For example, "%h" represents the remote host name in the request. Note that all the string replacement values supported by Tomcat are NOT supported for the PassThrough transport's access logs. The list of supported values are given below.
- %{xxx}i is used to represent the header in the incoming request (xxx=header value).
- %{xxx}o is used to represents the header in the outgoing request (xxx=header value).
While you can use the above attributes to define a custom pattern, the standard patterns shown below can be used.
-
common ( Apache common log pattern ):
-
combined ( Apache combined log pattern ):
By default, a modified version of the Apache combined log format is enabled in the ESB, as shown below. Note that the "X-Forwarded-For" header is appended to the beginning of the usually combined log format. This correctly identifies the original node that sent the request (in situations where requests go through a proxy such as a load balancer). The "X-Forwarded-For" header must be present in the incoming request for this to be logged.
-
-
Restart the server.
-
Invoke a proxy service or REST API that is deployed in the Micro Integrator. The access log file for the service/API will be created in the
<MI_HOME>/repository/logs
directory. The default name of the log file ishttp_access_.log
.Tip
Note that there will be a delay in printing the logs to the log file.
Supported log pattern formats¶
Attribute | Description |
---|---|
|
Remote IP address |
|
Local IP address |
|
Bytes sent, excluding HTTP headers, or '-' if zero |
|
Bytes sent, excluding HTTP headers |
|
Cookie value |
|
Accept header |
|
Accept Encoding |
|
Transfer Encoding |
|
The remote hostname (or IP address if enableLookups for the connector is false) |
|
Remote logical username from identd (always returns '-') |
|
Accept Language |
|
Keep Alive |
|
Request method (GET, POST, etc.) |
|
Content Encoding |
|
Request Element |
|
HTTP status code of the response |
|
Accept Chatset |
|
Date and time, in Common Log Format |
|
The time taken to process the request in seconds. |
|
The remote user that was authenticated (if any), else '-' |
|
Requested URL path |
|
Local server name |
|
Vary Header |
|
Connection Header |
|
Server Header |
Updating the Log4j2 Log level¶
You can dynamically update the log level for a specific logger by using the Micro Integrator dashboard or CLI. If you change the wire log configuration directly from the log4j2.properties
file (without using the dashboard or CLI), the Micro Integrator needs to be restarted for the changes to become effective.
Log Levels
The following table explains the log4j2 log levels you can use. Refer Log4j2 documentation for more information.
Level | Description |
---|---|
OFF | The highest possible log level. This is intended for disabling logging. |
FATAL | Indicates server errors that cause premature termination. These logs are expected to be immediately visible on the command line that you used for starting the server. |
ERROR | Indicates other runtime errors or unexpected conditions. These logs are expected to be immediately visible on the command line that you used for starting the server. |
WARN | Indicates the use of deprecated APIs, poor use of API, possible errors, and other runtime situations that are undesirable or unexpected but not necessarily wrong. These logs are expected to be immediately visible on the command line that you used for starting the server. |
INFO | Indicates important runtime events, such as server startup/shutdown. These logs are expected to be immediately visible on the command line that you used for starting the server. It is recommended to keep these logs to a minimum. |
DEBUG | Provides detailed information on the flow through the system. This information is expected to be written to logs only. Generally, most lines logged by your application should be written as DEBUG logs. |
TRACE | Provides additional details on the behavior of events and services. This information is expected to be written to logs only. |
Viewing logs via the dashboard¶
- Sign in to the Micro Integrator dashboard.
-
Click Log Configs on the left-hand navigator to open the Logging Management window.
-
Use the Search option to find the required logger, and change the log level as shown above.
Viewing logs via the CLI¶
-
Download and set up the API Controller.
-
Issue commands to view logs for the required Micro Integrator artifacts. For more information, see Managing Integrations with apictl.
Updating the threshold Level¶
The threshold value filters log entries based on the log level. This value is set for the log appender in the log4j2.properties
file. For example, a threshold set to 'WARN' allows the log entry to pass into the appender. If its level is 'WARN', 'ERROR' or 'FATAL', other entries will be discarded. This is the minimum log level at which you can log a message.
Shown below is how the log level is set to DEBUG for the CARBON_LOGFILE
appender:
appender.CARBON_LOGFILE.filter.threshold.level = DEBUG
Updating the Log4j2 Log pattern¶
The log pattern defines the output format of the log file. This is the layout pattern that describes the log message format.
Identifying forged messages: The conversion character 'u' can be used in the pattern layout to log a UUID. For example, the log pattern can be [%u] [%d] %5p {%c} - %m%ex%n, where [%u] is the UUID.
Hiding current parameters in the printed log¶
By default, when an error occurs while invoking a data service, the Micro Integrator logs a set of parameters in the error message.
For example:
DS Code: INCOMPATIBLE_PARAMETERS_ERROR
Source Data Service:-
Name: RDBMSSample
Location: /RDBMSSample.dbs
Description: N/A
Default Namespace: http://ws.wso2.org/dataservice
Current Request Name: _addEmployee
Current Params: {firstName=Will, lastName=Smith, salary=1200, [email protected]}
You can hide the 'Current Params' in the printed logs by passing the following system property:
-Ddss.disable.current.params=true \
Using Custom Log appenders¶
Custom log appenders for Log4j2 can be used to store application logs in various environments/systems such as cloud storages.
However, since WSO2 Micro Integrator works in an OSGi environment, such Log4j2 extensions cannot be used as they are. Therefore, you need to modify those extensions to be compatible with WSO2 Micro Integrator. Follow the steps given below to modify an existing Log4j2 extension:
-
In the custom log appender, open the
pom.xml
file of the module that contains theLog4j2Appender
class. -
Under the
build
section, addmaven-compiler-plugin
andmaven-bundle-plugin
as follows.<plugins> ... <plugin> <artifactId>maven-compiler-plugin</artifactId> <executions> <execution> <id>log4j-plugin-processor</id> <goals> <goal>compile</goal> </goals> <phase>process-classes</phase> <configuration> <proc>only</proc> <annotationProcessors> <annotationProcessor> org.apache.logging.log4j.core.config.plugins.processor.PluginProcessor </annotationProcessor> </annotationProcessors> </configuration> </execution> </executions> </plugin> <plugin> <groupId>org.apache.felix</groupId> <artifactId>maven-bundle-plugin</artifactId> <extensions>true</extensions> <configuration> <instructions> <Bundle-SymbolicName>${project.artifactId}</Bundle-SymbolicName> <Bundle-Name>${project.artifactId}</Bundle-Name> <Fragment-Host>org.ops4j.pax.logging.pax-logging-log4j2</Fragment-Host> <Export-Package> <PACKAGE_CONTAINS_THE_APPENDER_CLASS> </Export-Package> <DynamicImport-Package>*</DynamicImport-Package> <Import-Package></Import-Package> <Include-Resource>${project.build.directory}/classes/</Include-Resource> </instructions> </configuration> </plugin> ...
-
Rebuild the related module and copy the built JAR file from the
target
directory to<MI_HOME>/dropins
directory. -
Configure the custom appender in the
log4j2.properties
file as follows.appender.log4j2Custom.type = Log4j2Appender appender.log4j2Custom.name = log4j2Custom appender.log4j2Custom.layout.type = PatternLayout appender.log4j2Custom.layout.pattern = [%d] %5p {%c} - %m%ex%n
-
The custom appender should be added to the list of registered appenders in the
log4j2.properties
file as shown below.appenders = log4j2Custom, ....
-
Restart the server.
What's Next?¶
Once you have configured the logs, you can start using the logs.
Top