> ## 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. # Anypoint Platform Monitoring for MuleSoft > See which Mule applications, replicas, servers and flows are down, and how their traffic and errors change, straight from Anypoint Platform. Components [`Engine`](https://docs.germainux.com/deploy/germain-ux-engine) > [card] [How It Works](#how-it-works) > > Polling Anypoint every 5 minutes > [card] [Before You Start](#before-you-start) > > Connected app and IDs > [card] [Set It Up](#set-it-up) > > Wizard, queues, restarts > [card] [KPIs](#kpis) > > Availability, traffic, alerts ## Overview GermainUX shows you **which Mule applications are down or degraded** in each Anypoint environment, without any change to your Mule flows. You see application, replica, server and flow availability for CloudHub 1.0, CloudHub 2.0, Runtime Fabric and hybrid runtimes, next to inbound request volume, server errors and response time from Anypoint Monitoring. Errors and warnings from your cloud applications' logs, CloudHub alerts and Anypoint MQ queue depth arrive in the same place. Availability, traffic and error KPIs come with default SLAs, so your team hears about a crashed replica or a stopped flow before the connected applications do. > [card] Application and Replica Availability > > Whether each deployed application is running, and how many of its CloudHub 2.0 or Runtime Fabric replicas are up, with the reason a replica is down. > [card] Hybrid Servers and Stopped Flows > > Whether each hybrid server is connected to Runtime Manager, and which flows of a started application have stopped. > [card] Requests and Response Time > > Inbound requests per application and HTTP status group (2xx, 4xx, 5xx), and average response time, from Anypoint Monitoring. > [card] Errors and Warnings from Cloud Logs > > New ERROR, FATAL and WARN log lines of CloudHub 1.0, CloudHub 2.0 and Runtime Fabric applications, grouped by Mule error type and flow. > [card] CloudHub Alerts > > Every time an alert you defined in Runtime Manager for CloudHub 1.0 fires, with its severity and context. > [card] Anypoint MQ Queue Depth > > Messages waiting and in flight in each Anypoint MQ queue, to catch a backlog when a consumer stops. ### Questions It Answers * Which Mule applications are down right now, and in which environment? * How many replicas of this application are running, and why did the others stop? * Which flows stopped on our hybrid runtimes? * Which application started returning 5xx errors, and since when? * Did response time change after the last deployment? * Is a queue backing up because its consumer stopped? ### What Each Deployment Model Gives You | Deployment model | What GermainUX collects | | - | - | | **CloudHub 2.0 and Runtime Fabric** | Application availability, replica availability, and new ERROR and WARN log lines | | **CloudHub 1.0** | Application availability, new ERROR and WARN log lines, and the alerts Runtime Manager fires | | **Hybrid (customer-hosted runtimes)** | Server connection status, application availability and stopped flows. Logs come from the runtime log files, see [Runtime Monitoring for MuleSoft](https://docs.germainux.com/integrations/mulesoft-monitoring/mulesoft-runtime-monitoring.md). | | **All models** | Requests per HTTP status group and average response time from Anypoint Monitoring, and Anypoint MQ queue depth when you turn it on | GermainUX skips applications you stopped or undeployed on purpose, so they don't show as down. ### See It on the Dashboard In the left menu, select **Dashboards > All**, and then open **MuleSoft Overview** in the **MuleSoft** folder under **Application**. The **Anypoint Requests**, **Anypoint Server Errors**, **Anypoint Response Time** and **Anypoint Applications Down** charts show the Anypoint data. Click a chart to open the KPI behind it and drill into an application, environment or check. ![MuleSoft Overview dashboard with the API charts, Runtime Errors, and the Anypoint Requests, Server Errors, Response Time and Applications Down charts](https://mintcdn.com/germain-ux/yNXlW51ZNuuaNNHr/images/main/mulesoft-anypoint-platform-monitoring/mulesoft-overview-anypoint-charts.png?fit=max\&auto=format\&n=yNXlW51ZNuuaNNHr\&q=85\&s=79262652d6da5ff53d8ce7970ecc6975) MuleSoft Overview dashboard - GermainUX To see what is down, open the **MuleSoft Availability** KPI. Each row is one resource and check, with the reason in **Details**: the deployment and application status, the replicas that aren't running, or the names of the stopped flows. ![MuleSoft Availability pivot by resource, check, resource ID and system name, with the SLA status of each row](https://mintcdn.com/germain-ux/yNXlW51ZNuuaNNHr/images/main/mulesoft-anypoint-platform-monitoring/mulesoft-availability-by-resource.png?fit=max\&auto=format\&n=yNXlW51ZNuuaNNHr\&q=85\&s=f41af8abf3e52e2d88cf173192ae77fe) MuleSoft Availability by resource and check - GermainUX To see what drives a change in traffic, open the analysis of the **MuleSoft App Requests** KPI. It ranks the status groups and applications that changed most, for example a spike in 5xx requests. ![Analysis Dashboard of the MuleSoft App Requests KPI with leading factors by status group and application, including a 5xx spike](https://mintcdn.com/germain-ux/yNXlW51ZNuuaNNHr/images/main/mulesoft-anypoint-platform-monitoring/mulesoft-app-requests-analysis.png?fit=max\&auto=format\&n=yNXlW51ZNuuaNNHr\&q=85\&s=81e09b6e5abec59ebce2e654c4b91827) Analysis of the MuleSoft App Requests KPI - GermainUX ### How It Connects to Other Data Anypoint data tells you that an application is down or erroring. The transactions your Mule flows send, and the runtime logs, tell you which operation failed and why. With all three in GermainUX, you go from the alert to the failing call in one place. Application Down Log Errors Failing API Operation Downstream Service See [Deploy GermainUX Monitoring for MuleSoft](https://docs.germainux.com/integrations/mulesoft-monitoring/deploying-germainux-monitoring-for-mulesoft-a-step-by-step-guide.md) for the transactions your flows send. ## How It Works | Component | What it does | | - | - | | **MuleSoft Anypoint Monitor** | A GermainUX Engine component that calls the Anypoint Platform REST APIs every 5 minutes, for one organization and environment. It signs in with a connected app (client credentials). | | **Runtime Manager APIs** | Give the deployments, applications, replicas, servers and flows, their status, and the alerts CloudHub 1.0 fired | | **Anypoint Monitoring Metrics API** | Gives request counts per HTTP status group and average response time per application | | **Application logs** | GermainUX reads only the ERROR and WARN lines added since the previous poll, so each line arrives once | | **Anypoint MQ APIs** | Give the number of messages and in-flight messages per queue, when you turn queue monitoring on | Each poll lists the applications first, then asks for the details of each running one. The request metrics cover the window from 7 to 2 minutes before the poll, which leaves Anypoint Monitoring time to aggregate them. Availability is recorded as a percentage per resource and check: | Check | Value | | - | - | | **Application** | `100` when the application runs, `0` when it failed or isn't running | | **Replicas** | Running replicas as a percentage of the desired replicas (CloudHub 2.0 and Runtime Fabric) | | **Flows** | Running flows as a percentage of the flows expected to run (hybrid) | | **Server** | `100` when the server is connected to Runtime Manager, `0` when it's disconnected (hybrid) | ## Before You Start * A GermainUX Engine that can reach your Anypoint Platform control plane over HTTPS, for example `anypoint.mulesoft.com` or `eu1.anypoint.mulesoft.com`. See [GermainUX Engine](https://docs.germainux.com/deploy/germain-ux-engine.md). * A connected app in Anypoint Platform that acts on its own behalf (client credentials), with read access to the applications in each environment you monitor * Anypoint Monitoring in your organization, for request and response-time metrics * Your organization ID and the ID and name of each environment to monitor * The Anypoint MQ region, if you want queue depth ## Set It Up The **MuleSoft Anypoint Platform** wizard sets up monitoring for one Anypoint environment. It creates a **MuleSoft Anypoint Monitor** component on the Engine you choose, and optionally an HTTP action that restarts Runtime Fabric applications. Run it once for each environment you want to monitor. ### Enable Monitoring **1. Create the connected app** In Anypoint Platform, create a connected app that acts on its own behalf (client credentials), with read access to the applications of the environments you want to monitor. To collect request metrics, give it access to Anypoint Monitoring. For queue depth, give it access to Anypoint MQ. Note its client ID and client secret. **2. Open the wizard** In the left menu, go to **Settings > Wizards**. On the **MuleSoft Anypoint Platform** card, click **Add**. ![MuleSoft Anypoint Platform card on the Wizards screen, with the Add and Manage buttons](https://mintcdn.com/germain-ux/yNXlW51ZNuuaNNHr/images/main/mulesoft-anypoint-platform-monitoring/mulesoft-anypoint-platform-wizard-card.png?fit=max\&auto=format\&n=yNXlW51ZNuuaNNHr\&q=85\&s=404489fb7ec3194b33c288c67f7bfaa1) MuleSoft Anypoint Platform wizard card - GermainUX **3. Connect to Anypoint Platform** In the **Anypoint Platform** step, enter: | Field | Value | | - | - | | **Anypoint Region** | The control plane of your organization: **US** (the default), **EU**, **Canada**, **Japan**, **India** or **Australia** | | **Connected App Credentials** | Select the credentials of the connected app, or click **+** to create them: the user name is the client ID, and the password is the client secret | | **Organization ID** | The ID of the Anypoint organization (business group) the applications belong to | | **Application Name** | The monitored application the data belongs to in GermainUX. The default is `MuleSoft`. | ![Anypoint Platform step with the Anypoint Region, Connected App Credentials, Organization ID and Application Name fields](https://mintcdn.com/germain-ux/yNXlW51ZNuuaNNHr/images/main/mulesoft-anypoint-platform-monitoring/wizard-anypoint-platform-step.png?fit=max\&auto=format\&n=yNXlW51ZNuuaNNHr\&q=85\&s=f83f727cfd9d155eae30cec743e33946) Anypoint Platform step of the wizard - GermainUX **4. Choose the environment** In the **Environment** step, enter: | Field | Value | | - | - | | **Environment ID** | The ID of the Anypoint environment to monitor | | **Environment Name** | The name GermainUX shows in the **Environment** field of every MuleSoft KPI, such as `Production` | | **Poll Logs** | On by default: GermainUX collects the ERROR and WARN lines of CloudHub 1.0, CloudHub 2.0 and Runtime Fabric applications. See [Turn Off Log Polling](#turn-off-log-polling-optional). | | **Create RTF Restart Action** | Off by default. Turn it on to also create an HTTP action that restarts Runtime Fabric applications of this environment. See [Restart Applications Automatically](#restart-applications-automatically-optional). | ![Environment step with the Environment ID and Environment Name fields and the Poll Logs and Create RTF Restart Action checkboxes](https://mintcdn.com/germain-ux/yNXlW51ZNuuaNNHr/images/main/mulesoft-anypoint-platform-monitoring/wizard-environment-step.png?fit=max\&auto=format\&n=yNXlW51ZNuuaNNHr\&q=85\&s=5a9b52d1468b7c300dac91faee6dd797) Environment step of the wizard - GermainUX **5. Choose where the monitor runs** In the **Deployment** step, enter: | Field | Value | | - | - | | **Monitor Name** | A name for the monitor. The default is `MuleSoft Anypoint`. Add the environment, such as `MuleSoft Anypoint Production`, when you monitor several environments. | | **Monitoring Node** | The monitoring node to deploy the monitor to | | **Engine** | The Engine that runs the monitor. It must reach the Anypoint control plane over HTTPS. | | **Schedule on which to run this component** | Every 5 minutes, the default (cron expression `0 */5 * * * *`). See [Change the Monitoring Frequency](#change-the-monitoring-frequency). | ![Deployment step with the Monitor Name, Monitoring Node and Engine fields, and the schedule set to every 5 minutes](https://mintcdn.com/germain-ux/yNXlW51ZNuuaNNHr/images/main/mulesoft-anypoint-platform-monitoring/wizard-deployment-step.png?fit=max\&auto=format\&n=yNXlW51ZNuuaNNHr\&q=85\&s=818a1552b0eb5c691c259f808bc133c5) Deployment step of the wizard - GermainUX **6. Finish the wizard** Finish the wizard. GermainUX creates the monitor, and data arrives at its first poll, within 5 minutes. See [Validate](#validate). Repeat the wizard for each other environment. > [!WARNING] > > The client secret gives access to your Anypoint organization. Give the connected app only the access it needs, and rotate the secret the way your organization requires. ### Change the Monitoring Frequency The wizard schedules the monitor every 5 minutes. Keep that interval: the request metrics cover a 5-minute window, so a longer interval leaves gaps, and a shorter one counts requests twice. ### Monitor Anypoint MQ Queues (Optional) Queue monitoring is off by default. Ask the GermainUX team to turn it on, and give them the Anypoint MQ region of your queues, such as `us-east-1`. GermainUX then records the messages waiting and in flight in every queue of the environment, at each poll. The Anypoint MQ API allows 100 requests per minute, so GermainUX asks for the statistics of up to 50 queues per request. The analysis of the **MuleSoft MQ Messages** KPI shows which queue is backing up, such as a notifications queue whose consumer stopped. ![Analysis Dashboard of the MuleSoft MQ Messages KPI with a queue backlog over several hours and leading factors by queue](https://mintcdn.com/germain-ux/yNXlW51ZNuuaNNHr/images/main/mulesoft-anypoint-platform-monitoring/mulesoft-mq-messages-analysis.png?fit=max\&auto=format\&n=yNXlW51ZNuuaNNHr\&q=85\&s=20f5a38447ff192bcab348179a08a2f7) Analysis of the MuleSoft MQ Messages KPI - GermainUX ### Turn Off Log Polling (Optional) By default, GermainUX reads the new ERROR and WARN lines of every running CloudHub 1.0, CloudHub 2.0 and Runtime Fabric application. If you already collect these logs another way, turn off **Poll Logs** in the **Environment** step of the wizard. Availability, metrics and alerts keep working. ### Restart Applications Automatically (Optional) GermainUX can restart a Mule application when its availability SLA is breached. It ships two HTTP actions that call the Anypoint Platform APIs: | Action | Restarts | Set up | | - | - | - | | **MuleSoft RTF Restart Application** | The Runtime Fabric application of the fact that breached the SLA | One action per environment. Turn on **Create RTF Restart Action** in the wizard, and GermainUX creates **MuleSoft RTF Restart Application - ENVIRONMENT\_NAME**. | | **MuleSoft CloudHub 1.0 Restart Application** | One CloudHub 1.0 application | One action per application, set up by the GermainUX team | Each action restarts an application at most once every 30 minutes, so a crash loop doesn't trigger a restart loop. Neither action restarts CloudHub 2.0 applications. The action signs in with the same connected app as the monitor, so the connected app needs permission to restart applications. The action does nothing until you attach it to the **Down** or **Degraded** SLA of the **MuleSoft Availability** KPI (**Application** or **Replicas** check). See [Configure SLA](https://docs.germainux.com/analytics/slas/configure-sla.md), [Automated Actions](https://docs.germainux.com/automation/automated-actions.md) and [HTTP and HTTPS Execution](https://docs.germainux.com/automation/synthetic-http-execution.md). > [!NOTE] > > An automatic restart changes your production environment. Agree on which applications GermainUX may restart before you turn it on. ### Disable Monitoring **1. Find the component** In the left menu, go to **Settings > Wizards**, and click **Manage** on the **MuleSoft Anypoint Platform** card. Or go to **Settings > Germain > State**, open **Components**, and search for the monitor by its name. **2. Turn it off** Turn off **Enabled** for the environment you want to stop monitoring. ## Validate Five minutes after you finish the wizard, open the **MuleSoft Overview** dashboard (see [See It on the Dashboard](#see-it-on-the-dashboard)) and check that: * **Anypoint Applications Down** is empty, or lists only applications that really are down * The **MuleSoft Availability** KPI has a row for each running application, with the environment name you gave * **Anypoint Requests** shows traffic for applications that received requests * Errors from cloud applications appear in **Runtime Errors** To test an alert, stop one replica or flow in a non-production environment. The **Degraded** SLA is breached after three polls in a row, about 15 minutes. ## Troubleshooting > [accordion] No Anypoint data arrives > > Check the Engine log for a line such as `MuleSoft Anypoint target 'amc-deployments' ... returned HTTP 401`. A `401` means the client ID or secret is wrong, and a `403` means the connected app lacks access to that environment or API. Also check that the Engine reaches the control plane of your region over HTTPS. > [accordion] Availability is there, but requests and response time are missing > > These come from Anypoint Monitoring. Check that your organization has Anypoint Monitoring and that the connected app can read its metrics. An application with no inbound requests in the window has no request rows. > [accordion] Requests show an application ID instead of its name > > GermainUX takes application names from the deployment and application lists it reads in the same poll. If the calls for that deployment model are turned off, it can't resolve the name. Ask the GermainUX team to turn on the calls for the deployment models you use. > [accordion] A stopped application doesn't show as down > > This is intended. GermainUX skips applications whose desired state is stopped or undeployed, so a planned stop doesn't raise an alert. > [accordion] Hybrid applications have no log events > > Anypoint Platform doesn't hold the logs of hybrid runtimes. GermainUX reads them from the runtime's log files. See [Runtime Monitoring for MuleSoft](https://docs.germainux.com/integrations/mulesoft-monitoring/mulesoft-runtime-monitoring.md). ## Security and Privacy Anypoint Platform data includes personal data: * **Log messages**: the **Details** of each MuleSoft Log Event hold the full log line and error block your applications wrote, which can include customer identifiers, payload fragments and user names * **Alert context**: the **Details** of each MuleSoft Platform Alert hold the context Runtime Manager sends with the alert * **Free text**: log messages and alert context contain whatever your applications and Runtime Manager write into them, so treat them as possibly containing personal or customer data The connected app's client ID and secret are stored as GermainUX credentials, which the monitor and the restart action refer to. To mask, anonymize or exclude this data, see Data Privacy. ## KPIs | KPI | What it measures | Fields | | - | - | - | | **MuleSoft Availability** | Availability in % per resource and check (Application, Replicas, Flows, Server) | Resource, Check, Environment, Resource ID, Details | | **MuleSoft App Requests** | Inbound requests per application and HTTP status group, per poll | Application, Status Group, Environment | | **MuleSoft App Response Time** | Average inbound response time per application, in milliseconds | Application, Environment | | **MuleSoft Log Event** | ERROR, FATAL and WARN log lines of cloud applications | Error Type / Logger, Level, Flow, Mule Application, Environment, Correlation ID, Details | | **MuleSoft Platform Alerts** | Each trigger of a CloudHub 1.0 alert | Alert, Severity, Application, Environment, Details | | **MuleSoft MQ Messages** | Messages in an Anypoint MQ queue | Queue, Environment | | **MuleSoft MQ In-flight Messages** | Messages received but not yet acknowledged in a queue | Queue, Environment | Default SLAs: | SLA | KPI | Severity | Breached when | | - | - | - | - | | **Down** | MuleSoft Availability | High | An **Application** or **Server** check is below 100% for three polls in a row. It recovers at the next poll at 100%. | | **Degraded** | MuleSoft Availability | Medium | A **Replicas** or **Flows** check is below 100% for three polls in a row | | **Server Error Spike** | MuleSoft App Requests | Medium | Every 15 minutes, per application: the 5xx requests of the last 15 minutes changed by more than 200% compared with the same 15 minutes a week earlier, with at least 20 requests | | **Response Time Spike** | MuleSoft App Response Time | Medium | Every 15 minutes, per application: the average response time changed by more than 200% compared with the same 15 minutes a week earlier | | **Error Spike** | MuleSoft Log Event | Medium | Every 15 minutes, per error type: ERROR and FATAL lines changed by more than 200% compared with the same 15 minutes a week earlier, with at least 20 lines | For all MuleSoft KPIs, see [KPIs](https://docs.germainux.com/integrations/mulesoft-monitoring.md#kpis) on the MuleSoft overview. ## Related Documentation > [card] [Runtime Monitoring for MuleSoft](https://docs.germainux.com/integrations/mulesoft-monitoring/mulesoft-runtime-monitoring.md) > > Log files and JVM of hybrid runtimes > [card] [Analytics](https://docs.germainux.com/analytics.md) > > More Analytics Features > [card] [Automation](https://docs.germainux.com/automation.md) > > More Automation Features ## Get Help What GermainUX collects depends on the deployment models and Anypoint features you use. The GermainUX team can help you set up queue monitoring, CloudHub 1.0 restart actions, and the calls for your deployment models. > [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.