Real User Monitoring

The Real User Monitoring application of SAP Cloud ALM can be used to monitor performance as experienced by end users as well as the utilization of business functionality. The basic concept is to get all user interactions and the relevant server requests, which are then correlated in the Real User Monitoring application. Therefore, Real User Monitoring provides transparency about which applications are most used by the end users and what are the relevant end user response times.

Please watch the video to understand how data is gathered in Real User Monitoring:

Request executions are rated not based on fixed thresholds but on historical values. Real User Monitoring shall help IT users and Business users to understand how often applications are executed and what are the response times for the end users.

By utilizing the SAP Passport technology it is possible to correlate performance data measured at front-end, service and/or system side without having the need of additional data injection or agent installation on end user devices. The app is assembling the collected information in a way that the request flow with all including components gets transparent. So, performance problems at front-end and server side can be identified and the resource consumption of each sub-request can be evaluated.

Within the application you can:

• Identify single requests that show poor performance for a specific execution.
• Review the execution frequency of a specific application or function.
• Access the request flow and view the analysis that includes all components involved in a request flow execution.
• Analyze the resource consumption of each sub-request (for example, review the time that was spent by a single sub-request for a component).
• Customize your request types with personalization features: You can filter by timeframe, request name, and request type.

The following graphic demonstrates how data is transferred from different managed components and processed in SAP Cloud ALM:

Note that there is no additional data injection via plug-in or any other type of agent on the front end device necessary. The performance experienced by the end user is measured directly on the client each time that the end user is using the browser or SAP GUI. The measured values are transferred via the SAP Passport in addition to transaction ID, root context ID and further information, which are necessary to determine the origin of the data. On the service and system side, the statistical records are collected automatically and transferred to SAP Cloud ALM. The Real User Monitoring application is then assembling and correlating the data to end-to-end real user request execution scenarios.

In the configuration of Real User Monitoring, you can activate and deactivate the measurements of managed components. For deactivated components, no requests are measured in Real User Monitoring. If supported by the managed component, the collection of metrics on the managed SAP solution itself is deactivated. In addition, you can also activate events in the configuration.

The prerequisites for the configuration are as follows:

• The role Real User Analyst Administrator is assigned to your user.
• The relevant managed component is connected to SAP Cloud ALM.
• The relevant managed component is selected in the Scope selection.

The configuration consists of two steps: the activation/deactivation of monitoring for a managed component and the configuration of events for this respective managed component.

The following screenshot displays the Configuration Screen to activate and deactivateManaged Components:

For the configuration, proceed as follows: 

1. Choose Configuration (1) to open the configuration panel.
2. Expand the section Managed Components (2) to see a list of all managed SAP solutions available for Real User Monitoring.
3. The managed components are displayed with information about their monitoring statuses. Press the Slider Button (3) to activate or deactivate the monitoring of the component.

The following screenshots demonstrate how to configure Events:

In each managed component there are events at your disposal, which you can monitor in the Real User Monitoring app. By default, these events are inactive. To activate events, proceed as follows:

1. Select Configuration (1), and select the button Edit (2) for the managed components.

2. For the different managed components, the event creation statuses are displayed. To configure these events, select the managed component name, or select Details (3) in the corresponding row.

3. The configuration settings for the selected managed component is displayed (4). Select the tab for the event sub type you want to configure.

   Currently, events can be created when the error rate of http(s) requests are exceeding a configured threshold. Configure these settings in the tab Http Errors (5). The configuration consists of two parts:

   • In the first section (6), you can specify the conditions under which an event should be created. For more details, see the in-app help.

   • In the second section Event Actions (7), you can specify which actions should be performed in case of an event.

     Note

     In the section Event Actions, you have the following options: Create Alert, Send Email To, Create Ticket, and Send Chat Message.

4. Save your changes.

The overview of the performance metric for services in your scope and your favorites in the selected time range is displayed as the  Apdex (Application Performance Index). This is an open standard developed for measuring the performance of applications.

The following screenshots display the Real User Monitoring Overview page:

The Apdex score is a weighted average of executions with weights 1 (satisfied, indicated by green executions), 0.5 (tolerating, indicated by yellow executions) and 0 (frustrated, indicated by red executions).

This screenshot displays the performance rating of an individual request:

The request rating for the Status Summary (1) is done in the way that for every request action, the response time is compared with the median of former response times of that category. 

The color of the requests depends on the response time, which is displayed and distinguished by categories, Critical (red), Fair (yellow) or Good (green).

Real User Monitoring includes a number of predefined pages, which can be selected via the left hand navigation. Furthermore, it is possible to create own views via the plus icon.

The screenshots below illustrate a typical usage scenario:

A typical usage scenario in Real User Monitoring requires the following steps:

1. Overview: Identification of services and/or request types with poor performance.
2. Requests view: Identification of single applications with poor performance or high usage.
3. Request Details: Identification of time frame where single requests are executed with poor performance.
4. Request Flow: Analysis of the single request flow including all components involved in the execution.

These steps are now described in more detail.

The screenshot displayed is of the Overview page:

The Overview page (1) shows, the development of the Apdex (2) over time of the services, and systems in scope. These entities are displayed in order of decreasing criticality.

The performance status of every managed component in scope is displayed in one tile. These tiles show the development of the Apdex over time for the three most critical request types (3) of the corresponding service or system; their name and type are displayed in the tile header. Within a request type, the size of the bar corresponds to the number of executions; the color corresponds to the Apdex rating. In the tooltip (4), the starting time, the Apdex value, and the number of executions for the different bars are displayed. On the left frame of the tile, the color of the average rating based on the displayed request types is shown.

This screenshot displays the Request page:

On the Requests page (1), you can determine, which request types in which managed components have an exceptionally long response time. In doing so, you can determine down to the level of the execution details, where the most of the time is spent. To switch to the next drill-down level, select the information in the first column. In the Selected Action level (2), you can see, which request names or actions have contributed to performance issues and should therefore be examined in more detail.

In the Execution time level (3), you can see the response time for individual executions with the related time stamp. The response time is compared to the threshold values determined by the historical response time distribution. You can also see the Net Time and the Net Time Percentage. A low value means that most of the time for the action is not spent in the selected service or system but somewhere else. In this case, drill further down to investigate the real issue.

In the deepest level of the request page (Request Flow (4)), one single execution is displayed, including correlated requests in other components. The selected execution has a blue border, other boxes are requests triggered by this action in other/same services or systems. The percentage values (5) in the upper right corners of each card show how much of the overall response time the requests took in the corresponding component.

These screenshots display the filter options on the Analysis page:

The Analysis page (1) of the Real User Monitoring app offers different drilldown and display functions for analysis. On this page, you can display different request metrics broken down into different dimensions, offering a large number of analysis options. You define the crucial display settings for this page in the popover Filter (2).

This screenshot shows the Front End page:

The Front End page (1) of the Real User Monitoring app displays usage and performance metrics from front-end requests. In the OS & Browsers (2) section, the types of the operating systems, browsers, and devices (used by the end users) with their number of users are displayed. You can use this information, for example, to inform users to upgrade their operating systems, browsers or devices in case of non-compliance or security risks.

The next screenshot shows the Back End page:

The Back End page (1) of the Real User Monitoring app displays usage and performance metrics from back-end requests. In this page, you can display the most important back-end usage and performance metrics for the following back-end request types (2):

• HTTP
• HTTPS
• RFC
• RFCS
• Dialog
• WS (Web Service)

For all these request types the response times are displayed; also, the number of executions of the displayed request types is shown.

This screenshot shows the Service / System page:

The Services / Systems page (1) offers an overview of your different request types, grouped by the managed components in scope. This helps you to identify entities that show poor performance. It displays the different ratings per component and request type. You can also identify how many requests of a particular request type are executed, and which component handles the highest number of requests.

The color of the requests depends on the response time. The status for every request action is determined by comparing the response time with the median of all historic response times of the corresponding action:

• If the response time is at least 2 times the standard deviation longer than this median, the status is Critical (color red).
• If the response time is at least the standard deviation longer than this median, the status is Warning (color yellow).

The next screenshot displays the Clients page:

On the Clients page (1), the operating system, the browser, and the device type used by the different users are displayed. You can use this information, for example, to inform users to upgrade their operating systems, browsers, or devices in case of non-compliance or security risks.

The next screenshot shows the Execution Flow page:

In the Execution Flow page (1), detailed information about the actions of a user and the corresponding system response, is displayed in chronological order. Use this information to analyze usage and identify possible problems in the system.

By default, the initial display is empty. Enter a valid User name or Root Context ID in the Filter (2).

Once the results are displayed, all user activities and corresponding backend requests with response times are displayed.

This screenshot shows the Expensive Requests page:

The Expensive Requests page (1) displays request names and spotlights the most critical ones. On this page, of the numerous requests in your services and systems in scope, the request names using the most resources and causing the most critical execution results, are displayed. By default, the Time Frame is This Week, and the view is limited to the 200 most expensive request names. You can change this number by using the Filter function (2).

You can select one of the following three views via the Display Mode (3) function:

• Performance (default): The request names with the maximum number of red executions are displayed.
• Workload: The request names with the maximum total response time are displayed. The total response time of a request name is the product of the number of executions and the average response time. This reflects the resources used by the corresponding requests.
• Usage: The request names with the maximum number of unique calls are displayed. The number of unique calls represent the number of users executing the corresponding requests. This indicates how comprehensively the request name is used.

The results are displayed in a tree map in which the different request names are displayed as squares, grouped by the different request types. The size of the squares depends on the selected display mode. The color of the squares depends on the percentage of red executions compared to all executions of the request name.

This screenshot displays the HTTP Errors Page page:

The HTTP Errors page (1) shows the number of errors while executing request types HTTP(S) for the systems and services in scope. For every system or service, the following data for the selected time frame is displayed in detail:

• Number of Total Executions for requests of request types HTTP(S).
• Success Rate of calls, as a percentage.
• Percentage of calls with HTTP status codes 4xx (Client Errors).
• Percentage of calls with HTTP status codes 5xx (Server Errors).

In the History (2) section, the development over time of HTTP(S) calls and errors is displayed. To give you a better overview, an adjusted period before the Selected Time Frame is also included in the charts. The selected time frame itself is highlighted in purple.

The last screenshot displays the Alerting page:

On the Alerting page (1) of the Real User Monitoring app, the alerts you have activated in the Configuration (2) are displayed in a list. You activate and configure the alerting in the Configuration of the corresponding managed component.

Scan the list via Alert Name and Message, Status, Processor, and Object Details. You can perform the following actions:

• Sort the open alerts
• Assign or remove alert processors
• Confirm open alerts
• View the action logs of an alert
• Export the alert list to a spreadsheet

For analyzing an alert, you can drilldown the alert details (3) to get information on the related message. By choosing the relevant option from Actions button (4), you can perform actions such as adding comments, starting a workflow, sending notification, and so on per alert.