Logging is a key part of application debugging and analysis. This document discusses best practices for logging in Mule applications using the logger component. It recommends configuring log4j to use RollingFileAppender to control log file sizes. The logger component should be used to log messages with the log level and category string providing meaning. The category string should indicate the project, functionality, and flow being logged to help decode where log messages originate. Log4j properties can enable logging at granular levels like specific flows by configuring logger categories. Following these practices helps support teams debug issues faster through meaningful logs.

1. LOGGING BEST PRACTICE
IN MULE
USING
LOGGER COMPONENT
Govind Mulinti

2. 2015 © WHISHWORKS. All rights reserved. WHISHWORKS Confidential
• Logging is been a key discussion whenever we go back
to an application for analysis or debugging. Having
proper logs in the application is first best practice that
we need to put into practice. The next thought should
be given to how these logs would be useful to the
supporting team members.
• Here we discuss a few best practices that we can
make use while creating the ESB applications which
will be very useful and appreciated by the support
team or whoever is looking at the application at a
later point in time.
2
Logging Best Practice in Mule ESB using Logger component

3. 2015 © WHISHWORKS. All rights reserved. WHISHWORKS Confidential
Log4j configuration
First rule of thumb, we will be using log4j.properties file with in the
application/mule project that we wish to configure for appropriate logging. We
would configure the log4j to use the RollingFileAppender as below.
# Default log level
log4j.rootCategory=WARN, file
log4j.appender.file = org.apache.log4j.RollingFileAppender
log4j.appender.file.MaxFileSize=1MB
log4j.appender.file.MaxBackupIndex=10
log4j.appender.file.File = ${mule.home}/logs/mule-app-myproject.log
log4j.appender.file.Append = true
log4j.appender.file.layout = org.apache.log4j.PatternLayout
log4j.appender.file.layout.ConversionPattern=%-5p %d [%t] %c: %m%n
3

4. 2015 © WHISHWORKS. All rights reserved. WHISHWORKS Confidential
Using logger component
We can see that the default log level is set to WARN. This will enable us to
log the application related logs at INFO or DEBUG levels.
Now in the project go ahead and add the logger component. The properties
for one of the logger that I have used is shown below.
You are free to set the name and the message as per the naming and
messaging best practices. We are more interested now are in the ‘Level’ and
the ‘Category’ fields.
4

5. 2015 © WHISHWORKS. All rights reserved. WHISHWORKS Confidential
Using the Log Level
• For ‘Level’ property, we suggest for all the custom messages should be set to
DEBUG level. Few log messages, which we wish to highlight or want them to be
available of at a higher level like an entry and exit of the flows, calls or some
specific functionality, can be set to INFO.
• The ‘Category’ property should be set to string similar to a package of a java
class.
• For example here we are using ‘com.ww.myproject.myfunction.flow2’.
• We should follow a practice so anyone using this can decode this string. Here I
have a base package of ‘com.ww’ which would be for an organization. Then the
project name, which is ‘myproject’ and then the flow name in that particular
project.
• So we can decode my package of which would be for the logger from the flow
named ‘flow2’ within an application denoted by name or known as ‘myproject’.
The additional element ‘myfunction’ is added which tells us that this flow is part
of that functionality that is implemented.
5

6. 2015 © WHISHWORKS. All rights reserved. WHISHWORKS Confidential
Setting Log Level in log4j.properties
Now, that is good for our understanding. We will see how this can be used with in the log4j.properties.
We have seen that I have set the default log level to ‘WARN’. SO now if I wish to see the logs for my
application ‘myproject’ then I would add the following line in the log4j.properties file.
log4j.logger.com.ww.project=DEBUG
This would generate all the debug messages related to the project. This may generate a huge set of logs, so
you may want to get only the logs specific to the functionality that you are currently looking into. So that is
where this functionality element that we added into our package comes into play. To obtain this we would
update the parameters as shown below.
log4j.logger.com.ww.myproject.myfunction=DEBUG
Further to drill down you can enable or disable the logs specific to those flow to get more granular set of
messages as shown below for flow2. We can add multiple similar lines for each flow if we need such small
sets of logs for specific flows and avoid rest of the log messages.
log4j.logger.com.ww.myproject.myfunction.flow2=DEBUG
6

7. 2015 © WHISHWORKS. All rights reserved. WHISHWORKS Confidential
Conclusion
After debugging process this line should be either
commented or removed from the log4j.properties file so we
stop producing the huge set of logs file containing detailed
debug messages.
By putting this into practice we can ensure that the
customers as well as the support team would appreciate the
efforts put into this. This would help the support team to
look into the logs and get debug messages so as to analyze
the issue that are investigated. This would reduce the
investigation time, to narrow down to the root cause and to
provide appropriate fix with a short turnaround time.
7