4 ways to externalize MuleSoft logs to the Elastic Stack

The former Netflix Architect Allen Wang posted back in 2015 on SlideShare: “Netflix is a logging company that occasionally steams video.” 

Five years ago, Netflix was creating about 400 billion events per day in different event types. Today, organizations can’t afford for their applications to have slow performance or experience downtime. To prevent that, engineers must rely on the data generated by their applications and infrastructure.

JSON logging in Mule 4: Logs just got better

This is the second in a series about JSON logging. If you want to customize the output data structure you can check part 1 of the blog post. In this post, we are going to explore the new capabilities added in version 2 that were implemented based mostly on user feedback.

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


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


“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


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


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.

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,