Real User Monitoring (RUM) Configuration

Real user monitoring (RUM) is a passive monitoring technique that records user interaction with a website or client interacting with a server or cloud-based application. It has many uses, including:

  • testing website or application changes for errors or slowdowns in the pre-deployment phase
  • troubleshooting performance problems

As technology shifts to hybrid environments, it becomes more and more important to monitor from within the client itself.

Real user monitoring is typically "passive monitoring" – that is, it collects web traffic without having any effect on the operation of the site. This differs from synthetic monitoring with automated web browsers in that it relies on actual inbound and outbound web traffic to take measurements.

Instart's service provides a RUM capability. If enabled for a customer, baseline page load time information is exposed through the customer portal on the Analytics > Load Times pane. All raw data collected by the Nanovisor is available via log delivery for in-depth analysis.

Page load time information comes from the Navigation Timing API in modern (HTML 5-compliant) browsers. Navigation Timing is a JavaScript API that provides a simple way to get accurate and detailed timing statistics for page navigation and load events.

When RUM is enabled, the Nanovisor collects the Navigation Timing metrics when it runs, and periodically encodes this data into a query string which it appends to a request for blank.gif from the service, thereby beaconing the most recent timing data back for collection. The service, upon receiving the request, then decodes the query string and puts the values into both the statistics database used by the Customer Portal and the access log line (see below) stored for the request.

Here's an example query string with the Navigation Timing data (with line breaks added for readability):

?beacon={"id":"beacon","timing":{"loadEventEnd":1421885826360,
"loadEventStart":1421885826222,"domComplete":1421885826211,
"domContentLoadedEventEnd":1421885825814,"domContentLoadedEventStart":1421885825814,
"domInteractive":1421885825814,"domLoading":1421885823994,
"responseEnd":1421885825035,"responseStart":1421885823280,
"requestStart":1421885823280,"secureConnectionStart":0,"connectEnd":1421885823280,
"connectStart":1421885823280,"domainLookupEnd":1421885823280,
"domainLookupStart":1421885823280,"fetchStart":1421885823280,"redirectEnd":0,
"redirectStart":0,"unloadEventEnd":0,"unloadEventStart":0,
"navigationStart":1421885823279},"nav":{"redirectCount":0,"type":0}}

For the portal Load Times display, we calculate the following metrics:

  • Time to Page Load – the time between when the browser sends its request for the web page assets (that is, after the DNS lookups are finished and the TCP connection has been established) until the load event occurs. This is simply the difference between the time of the loadEventStart event and the requestStart event.
  • Time to Interactive – the time between when the browser sends its request for the web page assets (that is, after the DNS lookups are finished and the TCP connection has been established) until the page becomes responsive to user interactions. This is simply the difference between the time of the domInteractive event and the requestStart event.

Configuration

To enable RUM in the property configuration, add a monitoring block in an action block. The nv block with target set to auto or rum is also required, and a extra_flags block: 

"nv": {
      "injection": true,
      "release": "latest",
      "target": "auto",
      "client": {
        "extra_flags": "{\"disableQuerySelectorInterception\" :true,  'rumDataConfigKey':'/instartlogic/clientdatacollector/getconfig/monitorprod.json','custName':'acmestores','propName':'anvilworld'}"
      },
      "serve_from_parent_domain": true
    },

The value of rumDataConfigKey determines the config file for this customer. By default we use a common file (monitorprod.json). If you want to use a customer-specific file, please contact Support.

Important

The use of the extra_flag parameters is required for the period of time that the RUM v1 and v2 data pipelines are both active. If extra_flags is not present, the v1 pipeline is used. Eventually, we will retire the v1 pipeline and the need for the extra_flags parameters.

There is also another parameter that can be specified in the monitoring block – max_error_beacons, which specifies the maximum number of JavaScript errors that will be returned from the client. By default, this is 0.