Mule Application Logging with Log4j2

The Mule Runtime enables seamless communication between different applications and formats inside and outside the corporate network. In addition to sharing information, a logging policy is essential for early detection of errors, security threats, or for auditing and debugging purposes.

Mule has been using the logging system Apache Log4j2 since version 3.6. Log4j2 is the next version of the popular and influential log4j library that has been used in the Java ecosystem for many years. Version 2 builds on its predecessor’s logging capabilities and includes significant enhancements, especially in the area of performance.

Configuration and implementation of log messages within a Mule Service is shown below.

Mule Logger within a Flow

The log component <logger /> allows the logging of business- and metadata during the flow processing. Due to the log level, logging can be defined as required and targeted.

<logger message="Processing message with id #[message.id] and payload #[payload]" level="INFO" doc:name="Logger"/>

Mule Java logger in custom components

Custom components get access to the logger through the Log42j Framework, using the LogFactory class.

Log logger = LogFactory.getLog(getClass());

if (logger.isInfoEnabled())
{
  logger.info("Processing event received.");
}

Log4j2 configuration for a Mule Service Application

The logging behavior of a Mule Service is defined by the configuration file log4j2.xml. The basic configuration includes the logging system, log pattern, logger and log level.

<?xml version="1.0" encoding="utf-8"?>
<Configuration>
    <Appenders>
        <RollingFile name="file" fileName="${sys:mule.home}${sys:file.separator}logs${sys:file.separator}service-experience-api.log"
                 filePattern="${sys:mule.home}${sys:file.separator}logs${sys:file.separator}service-experience-api-%i.log">
            <PatternLayout pattern="%d [%t] %-5p %c - %m%n" />
            <SizeBasedTriggeringPolicy size="10 MB" />
            <DefaultRolloverStrategy max="10"/>
        </RollingFile>
    </Appenders>
    <Loggers>

		<!-- Http Logger shows wire traffic on DEBUG -->
		<AsyncLogger name="org.mule.module.http.internal.HttpMessageLogger" level="WARN"/>

		<!-- JDBC Logger shows queries and parameters values on DEBUG -->
		<AsyncLogger name="com.mulesoft.mule.transport.jdbc" level="WARN"/>

        <!-- CXF is used heavily by Mule for web services -->
        <AsyncLogger name="org.apache.cxf" level="WARN"/>

        <!-- Apache Commons tend to make a lot of noise which can clutter the log-->
        <AsyncLogger name="org.apache" level="WARN"/>

        <!-- Reduce startup noise -->
        <AsyncLogger name="org.springframework.beans.factory" level="WARN"/>

        <!-- Mule classes -->
        <AsyncLogger name="org.mule" level="INFO"/>
        <AsyncLogger name="com.mulesoft" level="INFO"/>

        <!-- Reduce DM verbosity -->
        <AsyncLogger name="org.jetel" level="WARN"/>
        <AsyncLogger name="Tracking" level="WARN"/>

        <AsyncRoot level="INFO">
            <AppenderRef ref="file" />
        </AsyncRoot>
    </Loggers>
</Configuration>

Conclusion

Mule standard components allows developers to log business or technical information within the process flow very easy. The Mule Logging Framework is available and open to use for custom components. Log4j2 achieves very high throughput also in many parallel log messages by using asynchronous loggers. Integration of the Mule Server to Log Management Systems is possible due to the standardized Log4j2 log output. Using Log4j2 in the Mule Runtime, existing logging policies can be implemented very well.

Author: dataliquid GmbH
To top