Mule Applications Test
Mule applications are created to perform system integrations. Typically, the application reads data from internal and external sources, processes and transforms data to the required formats or structures, and writes that output to the systems and servers where you store or use the transformed data. Mule applications are configured to run in Mule runtime engine (Mule). A request to a Mule application triggers Mule to encode the request and data in a Mule event and to pass it to either single or multiple threads. Mule apps process messages and other parts of Mule events through Mule components, connectors, and modules that are set up within the scope of Flow and Subflow components within an app. At the simplest level, flows are sequences of processors. A message that enters a flow can pass through a variety of processors. In a typical flow, a Mule application receives a message through a source (such as an HTTP Listener component), transforms that message into a new format, and processes any business logic before writing the processed message to an external system in a format that the system can read.
Any exception that occurs during the message processing through a Mule flow can hinder the normal flow execution and thereby cause failure of user requests. If the number of failed requests are left unnoticed it can lead to critical errors and hence affect the smooth running of your application. Any unexpected surge in incoming traffic or high average processing time of events can lead to bottleneck conditions that adversely affects the message processing capability of the application. Hence it is very crucial to identify and resolve such discrepancies way before it affects the availability or performance of the Mule applications.
This test auto-discovers each Mule flow in every application deployed on the Mule ESB and reports the number of fatal errors and execution errors. In addition, this test also points to the average processing time, processed events, synchronous and asynchronous events received by each application. This way, the test helps you to proactively identify any error conditions or processing bottlenecks and problematic or error-prone Mule flows before it degrades the user experience.
Target of the test : A Mule ESB
Agent deploying the test : An internal/remote agent
Outputs of the test : One set of results for each application:flow on the target Mule ESB being monitored.
First-level Descriptor: Mule Application
Second-level Descriptor: Mule Flow
Parameters | Description |
---|---|
Test Period |
How often should the test be executed. |
Host |
The host for which the test is to be configured. |
Port |
The port number at which the specified host listens. |
JMX Remote Port |
To collect metrics from a Mule ESB, the eG agent monitoring that server should be configured to use JMX to connect to the JRE used by the server and pull out the metrics of interest. Here, specify the port at which the jmx listens for requests from remote hosts. Ensure that you specify the same port that you configured in the ${MULE_HOME}/conf/wrapper.conf of the target application For more details, refer to Pre-requisites for Monitoring the Mule ESB |
JMX User, |
By default, the JMX connector on the Mule ESB requires no authentication and security, in that case set the JMX User and JMX Password parameters as none. If the JMX connector on the Mule ESB requires both authentication and security, then to enable the eG agent to use JMX, you need to configure the agent with the credentials of a user who is authorized to use JMX and has read only privileges. You can hence configure the JMX User and JMX Password parameters with the credentials of a user with monitor role given in jmxremote.password and jmxremote.access files. To know the credentials of such a user, refer to Pre-requisites for Monitoring the Mule ESB Confirm the JMX Password you specify by retyping that password in the Confirm Password text box. |
JNDIName |
The JNDIName is a lookup name for connecting to the JMX connector. By default, this is jmxrmi. If you have registered the JMX connector in the RMI registry using a different lookup name, then you can change this default value to reflect the same. |
JMX Provider |
This test uses a JMX Provider to access the MBean attributes of the Mule ESB and collect metrics. Specify the package name of this JMX Provider here. By default, this is set to com.sun.jmx.remote.protocol. |
Timeout |
Specify the duration (in seconds) for which this test should wait for a response from the Mule ESB. If there is no response from the server beyond the configured duration, the test will timeout. By default, this is set to 1000 seconds. |
Measurement | Description | Measurement Unit | Interpretation |
---|---|---|---|
Execution errors |
Indicates the number of execution errors occurred in this flow on this application. |
Number |
A low value is desired for this measure. This error occurs when there is any exception during the processing of message through a Mule flow and this in turn causes normal flow execution stops. Execution errors may cause failure of user requests. Compare the value of this measure across Mule flows to isolate the flows that are error-prone. For the Summary descriptor, this measure reports the number of execution errors occurred across all the flows in the application. |
Fatal errors |
Indicates the number of erroneous/failed requests occurred in this flow on this application. |
Number |
A low value is desired for this measure. Fatal errors are very critical and can affect the performance of the application. Compare the value of this measure across Mule flows to isolate the flows that are error-prone. For the Summary descriptor, this measure reports the number of fatal errors occurred across all the flows in the application. |
Processed events |
Indicates the number of events processed by this flow on this application. |
Number |
This measure helps to analyze the incoming traffic to your application. Mule collects events information for the flows and message processors to handle the business transactions. For the Summary descriptor, this measure reports the number of events processed across all the flows in the application. |
Average processing time |
Indicates the average time taken to process any event by this flow on this application. |
Seconds |
A low value is desired for this measure. A high value indicates that the flow is taking more time to process events and hence is an indication of bottleneck conditions. Compare the value of this measure across Mule flows to isolate the flows that were taking too long to process events. For the Summary descriptor, this measure reports the average time taken to process events across all the flows in the application. |
Synchronous events received |
Indicates the number of messages processed synchronously by this flow on this application. |
Number |
Synchronous type of flow processes messages along a single thread, which is ideally suited to transactional processing. For the Summary descriptor, this measure reports the number of messages processed synchronously across all the flows in the application. |
Total events received |
Indicates the total number of events received by this flow on this application. |
Number |
For the Summary descriptor, this measure reports the total number of events received across all the flows in the application. |
Asynchronous events received |
Indicates the number of messages processed asynchronously by this flow on this application. |
Number |
Asynchronous type of flow processes messages along multiple threads. For the Summary descriptor, this measure reports the number of messages processed asynchronously across all the flows in the application. |