Logging is a key topic whenever we go back to an application for analysis or debugging. Having the right information in the logs of an application is one of the best practices in software engineering. The next thought should be given on to how these logs would be useful to the supporting team members.
Here we will discuss a few best practices that can be used while creating ESB applications which are very useful and appreciated by the support team or whoever is looking at the application at a later point in time.
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
We can see that the default log level is set to WARN. This will enable us to log the application related and more detailed information in 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 is used below.
Based on the naming and messaging best practices , the name and message can be configured . We are more interested in the ‘Level’ and the ‘Category’ fields.
For ‘Level’ property, we suggest that all custom messages be set to DEBUG level. Few log messages, which we wish to highlight or want them to be available 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 that anyone who makes use of this can decode the string. Here, we have used a base package of ‘com.ww’ which would be for an organization. Then the project name, which is ‘myproject’ followed by the flow name in the same project.
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 a part of the functionality that is implemented.
Now, that is good for our understanding. We will see how this can be used with in the log4j.properties.
We have seen that default log level can be set to ‘WARN’. S0, now if we wish to see the logs for the application ‘myproject’ then we can add the following line at the end in the log4j.properties file.
<span style="color: #0000ff;">log4j.logger.com.ww.project=DEBUG</span>
This would generate all the debug messages related to the project. Also, this may generate a huge set of logs, and we may want to get only the logs specific to the functionality that we 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.
<span style="color: #0000ff;">log4j.logger.com.ww.myproject.myfunction=DEBUG</span>
Further to drill down, we can also enable or disable the logs specific to those flow in order 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.
<span style="color: #0000ff;">log4j.logger.com.ww.myproject.myfunction.flow2=DEBUG</span>
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.
We can ensure that the operations and support team would appreciate the efforts to have effective logging that will help in root cause analysis, performance monitoring and resolve time sensitive critical application issues.
If you would like to find out more about how Mule Integration could help you make the most out of your current infrastructure while enabling you to open your digital horizons, do give us a call at +44 (0)203 475 7980 or email us at Salesforce@coforge.com
Other useful links:
Coforge Systems Integration
API Recipes with MuleSoft Anypoint Platform
Case studies
