Monitoring MuleSoft 4

Monitor your MuleSoft 4 Anypoint platform solutions run-time environment with the Mule ESB Monitoring Agent for Nodinite and get alerts whenever there is a problem detected.

This section describes what's being monitored and the rules for how Nodinite translates this into meaningful monitoring states. Also, some remote commands are available as Actions to help you swiftly manage problems. Actions are further detailed on the Managing Mule 4.x page.

Features

• Automatic Discovery
  • The Nodinite MuleSoft agents make use of the MuleSoft Rest API'S and offer you an automatic discovery of your Mule Apps. Sharing access to any individual Mule App is very easy from within Nodinite using Monitor Views.
• State Evaluation - Make sure the Mule Apps has the intended run-time state!
  • STARTED/STOPPED - Provides means to get you alerted if anyone disables your Mule flow

    If Nodinite can't check the state of your MuleSoft Apps, chances are no one else can use them either

• Category-based monitoring - To help you sort out the different type of MuleSoft artifacts, the monitored Resources are grouped by Categories
  
  List of categories being monitored.

State evaluation for Mule Resources

Mule ESB Monitoring Agent for Nodinite provide detailed information and remote action on the MuleSoft 4.x resources. The following Mule Categories are supported:

• Application
• Flow
• Server

Application

List of Mule Apps in a Monitor View.

One Mule App will be displayed within Nodinite as one Resource. If you have 42 deployed Mule Apps, then you will have 42 Resources categorized as Mule Application in Nodinite regardless of each application flow(s) count and server(s).

• The name of the Resources comes from the name of the deployed Mule App prefixed by the deployment target name.
• All Mule Apps belong to the 'Mule Application' category
• The Application name is based on physical deployment paths. This pattern guarantees uniqueness:
  • Configuration name/environment name/target name/mule app name

Here's an example of Application naming pattern.

Each Mule App (presented in Nodinite as a Resource) has one of the following evaluated states at any given moment:

	State	Status	Description	Actions
	Unavailable	Resource not available	If the mule App can't be evaluated either due to network or deployment problems	Review Prerequisites
	Error	Application is not running	Mule App is stopped/undeployed or Not running there are failed runs	Start mule application
	Warning	Application in transition state	Mule App exists in starting/stopping or undeploying state
	OK	Running and accept request	Mule app is running and/or there are no failed runs

From within Nodinite, you can reconfigure the state evaluation on Resource level using the Expected State feature.

Flow

List of Mule Flows in a Monitor View.

One Mule flow will be displayed within Nodinite as one Resource. If you have 20 deployed with numerous deployed applications Mule flows, then you will have 20 Resources categorized as Mule Flow in Nodinite.

• The name of the Resources comes from the name of the Mule flow within certain applications prefixed by the deployment application name preceded by the target name.
• All Mule Flows belong to the 'Mule Flow' category
• The Flow name is based on physical deployment paths. This pattern guarantees uniqueness:
  • Configuration name/environment name/target name/mule app name/mule flow name

Here's an example of Flow naming pattern

Each Mule Flow (presented in Nodinite as a Resource) has one of the following evaluated states at any given moment:

	State	Status	Description	Actions
	Error	Flow is not running	Mule flow is Stopped or not running, there are failed runs	Start mule flow
	Warning	Unmanaged flow	Flow in freely transition states(Apps behavior)
	OK	Within user-defined thresholds	Mule app is running and/or there are no failed runs

From within Nodinite, you can reconfigure the state evaluation on Resource level using the Expected State feature.

Server

List of Mule Servers in a Monitor View

One Mule server will be displayed within Nodinite as one Resource. If you have 3 added servers, then you will have 3 Resources categorized as Mule Server in Nodinite.

• The name of the Resources comes from the name of the Mule server.
• All Mule Servers belong to the 'Mule Server' category
• The Server name is based on deployment name. This pattern guarantees uniqueness:
  • Configuration name/environment name/target name
    Here's an example of Target/Server naming pattern

Each Mule Server (presented in Nodinite as a Resource) has one of the following evaluated states at any given moment:

	State	Status	Description	Actions
	Error	Disconnected	Mule server is stopped or not running, there are failed runs	Start mule server
	Warning	Created/Connected	Server is available but not ready to accept requests
	OK	Running	Mule server is running, and accepting requests

From within Nodinite, you can reconfigure the state evaluation on Resource level using the Expected State feature.

Next step

• Managing Mule 4.x

Related

• Prerequisites
• Resources
• Categories
• Applications