> ## Documentation Index > Fetch the complete documentation index at: https://docs.germainux.com/llms.txt > Use this file to discover all available pages before exploring further. # Runtime Monitoring for MuleSoft > Turn the errors in your Mule runtime logs, and the health of the runtime's JVM, into KPIs and alerts for the runtimes you host. Components [`Engine`](https://docs.germainux.com/deploy/germain-ux-engine) > [card] [How It Works](#how-it-works) > > Log parser and JMX > [card] [Before You Start](#before-you-start) > > Engine and log access > [card] [Set It Up](#set-it-up) > > Server profile and JMX > [card] [KPIs](#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. > [card] 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. > [card] 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. > [card] 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. > [card] Runtime Startup and Deployment Errors > > Errors the runtime writes to `mule_ee.log`, such as an application that failed to deploy. > [card] 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 Call Correlation ID Log Error Block JVM 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](https://mintcdn.com/germain-ux/yNXlW51ZNuuaNNHr/images/main/mulesoft-runtime-monitoring/mulesoft-log-events-by-error-type.png?fit=max\&auto=format\&n=yNXlW51ZNuuaNNHr\&q=85\&s=3f8a1be52b973d36ae7aeae45b7acc7f) 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](https://mintcdn.com/germain-ux/yNXlW51ZNuuaNNHr/images/main/mulesoft-runtime-monitoring/mulesoft-log-event-analysis.png?fit=max\&auto=format\&n=yNXlW51ZNuuaNNHr\&q=85\&s=6c42397fb2618404725210310f0f0df9) 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](https://mintcdn.com/germain-ux/yNXlW51ZNuuaNNHr/images/main/mulesoft-runtime-monitoring/mule-runtime-jvm-heap.png?fit=max\&auto=format\&n=yNXlW51ZNuuaNNHr\&q=85\&s=f293ea7f9052dd137eb1424796e6157a) Heap usage of a Mule runtime JVM - GermainUX ## How It Works | Component | What it does | | - | - | | **MuleSoft Runtime Log Directory Monitor** | Runs on a GermainUX Engine with access to the Mule log directory. It watches the `.log` files in that directory, and reads existing files when it starts. | | **MuleSoft Runtime Log Parser** | Parses each entry, keeps the ERROR, FATAL and WARN entries with their multi-line error blocks, and records each one as a **MuleSoft Log Event** | | **JVM JMX Monitor** | Connects to the runtime's JMX port and reads memory, CPU, thread, class-loading and garbage-collection values. It records them as the same Java KPIs that the GermainUX Java agent produces. | 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: | Field | Taken from | | - | - | | **Error Type / Logger** | The `Error type` line of the Mule error block, or the logger name when there is none | | **Level** | `ERROR`, `FATAL` or `WARN` | | **Flow** | The processor path, or the flow in the thread name | | **Mule Application** | The application in the thread name, or the log file name (`orders-api.log`) | | **Correlation ID** | The event ID or `correlationId` of the entry | | **Details** | The whole entry, including the error block and stack trace | 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](https://docs.germainux.com/integrations/mulesoft-monitoring/mulesoft-anypoint-platform-monitoring.md). ## 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](https://docs.germainux.com/deploy/germain-ux-engine.md) and [Profiles to Deploy at Scale](https://docs.germainux.com/management/profiles-to-deploy-at-scale.md). * 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](https://mintcdn.com/germain-ux/yNXlW51ZNuuaNNHr/images/main/mulesoft-runtime-monitoring/apply-mulesoft-runtime-profile.png?fit=max\&auto=format\&n=yNXlW51ZNuuaNNHr\&q=85\&s=1070cb94a18406c701600ae669114bf5) MuleSoft Runtime profile in the Apply Profile dialog - GermainUX **3. Enter the profile values** GermainUX opens a wizard with the fields of the profile: | Field | Value | | - | - | | **Application** | The monitored application the events belong to. The default is `MuleSoft`. | | **Mule Log Directory** | The directory that holds `mule_ee.log` and the application logs, usually `$MULE_HOME/logs`. Select an existing file path data source, or create one. | **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](https://docs.germainux.com/getting-started/support.md). 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](https://docs.germainux.com/integrations/java-monitoring.md). ### 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 > [accordion] No log events arrive > > 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. > [accordion] Some errors are missing > > 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. > [accordion] Events have no application or flow > > 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. > [accordion] No JVM metrics arrive > > 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](https://docs.germainux.com/management/compliance-privacy-and-security/data-privacy.md). ## KPIs | KPI | What it measures | Fields | | - | - | - | | **MuleSoft Log Event** | ERROR, FATAL and WARN entries of the runtime and application logs | Error Type / Logger, Level, Flow, Mule Application, Environment, Correlation ID, Details | | **Java Heap Usage**, **Java Heap Available**, **Java Heap Space Size**, **Java Heap Space Allocated** | Heap memory of the runtime JVM | — | | **Java Non-Heap Size**, **Java Non-Heap Available** | Non-heap memory of the runtime JVM | — | | **Java Process CPU Load**, **Java Thread Count** | CPU and threads of the runtime JVM | — | | **Java Loaded Class Count**, **Java Unloaded Class Count**, **Java Total Loaded Class Count** | Class loading | — | | **Java GC Count**, **Java GC Time** | Garbage collection | — | Default SLA: | SLA | KPI | Severity | Breached when | | - | - | - | - | | **Error Spike** | MuleSoft Log Event | Medium | Every 15 minutes, per error type: ERROR and FATAL entries changed by more than 200% compared with the same 15 minutes a week earlier, with at least 20 entries | For all MuleSoft KPIs, see [KPIs](https://docs.germainux.com/integrations/mulesoft-monitoring.md#kpis) on the MuleSoft overview. ## Related Documentation > [card] [Anypoint Platform Monitoring for MuleSoft](https://docs.germainux.com/integrations/mulesoft-monitoring/mulesoft-anypoint-platform-monitoring.md) > > Availability, metrics and cloud logs > [card] [Files / Logs Observability](https://docs.germainux.com/integrations/file-log-monitoring.md) > > How GermainUX reads log files > [card] [Analytics](https://docs.germainux.com/analytics.md) > > More Analytics Features ## Get Help > [card] [Contact GermainUX Support](https://docs.germainux.com/getting-started/support.md) > > 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. > [card] 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. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.