Pre-requisites for Real User Monitoring using eG Enterprise

Before attempting to monitor real user transactions to your web site/web application, ensure that the following are in place:

At least one HTTP/HTTPS web site/web application receiving user traffic and fully/partially supporting the following web technologies/frameworks:

Fully supported web technologies/frameworks	Partially supported web technologies/frameworks1
Java, .NET, PHP, Node.js, Python, Ruby on Rails, HTML, XHTML, SHTML, Iframe, Ajax (XHR, fetch), Object, Frameset, Embed, jQuery, AngularJS, Angular, React (a.k.a React.js or ReactJS), Vue.js	Backbone.js, Ember.js, Knockout.js, Dojo, CanJS, Polymer, Mithril.js, Ampersand.js, Flight, Marionette.js, TroopJS, RequireJS, Aurelia, Spine JS, Matreshka.js, Redux, RxJS

1 - If the target web application supports these technologies, then eG RUM will be able to report the page load time, resource load time, and Ajax metrics for that target. However, note that virtual page metrics may / may not be reported for the same.

A JavaScript-enabled browser that ideally supports both the Navigation Timing API and the Resource Timing API. The Navigation Timing API provides data that can be used to measure the performance of a web site. The Resource Timing API provides a way to retrieve and analyze detailed network timing data regarding the loading of an application's resource(s) (eg., image, script, XMLHttpRequest, <SVG> etc.).

The table below lists the popular browsers, the browser versions that eG RUM supports fully and partially, and the versions that are not supported.

Browser	Versions Fully Supported1	Versions Partially Supported2	Versions Not Supported3
Internet Explorer*	10, 11	6, 7, 8, 9	5 and below
Microsoft Edge	12, 13, 14, 15, 16		1
Chrome	24 and above	6 to 23	5 and below
Mozilla Firefox	35 and above	7 to 34	6 and below
Safari	11 and above	8 to 10	7 and below
Opera	15 and above		14 and below
IOS Safari	8, 8.1, 9.2 and above		7 and below, and between 8.2 and 9.2
Android browser	4.4 and above	4 and 4.3	3 and below
Blackberry Browser		10
Opera Mobile	37
Chrome for Android	59
Firefox for Android	54
IE Mobile	10 and above
UC browser for Android	11.4
Samsung Internet	4 and above
QQ Browser	1.2
Baidu Browser	7.12

1 - These versions of browsers support both the Navigation Timing API and Resource Timing API

2 - These versions of browsers support only the Navigation Timing API and not the Resource Timing API. Because of this, eG RUM will not be able to report on the load time of individual resources.

3 - These versions do not support both the Navigation and Resource Timing APIs

* - Note the following with respect to Internet Explorer:

Built-in security policies of Windows Server Editions (eg., Windows 2012, etc.) will not allow the Internet Explorer browser deployed on them to send beacons to the RUM collector. This means that the eG Real User Monitor will not be able to measure the experience of those users who are using IE on any Windows Server Edition to browse the target web site/web application.
- The Navigation Timing API typically exposes several properties that offer information about the time at which different page load events happen (see Figure 1) - eg., the requestStart event, the responseStart event, etc.
  Figure 1 : Page load events captured by the Navigation Timing API
  eG RUM uses the time stamps provided by the Navigation Timing API to compute and report the duration of page load events, so you can accurately identify where page loading is bottlenecked.
  The Navigation Timing API on Internet Explorer (IE) v11 in particular reports an incorrect time stamp for the requestStart event of the page loading process (see Figure 1). As a result, for page view requests initiated from IE 11 browsers alone, eG RUM will report incorrect values for the Average network time and Average server time measures.
  This issue was noticed in IE 11 in April 2019. It is recommended that you track hot fixes/patches released by Microsoft post April 2019, study the release notes of such fixes/patches, and determine if this bug has been fixed in any. If so, then you are advised to apply that fix/patch on IE 11 to resolve the issue.
  Until then, we recommend that you use the following workaround to accurately measure the Average server time of a page view request.
  - Deploy eG BTM (Java/.NET, as the case may be) on the backend server hosting the target web site/web application.
  - Use eG BTM to trace the path of transactions to the target web site/web application and enable the (Java or .NET) Business Transactions test to capture metrics on transaction performance.
  - Next, use the detailed diagnostics reported by eG RUM to identify the page view requests coming from the IE 11 browser. Make a note of the values in the Request time, URL and Query Params columns of detailed diagnosis.
  - Then, search the detailed diagnostics of the (Java or .NET) Business Transactions test for transactions with the same URL, Request time, and Query Params as reported by eG RUM.
  - The response time that eG BTM reports for each of these transactions is the Average server time of those transactions.
  Note that this workaround applies only for those transaction URLs that are captured and reported as part of detailed diagnostics.

User traffic should come from the following devices only:
- PC
- Server
- Laptop
- Mobile
- Tablet
At least one eG RUM collector

At least one remote agent operating on any remote Windows/Linux/Solaris host in the environment;
Minimum hardware requirements of the eG remote agent:
- Minimum 4GHz of CPU
- Minimum 4GB RAM
- Minimum 1 GB free disk space
  
  Note:
  
  The hardware requirements described above are the minimum requirements for performing real user monitoring using eG. The actual resource requirements will vary depending upon the traffic to your web site/web application. To understand the actual resource requirements for RUM, use the eG Manager and Database Sizing Calculator .
An eG database that is sized right to handle the load generated by the eG RUM; a minimum of 2GB of disk space should be free on the eG database.

Note:

The disk space requirements provided above are the minimum requirements for performing real user monitoring using eG. The actual resource requirements will vary depending upon the traffic to your web site/web application. To understand the actual database space requirement for your environment, use the eG Manager and Database Sizing Calculator.
By default, the eG RUM script (egrum.js) is bundled with the eG RUM Collector only. Because the RUM script is co-located with the collector, an unexpected collector outage can impact the performance and load time of web pages injected with the RUM script. To ensure fast loading and high availability of such web pages, and to assure users of a superior experience, we strongly recommend that you place the egrum.js file in a highly available location. The steps to achieve this are as follows:
- First, pick a highly available location in your environment. This can be any of the following:

Next, you need to download the egrum.js script file. For that, first login to the eG admin interface.

If a Real User Monitor component is already managed in the eG Enterprise system, then, follow the Infrastructure -> Components -> Add/Modify menu sequence, pick Real User Monitor as the Component type, and click the Modify button corresponding to the RUM component for which the egrum.js is to be relocated. In the figure that appears next (see Figure 2), click the Download button against egrum.js to download it. Also, copy the RUM header script displayed in the Include this line in your . . . text area to Notepad or any text editor.

Figure 2 : Downloading the egrum.js and copying the RUM Header script to a text editor

If a Real User Monitor component is yet to be managed, then, follow the Infrastructure -> Components -> Add/Modify menu sequence, pick Real User Monitor as the Component type, and click the Add New Component button to add the component. In the figure that appears next, provide a nick name for the RUM component, assign a collector and remote agent to it, and click Add to add the component. Figure 2 will then appear. Here, click the Download button against egrum.js to download it. Also, copy the RUM header script displayed in the Include this line in your . . . text area to Notepad or any text editor. Finally, click the Add button to add the component.
Once the egrum.js file is downloaded successfully, copy it to any folder in a highly available location.
Next, switch to the editor to which the RUM header script has been copied. Change the location of the egrum.js in the header to reflect its new location. For instance, in the sample header script below, you need to change the text highlighted in Red to indicate the new location.



<script charset='UTF-8' type='text/javascript'> window['egrum-start_time'] = new Date().getTime();

window['Site_Name'] = 'fbe3ef39-c0aa-4bed-a7f4-517fb6923d2e-1510039682956';

window['beacon-url'] = 'http://192.168.9.12:7077';</script>

<script src='http://192.168.9.12:7077/rumcollector/egrum.js' async> </script>
Then, save the script.
Finally, inject the script into the web pages of the target web site / web application, using the appropriate instrumentation mechanism.

This way, you can separate the egrum.js from the collector, and thus make sure that the unavailability of the collector does not affect the web page loading time.

The eG Enterprise Real User Monitoring Checklist

Before you set out to perform Real User Monitoring using eG Enterprise, its best to ensure that all pre-requisites are fulfilled. For that, it is recommended that you use the checklist below:

S. No.	What is to be checked?
1.	Architecture / work flow of the website/application to be monitored
2.	The underlying technology of the website/application (Java, .Net, PHP, etc...).
3.	Is the target website/application served using HTTP or HTTPS or both?
4.	Are the users of the website/application from the internet or intranet or both?
5.	If intranet, then what specific versions of browsers are the corporate users using?
6.	The name and version of the application server that is used to serve the website content
7.	Is the website/application served via a web server (such as Apache, IIS, Nginx, etc.)? if so, what is the web server and what version of the server is being used?
8.	Are there any load balancers (such as NetScaler, F5, etc.) used to serve the website/application? If yes, which load balancer is used and what is its version?
9.	Are any third-party frontend-related frameworks used? If so, what framework is used and what is its version? (e.g., AngularJS, Reactjs, Ember.js, etc)