Skip to main content
ComponentsEngine

How It Works

Log parser and JMX

Before You Start

Engine and log access

Set It Up

Server profile and JMX

KPIs

Log events and JVM

​
Overview

GermainUX shows you which errors your Mule runtimes raise, in which application and flow, for the runtimes you host yourself. Each ERROR, FATAL and WARN entry in mule_ee.log and the application logs becomes a log event with its Mule error type, such as HTTP:CONNECTIVITY, its flow, application and correlation ID, and the full error block. Next to it, GermainUX tracks the runtime’s JVM: heap, CPU, threads and garbage collection. An error-spike SLA comes ready to use, so your team sees a new failure pattern, or a runtime running out of memory, before the integrations behind it stop.

Errors by Mule Error Type

Errors grouped by the Mule error type from the error block (HTTP:CONNECTIVITY, HTTP:TIMEOUT), or by logger name when there is none.

Flow and Application

The flow and Mule application each error came from, taken from the processor path, the thread name or the log file name.

Full Error Context

The whole multi-line entry, with the error message, element, flow stack and stack trace, plus the correlation ID of the Mule event.

Runtime Startup and Deployment Errors

Errors the runtime writes to mule_ee.log, such as an application that failed to deploy.

JVM Health

Heap and non-heap memory, process CPU, threads, class loading and garbage collection of the Mule runtime JVM.

​
Questions It Answers

  • Which Mule error types are we getting most, and since when?
  • Which application and flow does this error come from?
  • Did a new error type appear after the last deployment?
  • Which application failed to deploy when the runtime restarted?
  • Is the runtime running out of heap before the errors start?
  • Which API call does this log error belong to?

​
How It Connects to Other Data

Each log event keeps the correlation ID of the Mule event. When your flows also send transactions to GermainUX, the transaction and its log errors share that ID, so you go from a failed API call to the error that caused it.
Failed API CallCorrelation IDLog Error BlockJVM Heap and GC

​
See It on the Dashboard

In the left menu, select Dashboards > All, and then open MuleSoft Overview in the MuleSoft folder under Application. The Runtime Errors chart counts ERROR and FATAL log events. Click it to open the MuleSoft Log Event KPI and pivot by error type, application or flow.
Runtime Errors pivot of the MuleSoft Log Event KPI by error type, level, Mule application and flow

MuleSoft log events by error type - GermainUX

The analysis of the MuleSoft Log Event KPI shows the days with error spikes, and ranks the levels, applications and error types behind them.
Analysis Dashboard of the MuleSoft Log Event KPI with daily error counts and leading factors by system, level, Mule application and error type

Analysis of the MuleSoft Log Event KPI - GermainUX

Java Heap Usage drillthrough showing the heap usage of a Mule runtime JVM per hour over four days

Heap usage of a Mule runtime JVM - GermainUX

​
How It Works

The MuleSoft Runtime server profile deploys the log directory monitor and the log parser together on the host. The parser reads the default Mule 4 log formats: the runtime format of mule_ee.log, the application format with processor path and event ID, and the format of the Mule tracing module. It skips INFO and DEBUG entries. For each event, GermainUX takes: CloudHub 1.0, CloudHub 2.0 and Runtime Fabric applications don’t write log files you can reach. GermainUX reads their errors through Anypoint Platform instead, into the same MuleSoft Log Event KPI. See Anypoint Platform Monitoring for MuleSoft.

​
Before You Start

  • A Mule 4 runtime that you host, on a server or VM
  • A GermainUX Engine on the runtime host, or on a host that can read the Mule log directory, associated with the host in GermainUX. See GermainUX Engine and Profiles to Deploy at Scale.
  • The path of the Mule log directory, usually $MULE_HOME/logs
  • For JVM metrics: remote JMX turned on in the Mule runtime JVM, and the JMX port open to the Engine

​
Set It Up

​
Enable Log Monitoring

1

Select the Mule runtime host

In the left menu, go to Settings > Data Sources, and open the Hosts tab. Select the host that runs the Mule runtime.
2

Select the MuleSoft Runtime profile

Click Apply Profile, select MuleSoft Runtime, and click Apply.
Apply Profile dialog with the MuleSoft Runtime profile selected and the Apply button

MuleSoft Runtime profile in the Apply Profile dialog - GermainUX

3

Enter the profile values

GermainUX opens a wizard with the fields of the profile:
4

Finish the wizard

Finish the wizard. GermainUX deploys the MuleSoft Runtime Log Directory Monitor and the MuleSoft Runtime Log Parser on the host’s Engine.
Repeat these steps for each host that runs a Mule runtime.

​
Enable JVM Monitoring (Optional)

The GermainUX team sets up the JVM JMX Monitor component for your runtimes. Before you contact them:
1

Turn on remote JMX

Turn on remote JMX for the Mule runtime JVM, in $MULE_HOME/conf/wrapper.conf, and restart the runtime. Follow your organization’s rules for JMX authentication and TLS.
2

Open the JMX port to the Engine

Allow the GermainUX Engine to reach the JMX port on the runtime host.
3

Send the connection details to GermainUX support

Send the host, the JMX port and the JMX credentials, if any, to GermainUX Support. Share credentials through a secure channel.
For deeper data, such as database (JDBC) and JMS calls, add the GermainUX Java agent to the runtime instead. See Java Operational Experience Intelligence.

​
Disable Monitoring

1

Find the components

In the left menu, go to Settings > Germain > State, open Components, and search for MuleSoft Runtime.
2

Turn them off

Turn off Enabled for the MuleSoft Runtime Log Directory Monitor and the MuleSoft Runtime Log Parser of the host.

​
Validate

Cause a test error in a non-production application, for example by calling an API whose backend is unreachable. Within a few minutes:
  • The Runtime Errors chart on the MuleSoft Overview dashboard counts the error
  • The MuleSoft Log Event KPI shows it with its Mule error type, application and flow
  • Details holds the whole error block
For JVM monitoring, check that the Java Heap Usage KPI has values for the runtime JVM.

​
Troubleshooting

Check that the Mule Log Directory points to the directory that holds mule_ee.log, not to a single file, and that the Engine’s user can read the files. The directory monitor doesn’t read subdirectories.
The parser reads the default Mule 4 log formats. If your log4j2.xml uses a custom pattern, the entries don’t match and GermainUX skips them. Use the default pattern for the application logs, or contact GermainUX support to adapt the parser.
GermainUX takes the application and flow from the thread name, the processor path or the log file name. Entries the runtime writes outside a flow, such as startup errors in mule_ee.log, have no flow.
Check that remote JMX is on in wrapper.conf, that the runtime was restarted afterwards, and that the Engine reaches the JMX port.

​
Security and Privacy

Runtime log data includes personal data:
  • Log messages: Details holds the full log entry, including error messages, element definitions and stack traces, which can include URLs, customer identifiers and payload fragments
  • Infrastructure data: the log file path and the application, flow and host names
  • Free text: log messages contain whatever your applications write into them, so treat them as possibly containing personal or customer data
To mask, anonymize or exclude this data, see Data Privacy.

​
KPIs

Default SLA: For all MuleSoft KPIs, see KPIs on the MuleSoft overview.

Anypoint Platform Monitoring for MuleSoft

Availability, metrics and cloud logs

Files / Logs Observability

How GermainUX reads log files

Analytics

More Analytics Features

​
Get Help

Contact GermainUX Support

The GermainUX team helps you get up and running faster, empower your team, turn data into actionable insights, and optimize performance to deliver measurable business outcomes.

Can't Find What You Need?

Search all GermainUX docs with Ctrl + K, or use the feedback buttons at the bottom of this page to tell us what is missing.

The content of this document is proprietary to GERMAIN SOFTWARE.