Analyzing Statistics for Endpoints

This section explains how to view and analyze statistics relating to the ESB profile endpoints using WSO2 Analytics.

Use one of the following methods to view information in this page.

When you open the EI Analytics dashboard, the Overview page is displayed by default. Click on an endpoint in the TOP ENDPOINTS BY REQUEST COUNT gadget to view information relating to that endpoint.
Click ENDPOINT in the left navigator to open the OVERVIEW/ENDPOINT page, and search for the endpoint for which you want to view information.
Click on an endpoint that appears in the MESSAGE FLOW gadget in any of the following pages. This opens the OVERVIEW/ENDPOINT page with information relating to the endpoint you clicked on.
- OVERVIEW/PROXY
- OVERVIEW/API
- OVERVIEW/SEQUENCES

At any given time, this page displays the statistics for a selected time interval. Make sure you select the required time interval in the following bar displayed at the top of the page. If you want to define a custom time interval, click Custom and select the start and end dates of the required time interval in the calendar that appears.

Endpoint Request Count

View (Example)
Description	This indicates the total number of requests sent to the selected endpoint during a selected time interval. The successfully processed messages as well as the failed messages are displayed as a percentage of the total number of messages sent to the endpoint.
Purpose	This allows you to assess the extent to which an endpoint is used as well as the validity of the endpoint.
Recommended action	Compare the endpoint success rate for different time intervals. If the success rate is low during a specific time interval, check whether any unusual occurrences have taken place during that time interval (e.g., system downtime, unavailability of the back-end service.

Message Count

View (Example)
Description	This provides a graphical view of the count for both successful and failed messages that have been sent to an endpoint during a selected time interval.
Purpose	This allows you to identify any correlation that may exist between message failure rate, throughput and time. As a result, you can identify unusual occurrences that may have occurred during specific times (e.g., system downtime) as well as be aware if an endpoint cannot handle a high throughput.
Recommended action	If the message failure is particularly high during a specific time, you can check whether any unusual occurrences have taken place during that time (e.g., system downtime, unavailability of the back-end service) and take appropriate action.

Message Lantency

View (Example)
Description	The time taken per request sent to the selected endpoint to pass through the complete mediation flow.
Purpose	This allows you to understand the efficiency with which messages received by the ESB profile are sent to the selected endpoint.
Recommended action	If the message latency is high during a specific time interval, view the number of requests sent to the endpoint during the same time interval in order to check whether the endpoint has been available during that time interval. If the message latency is persistently low, check the back-end service for system errors.

Messages

View (Example)
Description	This provides the list of message IDS that were processed by a proxy service. Details including the port, time stamp and whether the message is successfully processed are displayed for each message ID. Messages can be sorted in an ascending or descending order based on the message ID, host, start time or status. You can search for specific message IDs, as well as click on a message ID to view more details about it in the OVERVIEW/MESSAGE/<MESSAGE_ID> page. When you search for information in this table, you need to use the correct search syntax as explained in Searching for Messages.
Purpose	This allows you to identify the individual message IDs that were not successfully processed and click on them to find more details in order to take corrective action.
Recommended action	Sort the messages by the status and check whether message failure correlates with specific time intervals. If such a pattern is identified, check whether any unusual activity (e.g., system downtime, unavailability of the backend service) has occurred during that time. Sort the messages by the status and check whether message failure correlates with a specific host. If message failures mainly occur for a specific port(s) investigate further. Click on the message IDs that have failed for further information about them in the OVERVIEW/MESSAGE/<MESSAGE_ID> page.