Managing the Web Site/Web Application to be Monitored

Now that the required collectors have been installed and configured, let us now proceed to manage the web site/web application to be monitored and assign one of the configured collectors to it.

Note:

A collector that is not SSL-enabled cannot manage an SSL-enabled (i.e., an HTTPS) web site/web application. However, a collector that is SSL-enabled, can manage both HTTP and HTTPS web sites/web applications.

For this, follow the steps below:

1. In the eG administrative interface, select the Add / Modify option from the Components menu in the Infrastructure tile.

2. Figure 1 will then appear.

   

   Figure 1 : Choosing to add a Real User Monitor

3. Select Real User Monitor as the Component type from Figure 1 and click the Add New Component button to add a new component of that type.

4. When Figure 2 appears, provide a unique name for the web site/web application that you want to monitor in the Nick name text box.

   

   Figure 2 : Adding a Real User Monitor

5. Then, select the RUM collector you want to assign to the specified web site/web application. By default, the Nick Name (see Figure 2) of each of the RUM collectors that you have configured in your environment will populate the RUM collector drop-down in Figure 2. From this drop-down list, select the nick name of the RUM collector that you want to assign to the web site/web application being managed.
6. Next, select the Remote agent that should monitor the web site/web application being managed by polling the selected collector.
7. Besides pointing you to slow and stalled pages, eG RUM also captures and reports JavaScript errors that may occur in a target web site/application. By default, eG RUM captures even those JavaScript errors that occur after the base page is loaded. For instance, say that an AJAX request was initiated during a base page load. Assume that this AJAX request executed a JavaScript that threw errors, causing an error response to be sent to the base page only after the base page was completely loaded. By default, eG RUM will report such errors too. This is why, the Capture JavaScript Error slider is pushed to the left by default. However, to reduce monitoring overheads and conserve database space, you many want eG RUM to capture JavaScript errors that occur only during base page load and not after it. If so, push the Capture JavaScript Error slider to the right.
8. The Capture Resource Details slider is pushed to the left by default. This means that, by default, when monitoring the target web site/application, eG RUM automatically discovers the resources (CSS, images, JavaScripts etc.) that a browser loads in response to a page view request, captures the total time the browser took to load each resource, and also provides a detailed break-up of the load time per resource. These detailed resource-level insights enable administrators to identify the exact resource that delayed page loading, and the accurate reason why that resource loaded slowly. Though these resource details can be effective tools for troubleshooting web site slowness, they can also put a strain on the eG database, particularly where a browser needs to load numerous resources per web page! If you want to spare your eG database this stress, then you can disable the collection of resource-level metrics. For this, you need to push the Capture Resource Details slider to the right.
9. eG RUM reports user experience metrics for three types of web pages by default - base pages, iFrames, and Ajax pages. To reduce the strain on the eG database, you may choose to exclude AJAX web pages from the monitoring scope of eG RUM. To achieve this, push the Capure XmlHttpRequest (XHR) slider to the right. By default, this slider is pushed to the left.

10. By default, for an AJAX request, eG RUM reports only four metrics, namely - Total page load time, Average server time, Average content download time, and Ajax callback time (which will be available only in the RUM Transaction Details page for an AJAX request). In other words, the detailed split-up of response time is not reported by default for AJAX requests. This is because, the Enable AJAX Correlation flag is set to No by default.

    To enable eG RUM to collect detailed response time metrics of AJAX requests, you first need to set the Enable AJAX Correlation flag to Yes. If this is done, then eG RUM will automatically correlate the default metrics it reports for AJAX requests with the insights that the ResourceTiming API offers for such requests.  This auto-correlation enables eG RUM to provide the break-up of the response time of an AJAX request in the RUM Transaction Details page of that request. Moreover, to allow you more granular insights into the response time of that request, a Related Resource Details page will appear next to the RUM Transaction Details page. With the help of both the pages, administrators will be able to easily and accurately diagnose the source of slowness in AJAX requests.

    However, note that a few caveats apply here. Even if the Enable AJAX Correlation flag is turned on, eG RUM will be able to report the detailed load time split-up of an AJAX request, only if:

    • The URL of that AJAX request, as determined by eG RUM, exactly matches with the URL captured by the ResourceTiming API;
    • The time of the AJAX request in eG RUM is at least close to the request time captured by the ResourceTiming API
    • The AJAX request is well within the maximum number of resource requests a browser can handle

    If even one of the aforesaid conditions is not fulfilled, then, though the Enable AJAX Correlation flag is set to Yes, the RUM Transaction Details page will report only four metrics, namely - Total page load time, Average server time, Average content download time, and Ajax callback time. The Related Resource Details page will also not provide any additional diagnostics.

    Sometimes, more than one AJAX request processed at around the same time may have the same URL. At such times, eG RUM may find more than one match for an AJAX request's URL in the Resource Timing API. In this case again, even if the Enable AJAX Correlation flag is set to Yes, the RUM Transaction Details page will report only the default metrics mentioned above - i.e., Total page load time, Average server time, Average content download time, and Ajax callback time. However, the Related Resource Details page will display all the matching/related URLs. You can drill down from a URL to view the detailed response time break-up for that URL.

11. A Single-Page Application (SPA) is a web technology and design paradigm that reduces browser-level page loads by using JavaScript to fetch resources and build pages. This creates a smoother, faster user experience more like a desktop or mobile application than a traditional web page (without reloading the entire page). The eG Real User Monitor provides monitoring support for SPA frameworks such as Angular JS, React JS, Vue.js, Backbone.js, ember, and Meteor. To automatically instrument a Single Page Application for real user monitoring, push the Capture SPA and Capture fetch() requests sliders to the right. Enabling these options adds the configuration parameters needed in the RUM snippet to enable SPA monitoring. Once the Snippet is added to the website, eG RUM automatically starts capturing page navigations for the SPA applications. This does not require any code change on the application pages.

12. You can configure eG RUM to capture the names of users who initiated a page view request, and report it as part of detailed diagnostics. If a Java/.NET server in the request path is enabled for business transaction monitoring, then the eG Business Transaction Monitor (BTM) can also be instrumented to capture the names of users who initiated application transactions, and send these names to eG RUM. The question now is, which of these user names should eG RUM report in detailed diagnosis - the name that it captured? or the name that eG BTM reported? You can indicate your preference using the Overwrite BTM User slider. If this flag is pushed to the right, then the user name captured by eG RUM will be used. If this slider is pushed to the left, then the user name sent by eG BTM will be used.

13. If you want to exclude requests to certain web pages in the target web site/application from the monitoring purview of eG RUM, then you can specify a comma-separated list of URLs/URL patterns to exclude in the URL Exclude Pattern text box. For instance, you specification can be: */webstore/shoes*,*/webstore/hardware*

    Note:

    Only base page / iFrame URL patterns can be specified in the URL Exclude Pattern text box. AJAX URLs cannot be specified here.

14. Specify a comma-separated list of AJAX URLs/URL patterns in the URL Exclude Pattern for AJAX text box, if you want requests to specific AJAX pages in the target web site/application to be excluded from monitoring. For instance, your specification can be: */webstore/payment*,*/webstore/auction*

    Note:

    If the Capture XmlHttpRequest (XHR) slider is pushed to the left, then this specification will be disregarded. In which case, all AJAX requests will be excluded from monitoring.

15. If you want eG RUM to monitor requests to specific patterns of URLs alone, then provide a comma-separated list of URLs/URL patterns to monitor in the URL Include Pattern text box. If you specify just an asterisk '*' here, then eG RUM will monitor requests to all pages in the target web site/application, except those URLs/URL patterns that have been specifically configured against URL Exclude Pattern.

    Note:

    Only base page/iFrame URLs can be specified against URL Include Pattern.

16. The detailed diagnostics provided by the eG Real User Monitor reveal the exact URLs in the target web site/web application that are slow to respond to user requests. By default however, these detailed metrics do not provide the names of the users who hit the slow URLs. If you want to include the user name in detailed diagnosis, then push the Capture UserName slider to the right (by default, this slider is pushed to the left). Once the flag is turned on, follow the steps detailed in the Enabling the eG Real User Monitor to Capture User Names topic, so you can easily configure eG RUM to capture the user name from a slow-loading web page and report it as part of detailed diagnosis. With the help of such information, help desk can perform troubleshooting more effectively. For instance, help desk can quickly identify the users who are experiencing slowness, well before they actually complain.

17. Then, click the Add button in Figure 2 to add the Real User Monitor component. Doing so will invoke Figure 3. Figure 3 provides you with multiple options to instrument the web pages in the managed web site/web application, so that they can capture user experience metrics.

    

    Figure 3 : Viewing the code snippet to be injected into the monitored web pages