Skip to main content

Logging in Mulesoft

By Gourav S

 Logger Component 

This Core component helps you monitor and debug your Mule application by logging important information such as error messages, status notifications, payloads, and so on. You can add a Logger anywhere in a flow, and you can configure it to log a string that you specify, the output of a DataWeave expression you write, or any combination of strings and expressions.






/


Type of Log in Mulesoft:

  • System Log: It is specific to MuleSoft runtime & “log4j.xml” configuration file is not accessible to an user.System logs contains log messages about the MuleSoft runtime life cycle (startup and shutdown) & status messages about MuleSoft application.
  • Application Log: It is specific to MuleSoft application & “log4j.xml” configuration file is packaged inside MuleSoft application. It contains all log messages generated inside the Mule application, including System.out messages. We can configure custom log file appender to send application log data outside of cloudhub to external log file appender like splunk.
  • Audit Log: It logs user interactions within Anypoint Platform, including logins, business groups creation, and environments creation.Only the organization owner can access all the audit logs data. It is useful to detect the access violations.

Log Levels:

  • DEBUG level logs messages which could be useful in debugging an issue
  • INFO level is designated for information related messages which tracks the progress of the mule flow.
  • WARN level is best suited for temporary problems or unexpected behavior
  • ERROR level should contain technical issues that need to be resolved for proper functioning of the application

Log level order/priority :

  •  DEBUG < INFO < WARN < ERROR.

  • Note: By default mule runtime shows INFO log level, so it ignores DEBUG or TRACE log level messages & logging is done asynchronously in cloudhub console. Synchronous logging happens for audit trail or for ERROR/CRITICAL messages.


How to View Logs of Mule Application :

  • View App Logs : Check Anypoint Console / CloudHub.
  • View the Runtime Log in Anypoint Studio:
    • Click Anypoint Studio > About Anypoint Studio > Installation Details > Configuration > View Error Log:


Logging (log4j)

  • Mule runtime engine (Mule) 4 uses Log4j 2 asynchronous logging by default, so the logging operation happens in a separate thread from the message processing, and the latter can continue without having to wait for the log operation to complete.
  • The Logger component integrates with Log4j2, allowing the logged messages to be handled according to your Log4j2 configuration.
  • You can configure Log4j2 to append custom log information, such as thread names, application names, or other contextual data.
  • Log4j2 is designed for high performance, especially in multi-threaded applications like those built with Mule 4.
  • Log4j2 allows logs to be written to various destinations, including files, the console, or external systems.



The above example makes the Runtime Manager agent log its state to a rolling log file in '$MULE_HOME/logs/custom_mule_agent.log', which rolls on a per day basis and until the file reaches a 250MB size.

Next > Best Practices in Logging.

Labels:

Comments

Post a Comment

Popular posts from this blog

Microservices design patterns

By Gourav S
Microservices design pattern Next :  saga-design-pattern-microservices
Post a Comment
Read more

Runtime Fabric (RTF)

By Gourav S
MuleSoft's Anypoint Runtime Fabric (RTF) has many features that help with deployment and management of Mule applications: Deployment: RTF can deploy applications to any environment, including on-premises, in the cloud, or in a hybrid setup. It can also automatically deploy Mule runtimes into containers. Isolation: RTF can isolate applications by running a separate Mule runtime server for each application. Scaling: RTF can scale applications across multiple replicas. Fail-over: RTF can automatically fail over applications. Monitoring and logging: RTF has built-in monitoring and logging capabilities to help teams troubleshoot issues and gain insights into application performance. Containerization: RTF supports containerization, which allows applications to be packaged with their dependencies and run consistently across different environments. Integration: RTF can integrate with services like SaveMyLeads to automate data flow between applications. Management: RTF can be managed with A...
1 comment
Read more

Integration Design Patterns

By Gourav S
Understanding Integration Design Patterns: Integration design patterns serve as reusable templates for solving common integration problems encountered in software development. They encapsulate best practices and proven solutions, empowering developers to architect complex systems with confidence. These patterns abstract away the complexities of integration, promoting modularity, flexibility, and interoperability across components. Most Common Integration Design Patterns: Point-to-Point Integration: Point-to-Point Integration involves establishing direct connections between individual components. While simple to implement, this pattern can lead to tight coupling and scalability issues as the number of connections grows. Visualizing this pattern, imagine a network of interconnected nodes, each communicating directly with specific endpoints. Publish-Subscribe (Pub/Sub) Integration: Pub/Sub Integration decouples producers of data (publishers) from consumers (subscribers) through a central ...
Post a Comment
Read more