Real User Monitoring

Real User Monitoring is one application in Focused Run which is a part of the Focused Solution family. It provides permanent measurement of all real user requests within a system landscape covering performance as well as utilization aspects.

Scope

  • Monitoring of real-user requests cross system and cross technology.
  • Correlation and assembling of different server side measured data to end-to-end user scenarios.
  • Data are provided by SAPUI5 or SAPGUI, SAP Gateway, SAP ABAP and SAP J2EE Systems. Scope will be step-by-step enhanced for non-SAP Systems based on customer requirements.
  • SAP Real User Monitoring covers performance as well as utilization measurement (web analytics).

Target Group

  • Application management service providers and customers who like to get transparency regarding real end user behavior based on high volumes of usage data.

Release Notes

Focused Run 1.00

  • Monitoring of performance and usage for ABAP Systems of request types RFC, Web Service, http(s), DIAG(SAPGUI) and SAPUI5/Fiori
  • Monitoring of performance and usage for SAP J2EE Systems of request types RFC, Web Service, http(s)
  • Monitoring UI
    • Status Overview
    • Request Overview
    • Customizable Card View
    • End-User View (SAPUI5/Fiori)

Feature Pack 01

  • Monitoring of performance and usage (without user names) for HANA XS engine of requests of type http(s) and SAPUI5/Fiori
  • Aggregation of the single request to hourly values with separate life time.
  • Monitoring UI
    • Tree map with dedicated views for performance, work load and usage
    • 24h profiles
    • Topology view, from which systems are the selected systems called and which systems are called by the selected systems

Feature Pack 02

  • Monitoring of performance and usage for SAP Cloud Platform of requests of type http(s) and SAPUI5/Fiori
  • SLA Alerts based on own created and public cards
  • Self Monitoring Alerts for RUM data collectors
  • Allow for actions a mapping of technical names to any free definable description like for requests
  • Allow in administration UI download and upload of
    • System settings (threshold configuration)
    • Pages and own defined cards from Cardview 
  • Monitoring UI
    • Front-end performance view ( chart for SAPUI5 requests with client response time, network time and server time)
    • Include ABAP back end performance KPIs from System Analytics

Feature Pack 03

  • History view of end-user browser versions
  • Configuration is now included in Monitoring UI
  • ABAP Exceptions of end-users can be displayed in separate view

Focused Run 2.00

  • Integration of System Analysis in RUM via jump-in functionality to relevant system and time stamp

 

Prerequisites

General

  • Real User Monitoring is available as of Focused Run 1.00
  • System Monitoring Setup of the Technical Systems involved is required for Real User Monitoring

Technical Requirements

  • FIORI/SAPUI5 Monitoring
    • Managed System must be at least on SAP_BASIS 7.40 SP12
    • Managed System SAPUI5 version must be at least on 1.38.8
    • Managed System ST-PI version must be at least on 7.40 SP04

Relevant SAP Notes

SAPUI5 version in Focused Run is developed and tested based on the underlying software components. It might happen when a higher version of the underlying component is applied (e.g. SAP_BASIS or SAP_UI) that some additional patches need to be applied.

  • Focused Run SP00
    • SAP Note 2412927:  Corrections for Real User Monitoring FRUN SP00
    • When SAP_UI 7.50 SP06 is applied the SAPUI5 version needs to be patched with SAP Note 2419950 (SAPUI5 upgrade to version 1.38.17).
  • Focused Run SP01

Preparation

  1. Execute Managed System Setup for Systems in Scope
  2. Ensure that latest and recommended ST-PI version is installed in managed systems Prerequisites (section above)
  3. Ensure that latest versions of notes are applied in FRUN Prerequisites (section above)
  4. Execute the report /RUM/SETUP to enable partioning of the tables
  5. Create for each customer ID one system user FRN_RUM<CID> with role SAP_FRN_RUM as mentioned in the Security Guide.

Setup of Real User Monitoring

Real User Monitoring Administration

Open the Real User Monitoring Administration

Global Settings

On this tab you can check if the housekeeping job scheduled and when it has been executed the last time.

  • Enter the lifetime of the data: Number of days for single requests and number of days for aggregated data (available since FP01).
  • Enter the time when the housekeeping job should run.

System Settings

On this tab you can:

  • Add new technical systems
  • Deleted existing systems/configuration
  • Change thresholds
  • Navigate in case of trouble shooting to the relevant agents for the system.
Adding a technical system

Click on Button Add System to open the LMDB search. 
Supported System Types are: ABAP, Java, HANADB( since FP01).

Search for a System, select it in the table below and click on OK.
Click on 'Apply and activate' to save your changes.

For a new added systems the credentials for the PUSH user (from SDA -> FRUN) needs to be provided. See also next step/tab.

Deleting a Technical System 

Select the system you want to delete and click the button Delete System.

Click on 'Apply and activate' to save your changes.

The confiiguration on the agent is deleted an data is no longer collected. Deleting a system does not delete the already collected data.

Changing Thresholds

If there are requests or applications where you expect a higher response time then the thresholds can be adapted.

The evalution if a request execution is rated as green, yellow or red and if fast executions are aggregated are already done on the agent.

Each request type (like http, RFC,..) has a three default thresholds:

  1. Green→Yellow (ms)
    Executions below this threshold are rated as green.
  2. Yellow→Red (ms)
    Executions below this threshold are rated as yellow.Executions above this threshold are rated as red.
  3. Aggregation (ms)
    Executions below this threshold are aggregated already in the agent. This ensures that many fast requests do not blow the amount of data. 
    This threshold must be lower than the Green→Yellow threshold.

The flag Aggregate Errors decide if http calls wich run into an error (e.g. status code 500) but are very fast are aggregated (if flag is set) or not.

Custom Thresholds

It is possible to create custom and system dependent thresholds by selecting the request type and clicking on button Add.

In the example above there are two additional thresholds for SAPGUI dialog requests. One for transaction SE80 and one for SE09. Both have different thresholds.

There are also two custom specific thresholds for https definded with wildcards. The first entry is for all https requests starting with /sap/bc/webdynpro/sap/Z which are aggregated if they are faster than 700ms and rated as red if they are slower than 4s. The second entry is for all https requests starting with /sap/bc/webdynpro/sap/Z and having TEST in the name which should be agregatted if they are faster than 600ms and rated as red if they are slower than 2s. Becasue this pattern is already matched by the first entry the second threshold will never taken into account.

For this reason you can change the order in the table by selecting entries and moving them up (button Move Up) or down (button  Move Down).

Note: When using wildcards for thresholds keep in mind that the first matching entry from top is taken into acoount.

By clicking on button Apply and Activate the changes are persisted and the configuration is send to the agent. Starting with collection the new thresholds are used to aggregate and rate the executions. 

Note: Historical values are not touched: changing thresholds do not change the rating of already collected data.

 

Push-User Credentials

The Agents need to know the the URL where they should push the data to and the credentials to login.

FP01
With FP01 this can be set in this step. It is possible to set or change the user or the password for several agents in one go. The password in the user master record (SU01) is not updated but only the value of the password is pushed to the agent.

 

Since FP02

With FP02 Real User Monitoring is integrated in Simple System Integration (SSI) setup. The credentials are sent by SSI to the agents. New password can be set with report RSSI_CHANGE_NETWORK_PASSWORD as mentioned in the master guide.

Request Description

It is possible to create for technical request name a more meaningful user friendly description which is then displayed in the monitoring. However configuration and filtering must be done for the technical names.

Expert Configuration

There are some settings possible which might be changed only after recommendation by SAP and which is not possible in the UI.

All settings are globally and are only effective after sending the configuration to the agents.

Note: Do not delete or change any entries in the table that are not mentioned here!

Changing collection frequency

The default frequency how often the collectory are running on the agents is in FP00 5 minutes and with FP01 2 minutes.

If you want to change the colelction frequency enter/change in SE16 in table /RUM/GLOBALCFG the entry

TYPE = COLLECTOR
PARAM = COLLECTION
VALUE = 120

The unit of the value is seconds.

Changing user aggregation

By default the user name is also contained in the aggregated records. This is helpful if you want to check or search in the monitoring UI which actions one dedicated user has been executed. If you want to reduce the table size and you are not interested in the user names of the aggregated records you can switch it of. You can then add in SE16 the following entry in table  /RUM/GLOBALCFG:

TYPE = COLLECTOR
PARAM = USER
VALUE =

Initial value removes the user from aggregated values, X keeps the user in the aggregated values.

Changing look back time

By default the agent tries to cover the last 24 hours of data from managed system. In case you want to change this value add in SE16 the following entry in table  /RUM/GLOBALCFG. The unit of the value is hours.

TYPE = COLLECTOR
PARAM = LOOKBACK
VALUE = 48

Changing Default Thresholds

Each request type has default thresholds (in ms):

FP00

System Type Request Typ Green->Yellow Yellow->Red Aggregation
ABAP   001 (Dialog) 1500 3000 1000
ABAP   101 (http) 1500 3000 1000
ABAP   102 (https) 1500 3000 1000
ABAP   251 (WS) 1500 3000 1000
ABAP   254 (RFC) 1000 3000 1000
ABAP   256 (SAPUI5) 2000 4000 1500
JAVA   101 (http) 2000 6000 1000
JAVA   102 (https) 2000 6000 1000

FP01

System Type Request Typ Green->Yellow Yellow->Red Aggregation
ABAP   001 (Dialog) 1500 3000 1000
ABAP   101 (http) 1500 3000 600
ABAP   102 (https) 1500 3000 600
ABAP   251 (WS) 1500 3000 600
ABAP   254 (RFC) 1000 3000 300
ABAP   256 (SAPUI5) 2000 4000 1000
JAVA   101 (http) 2000 6000 1000
JAVA   102 (https) 2000 6000 1000
HANADB   101 (http) 2000 6000 600
HANADB   256 (SAPUI5) 2000 6000

1000

FP02

System Type Request Typ Green->Yellow Yellow->Red Aggregation
  ABAP   001 (Dialog) 1500 3000 1000
  ABAP   101 (http) 1500 3000 600
  ABAP   102 (https) 1500 3000 600
  ABAP   251 (WS) 1500 3000 600
  ABAP   254 (RFC) 1000 3000 300
  ABAP   256 (SAPUI5) 2000 4000 1000
  JAVA   101 (http) 2000 6000 1000
  JAVA   102 (https) 2000 6000 1000
  JAVA   251 (WS) 1500 3000 600
  HANADB   101 (http) 2000 6000 600
  HANADB   256 (SAPUI5) 2000 6000

1000

  EXT_SRV   101 (http) 2000 6000 300
  EXT_SRV   102 (https) 2000 6000 300
  EXT_SRV   256 (SAPUI5) 2000 6000

1000

Default Thresholds: 

Default thresholds can be changed by entering the values with SE16 into table /RUM/FILTERCFG.
The values are in ms and should not be set too low. 
The value for Aggregation defines if a request is put into an aggregation bucket or kept as single request. This value must be lower than the value for Green→Yellow.

The Default values are only taken into account when a new system is added in RUM configuration. Existing configured system are not touched.

Alerting

Since FRUN 1.0 FP02 it is possible to create alerts and automatic notifications for RUM. There are two types of alerts available which can be displayed in the Alert Inbox for usecase Real User Monitoring:

Selfmonitoring Alerts

To be notified when a collector is stopped or not working anymore (e.g. user is locked, password changed, connection issue,..) you can schedule the report /RUM/SELFMON_ALERTS_TRIGGER as a background job.

It should be scheduled for user FRN_BTC_RUM and it is sufficient to run every 60 minutes.

In the variant you can specify if the report should be executed only for one (customer) network and a notification variant if you want to get notified by e-mail for example when the collector do not send anymore data.

Service Level Agreement (SLA) Alerts

You can specify for each self defined group that is also used in the cardview of the monitoring application if you want to get notified when an amount of executions are below a defined threshold. The following fields define the behavior:

  • Response TIme Threshold [ms] : Enter the value in ms. Default is 3000
  • Percentage: Define how many executions in % should be below the threshold. Default is 94
  • Calculation Frequency [min]: Defines how often the alert should be calculated. Default is 10 minutes
  • Minimum Number of Executions: Define how many executions must be available in the interval. Default is 10
  • Notification Variant: In case someone should be notified you can choose a variant.
  • Outbound Connection Variant: In case something should be triggered automatically you can choose the variant.

The calculation is triggered by the job /RUM/ALERT_CALCULATION which is scheduled when executing the report /RUM/SETUP.

Upgrade Steps

  1. Ensure that latest versions of notes are applied in FRUN Prerequisites (section above)
  2. Execute the report /RUM/SETUP which migrates own created card views to groups.

Focused Run SP01

With SP01 an additional authorization check for the RUM ICF service has been added. The role SAP_FRN_RUM has been enhanced with SP01 but if you have copied the role with SP00 or created your own role the customer role needs to be enhanced too. When using the SAP role you need to re-generate the role to create the new profiles.

To avoid that data is missing becasue the SDA could not send data you can enhance your customer role already in advance.

Add to your customer role for the technical user FRN_RUM_<CID> the object  S_ICF with:

  • ICF_FIELD = SERVICE
  • ICF_VALUE = RUM_PUSH

Focused Run SP02

With SP02 Real User Monitoring is integrated into Simple System Integration (SSI) which is handling the users for the push back communication. Execute in FRUN launchpad the application Global Settings & Network Configuration and mark the use case Advanced User Monitoring.

FAQ's

No, it has no impact on the end user performance.

No, RUM does not need any additional software to be installed on the end users device.

Prerequisites for managing and Managed Systems are listed in the Prerequisites Section.

Supported system types are:

  • ABAP and SAP J2EE in FP00
  • With FP01 additionally HANA DB (HANA XS engine of requests of type http(s) and SAPUI5/Fiori).
  • With FP02 additionally SAP Cloud Platform requests of type http(s) and SAPUI5/Fiori.

Several RFC server requests can be processed in one dialog step and are therefore written into one statistical record. If this is the case the CPU and DB time cannot be assigned to a single RFC call.

Real User Monitoring is able to monitor and correlate synchrous requests triggered by end users. As soon as there is an asynchronous step the request flow cannot be correlated completely.

Some components which do not forward the SAP Passport (like ABAP Proxy, XI runtime) also break the request flow and outgoing requests might not be mapped to the incoming request.

Requests of type SAPUI5/Frontend have some measured values that are different from other request types.

These are:

  • Round Trip Time (start time of irst server record until end time of the last server record per round trip)
  • Network Time
  • Number of Round Trips (numer of server requests initiated by this user interaction)

Response time is the elapsed end-user time measured in the browser.

Net Time is the time spend by the application in the browser. It is approximately the difference between the Response Time and the Round Trip Time influenced by the accuracy of the measurement. See also in the picture below.