Logging in mule

You should provide as much thought to logging in mule as designing your code or implementing the logic – since logging has direct impact on performance, maintainability and support. In this post, we will look at all the aspects related to logging in mule in detail.


Logging in mule is done using log4j2 library. Log4j2 can be configured for logging of mule applications by adding log4j2.xml into the src/main/resources folder (this file is by default created when you create a new project). Log4j2 enables asynchronous logging and many other improvements to the log4j framework and with right configuration, you can enable debug of mule applications and for production use.

Default rolling file strategy:

Compared to previous versions, in 5.4.0 version (and above) of anypoint studio with 3.7.3 Mule ESB run time (and above), the following rolling file appender is added by default:

This helps adding a size based roll over strategy – helpful for defining custom log file and logging level for the applications. Note that in case you want to define your own custom location to store these logs (ie. In some place other than the default logging location – so that logs are separate from system apps log folder), then you can either hard code the absolute path in the file or you can add relative path entry by adding a custom property in the configuration file.

For example:

If you add custom property like:

You can then use the property in the log entry like

This is especially useful for onPremise Mule installations. In Cloudhub, the logs are managed by the anypoint platform.

Auto re-load configurations

If you enable the monitorInterval property to the log4j2 configuration, then any changes to the log4j2 configuration file is auto picked up by the mule server.

This is extremely useful in case of debugging issues in production – when you can just change the logging level of concerned component during issue, debug the messages/working of the application and reset the logging level without requiring any restarts of the application. Note that this is useful in onPrem installations – for Cloudhub, the changes to log4j2 configuration could be dynamically applied as shown in “Logging Management in Cloudhub” section below.

Logging in Mule

In Mule code, you usually log the messages using the Log Message processor. A useful way of controlling the verbosity of custom logging from the mule flows is by using the category option effectively at the logger components.

For example, when defining the logger component, you have the option of defining the message, level and category options. In the following screenshot, we notice that we are logging the flow variable at Debug level and the logger is categorized for com.integralzone.custom.audit category.

Advantage of defining the category is that in log4j2.xml, you can configure the verbosity of the category for the mule application.

Another advantage of adding the category is that any log message will now have the category listed in the log4j error message – so that you can easily categorize the messages. If required, you can add specific appender to the log4j configuration to log certain log messages to specific appenders to handle appropriately (for ex: ERROR messages to an error logger for alerting purposes, all the error messages from INFO and above for common tracing, DEBUG level for root cause analysis, etc). This is extremely useful if you are using Splunk/ELK or similar monitoring tools which harvest the details from the logs.

Example implementation

In the API example (from the API policy enforcement blog post), let’s add two logger elements as shown

The first Logger is set at INFO level – which prints the incoming request as shown below

Second logger prints the outgoing payload at DEBUG level as shown

log4j2.xml should be like below if you have done the above changes

After making these changes run your project as mule application from Anypoint studio and access URL (for e.g., localhost:8081/api/machines)

in console you will see the output as

in configuration file we changed the default path of log file to new one. We can see that as below


Till now, we have seen logging in on-premises.To see Logging management in Cloudhub deploy the application to cloudhub without modifying the default log4j configuration,

Logging management in Cloudhub

Hit the application URL from postman (or browser)

You should now see the logging message (first logger) with INFO set as shown below in the logs:


Now, let’s change the logging level at runtime for this application. Click on Settings section and select Logging tab. Enter the details of category and level as shown.

Once you click Apply, these changes should get applied instantaneously.

If you try the request in postman or browser again, you should see DEBUG level logs as shown:

Additional Links:



Leave a Reply

Your email address will not be published. Required fields are marked *


two × five =