Logging best practice in mule using logger component

LOGGING BEST PRACTICE IN MULE

USING LOGGER COMPONENT

Govind Mulinti

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


Log4j configurationFirst 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 levellog4j.rootCategory=WARN, file log4j.appender.file = org.apache.log4j.RollingFileAppenderlog4j.appender.file.MaxFileSize=1MBlog4j.appender.file.MaxBackupIndex=10log4j.appender.file.File = ${mule.home}/logs/mule-app-myproject.loglog4j.appender.file.Append = truelog4j.appender.file.layout = org.apache.log4j.PatternLayoutlog4j.appender.file.layout.ConversionPattern=%-5p %d [%t] %c: %m%n

3


Using logger componentWe 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


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


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


ConclusionAfter 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

Logging best practice in mule using logger component

Software