Skip to main content
ComponentsEngine

How It Works

Polling Anypoint every 5 minutes

Before You Start

Connected app and IDs

Set It Up

Wizard, queues, restarts

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.

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.

Hybrid Servers and Stopped Flows

Whether each hybrid server is connected to Runtime Manager, and which flows of a started application have stopped.

Requests and Response Time

Inbound requests per application and HTTP status group (2xx, 4xx, 5xx), and average response time, from Anypoint Monitoring.

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.

CloudHub Alerts

Every time an alert you defined in Runtime Manager for CloudHub 1.0 fires, with its severity and context.

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

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

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

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

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 DownLog ErrorsFailing API OperationDownstream Service
See Deploy GermainUX Monitoring for MuleSoft for the transactions your flows send.

How It Works

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:

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.
  • 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

MuleSoft Anypoint Platform wizard card - GermainUX

3

Connect to Anypoint Platform

In the Anypoint Platform step, enter:
Anypoint Platform step with the Anypoint Region, Connected App Credentials, Organization ID and Application Name fields

Anypoint Platform step of the wizard - GermainUX

4

Choose the environment

In the Environment step, enter:
Environment step with the Environment ID and Environment Name fields and the Poll Logs and Create RTF Restart Action checkboxes

Environment step of the wizard - GermainUX

5

Choose where the monitor runs

In the Deployment step, enter:
Deployment step with the Monitor Name, Monitoring Node and Engine fields, and the schedule set to every 5 minutes

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. Repeat the wizard for each other environment.
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

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: 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, Automated Actions and HTTP and HTTPS Execution.
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) 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

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.
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.
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.
This is intended. GermainUX skips applications whose desired state is stopped or undeployed, so a planned stop doesn’t raise an alert.
Anypoint Platform doesn’t hold the logs of hybrid runtimes. GermainUX reads them from the runtime’s log files. See Runtime Monitoring for MuleSoft.

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

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

Runtime Monitoring for MuleSoft

Log files and JVM of hybrid runtimes

Analytics

More Analytics Features

Automation

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.

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.