Log4j in Mule - What you need to know

Apache Log4j is an open-source logging library for Java-based applications, developed by the Apache Software Foundation. It allows developers to log messages at various levels of severity, such as debug, info, warning, error, and fatal, which can then be stored in various formats, like console output, files, or even databases.

For as, Mulesoft Architects and developers, Log4j is a key element as Mule uses Log4j for logging within the runtime. Logging is crucial in MuleSoft for monitoring, debugging, and auditing our integrations, APIs, and services.

Log4j2 is designed for high performance, especially in multi-threaded applications like those built with Mule 4.

Log4j provides a flexible and configurable framework for logging messages from an application. The main components in the log4j framework are:

Loggers - Responsible for capturing logging information
Logging Levels - Determine the importance of the log message
Appenders - With appenders, we define the different destinations for our logs
Layouts - We use Layouts to define the style of our logs

Let's see them in detail:

Loggers

Loggers are the main components responsible for capturing log messages. A logger is associated with a specific part of the application, usually identified by a name (which typically corresponds to the package or class it logs messages for).
MuleSoft integrates Log4j to handle logging across its runtime and applications. MuleSoft’s use of Log4j allows developers to capture detailed information about the execution of Mule flows, connectors, components, and services.
In a Mule application, developers can utilize the Logger component to explicitly log messages within a flow. The Loggercomponent is configured directly within the Mule flow, and it can leverage Log4j’s logging capabilities.
You can control the verbosity of logs for different Mule components by adjusting the log levels in the log4j2.xmlfile.

Logging Levels

Logging levels are a fundamental concept in logging frameworks like Log4j. They determine the severity or importance of the log messages and help control which messages are captured and stored. Each log level represents a different kind of event, ranging from detailed debugging information to critical system errors. These are the log levels that Mule uses:

TRACE: Very detailed logging, including highly granular details. Rarely used in production due to its verbosity.
DEBUG: Detailed information typically of interest only when diagnosing problems. Useful in development and staging environments.
INFO: Informational messages that highlight the progress of the application. Generally used in production.
WARN: Potentially harmful situations that are not errors but could lead to issues. Use in production to catch non-critical issues.
ERROR: Error events that might still allow the application to continue running. Essential for production environments.
FATAL: Severe error events that lead to premature application termination. Critical to monitor in all environments.

Check out this post to dive deeper into how to use Log Levels for your Mule apps

Appenders

Appenders are responsible for defining where the log messages go (i.e., their destination). Common destinations include:

ConsoleAppender: Logs to the console (standard output).
FileAppender: Logs to a file.
RollingFileAppender: Logs to a file and rolls over when it reaches a certain size or at certain time intervals.
SocketAppender: Sends logs to a remote server.
Log4j allows multiple appenders to be attached to a logger, meaning that the same log message can be sent to several different destinations.

Check out this post to understand better How Appenders in Log4j work for your Mule apps

Layouts

Layouts determine the format of the log messages. For example, a layout might specify that each log message should include a timestamp, the severity level, and the actual message content. Log4j provides several built-in layouts like PatternLayout, XMLLayout, and JSONLayout, which allow us to customize how the log messages appear.

Check out these posts if you want to know more about how layouts work and how to set up some of the built-in layouts in Log4j:

Putting all together

When a log message is generated in an application, the following process typically occurs:

Capture: The logger captures the message, checking its level against the configured threshold.
Propagation: If the message level is appropriate, the logger passes it to the attached appenders.
Formatting: Each appender uses its configured layout to format the message.
Output: The formatted message is then sent to the destination defined by the appender (e.g., console, file).

Example

For example, let’s see the default log4j configuration of mule apps. This is the log4j2.xml file that we’ll get create when we start a new Project in Anypoint Studio. The file is located under src/main/resources:

Here, we can see:

There’s one Appender - Rolling File, the logs will be sent to a file that will be rotating
Logs sent to that appender will be formatted following the PatternLayout. This means logs will be written in plain text and, according to the conversion pattern, they will include details like date/time, thread name, log level and the log message
There are a few Loggers declared

The AsyncRoot logger is the one setup for all components of the app. It’s configured with INFO level for the logs
There are two loggers that refer to the HTTP connector. This means logs for the connector will log at WARN level
Lastly, there’s an explicit entry for the Mule Logger with INFO level. This refers to the Mule Logger processor and simplifies our job (this way we don’t have to remember the package name for the mule logger in case we need to change the log level)

Where to go from here

Now that you have a high level understanding of what the Log4j framework is, check out the following posts to dive deeper into the different topics related to Log4j and how we can configure it for our Mule apps: