JSON logging in Mule: How to get the most out of your logs

json mule logging

Logging is arguably one of the most neglected tasks on any given project. It’s not uncommon for teams to consider logging as a second-class citizen and it is usually taken for granted; until, of course, the team goes live and try to troubleshoot anything.

10x logging capacity, on-prem clustering from the cloud

The latest release of Anypoint Platform includes major upgrades to our logging service for applications running on CloudHub (now a Platform service). With this release, users will be able to retain more log information per application, using a globally distributed infrastructure, and access the logs via an updated UI. Additionally, users who do hybrid management of on-premises servers and applications will now be able to set up High Availability (HA) for their on-prem servers using the new clustering feature.

Disrupting your Asynchronous Loggers

motif

A little while ago we decided that it was time to include the option of asynchronous loggers in Mule ESB.

The asynchronous implementation is faster than the synchronous one because the process waits for IO on a different thread, instead of on the main execution thread, allowing it to continue its execution.

After some research, we decided to use LogBack or Log4j2, both are successors of the Log4j framework.

Asynchronous Logging in Mule 3.6

motif

“Logs are like car insurance. Nobody wants to pay for it, but when something goes wrong everyone wants the best available” – Pablo Kraan

The phrase above fully explains why logs are important and why we need to be able to log as much information as possible without impacting performance. Because logging usually implies an I/O operation, it’s a naturally slow operation.

The Problem

Before Mule 3.6,

Total traceability with correlation IDs

motif

Distributed systems are great: they’re more versatile and resilient than monolithic ones. They also bring challenges of their own, one of them being the difficulty of building a holistic picture of the systems and interactions involved in the processing of a request or the execution of a business activity.

Business process modeling and their reification in business process engines can help a lot in this matter. But these engines are not pervasively used and there are still blind spots,

She logs me, she logs me not

motif

Logging. An old friend. So critical for a production deployment and so hidden away. Much has been said and done in this area, and we’ve seen both success and total domination by log4j, as well as an abysmal failure of java.util.logging (still hearing the chorus of WTFs and raised eye brows).

With the introduction of Mule 3 the playing field has changed dramatically, but something was still missing. Multiple applications in runtime were still writing to the same single log file.

Logging just got a lot easier in Mule 3.1

December 17 2010

1 comment.
motif

Mule 3.1 introduces a very useful new <logger> element that makes it easy to inspect the content and properties of your messages in Mule while building or debugging a flow. It’s also perfect for logging errors, info messages etc.  Mule has always supported logging with the <log-component> but while working with the new orchestration capabilities of Mule 3 flows, we found a real need for fine-grained logging. With the new message processor architecture,