Website Monitoring FAQ

Terminology

What is the difference between page views, loads and transitions?

Single-page applications and multi-page applications (or “classical websites”) work quite differently from a technical perspective. This difference is important to judge performance and thus user experience. For this reason we are differentiating between page views, page loads and page transitions. With the help of these terms we are able to clearly communicate how a website is used.

  • Page Load: A page load is defined as the retrieval of the initial HTML document and all subsequent actions until the next navigation in the browser, i.e. a navigation that will require a new HTML document to be loaded. The website content is typically rendered as HTML on the server and then delivered to the user. A multi-page application (or “classical websites”) will almost only have page loads. An example for a website implementing this architecture is Wikipedia.

  • Page Transitions: Websites may change the content that the users are looking at via JavaScript. In contrast to page loads, this doesn’t make use of classical browser navigation. Typically new website content is loaded via JavaScript and then turned into HTML. This HTML is then placed into the document to enrich/replace the already existing document. Single-page applications make heavy use of this technique. For single-page applications there is commonly a far larger number of page transitions than page loads. An example for a website implementing this architecture is Instana’s product.

    A page transition is triggered when the page name is changed via the API.

  • Page View: To judge general activity on a website no matter what architecture is implemented, the term page view is introduced. Page views are the the sum of page loads and page transitions.

Metrics

Why are the recorded timings for my HTTP calls so unusually huge?

Our website monitoring records the time between the start of the request, e.g. XMLHttpRequest#send, and the success event, e.g. XMLHttpRequest#onreadystatechange with readyState === 4. The time between these two events can vary greatly and is affected by…

  • HTTP redirects
  • DNS lookup time
  • Time to establish TCP / TLS connections
  • Server response times
  • Request queueing times
  • Latency and throughput
  • Request and response sizes
  • Page throttling

While most of these items are well understood, the last one is often surprising. Browsers may decide to throttle down or even stop processing for web pages that aren’t visible. Page throttling is most likely the reason for unusually huge timings. Refer to Google’s blog post about this subject or the respective Mozilla Developer Network Page Visibility API page to learn more.

What do the website metrics mean?

Most of the website metrics are received from the various W3C specifications. Specifically

The terminology used within these documents is adhered to as much as possible. Additionally we are using the following metrics:

  • onLoad Time: This timing exists for each page load and models the time until a navigation is complete, i.e. the loading spinner has stopped. It is defined as loadEventEnd - fetchStart (see navigation timing). Within the user interface we always make the distinction between onLoad Time and onLoad Event Time to be explicit about the differences in terminology between the Instana user interface and the navigation timing specification.
  • DOM: A variation of the timing defined in navigation timing. This metric is defined as domContentLoadedEventStart - domLoading (see navigation timing). It is meant to be a more generally useful timing breakdown than navigation timing’s processing time. Also see the picture below to understand DOM time.
  • Children: A variation of the timing defined in navigation timing. This metric is defined as loadEventEnd - domContentLoadedEventStart (see navigation timing). It is meant to be a more generally useful timing breakdown than navigation timing’s onLoad times. Also see the picture below to understand Children time.

Navigation Timing Variation

Data collection

How are you gathering this information?

Instana’s website monitoring is based on Instana’s open source library called weasel. Weasel gathers the information from the Browser Navigation Timing API and transmits it in an efficient form. You can inspect its source code on GitHub to get all the information you may need.

Which browsers are supported?

The JavaScript agent is designed to support all browsers. Some APIs aren’t supported in older browsers though. In these cases the JavaScript agent won’t fail, but certain data point are not going to be available, e.g. navigation, resource and paint timing information could be missing.

How do you handle browsers which do not support the navigation timing API?

For browsers which do not support the navigation timing API, we provide approximate timings. These timings are not reliable and we do not encourage you to rely on approximate page load timings for these traces too much. In fact, when Instana has to resort to approximations for page load times, Instana will not include these values in statistics. This means that approximations are not part of aggregated page load times like mean, min, and max load times.

What kind of ineum calls can we make?

Details about the global ineum function are available within the website monitoring API documentation.

Why are you blocked by Adblock or similar browser extensions?

While most of those extensions were created to not display advertisements, most of them evolved into extensions that prevent website owners to track their users. The Instana monitoring script ended up in many of those extensions, and there is nothing we can do to have them revert their decision. If you have some control over your users, you can ask them to allow the EUM script in their adblocker.

How does backend correlation work with AJAX calls?

For AJAX calls, the backend correlation works out of the box for same-origin calls. Same-origin calls are calls, for which the protocol, domain and port of the HTML document are matching the protocol, domain and port of the AJAX call target. This restriction exists due to the same-origin policy. Specifically, the JavaScript agent is not allowed to add tracing headers for cross-origin calls.

Which HTTP endpoints are end-users making calls to (for SaaS)?

You should never need to configure anything for correct data transmission to Instana’s SaaS platform. The Instana user interface will always present correct tracking snippet which include the necessary URLs.

  • Retrieval of the JavaScript agent (all regions)

    • DNS Name: eum.instana.io
    • Ports: tcp/80 (HTTP) and tcp/443 (HTTPS)
  • Transmission of monitoring data to the European region

    • DNS Name: eum-eu-west-1.instana.io
    • Ports: tcp/80 (HTTP) and tcp/443 (HTTPS)
  • Transmission of monitoring data to the United States region

    • DNS Name: eum-us-west-2.instana.io
    • Ports: tcp/80 (HTTP) and tcp/443 (HTTPS)

Is it possible to proxy the HTTP endpoints (for SaaS)?

We strictly recommend not to attempt proxying of the HTTP endpoints. Please understand that we will not provide any support for any proxy setups nor for any issues that may arise due to the usage of a proxy. Should you still want (or have) to do this, you may find these pointers helpful:

  • Set proper Host HTTP headers.
  • Respect the difference between the eum.instana.io and eum-{region}.instana.io servers.
  • Make sure that our servers are aware of the end-users IPs. Send an X-FORWARDED-FOR header to our servers with the end-user’s IP. Alternatively send a X-REALER-IP HTTP header (yes, deliberately not X-REAL-IP) to the Instana servers which contains the end-user’s IP.
  • Pass through all the HTTP headers that the Instana servers include in the response body.
  • Don’t do any caching in the proxy.

Which HTTP headers are being used?

The JavaScript agent makes use of the following HTTP headers to achieve backend correlation.

  • Request Headers (to the backend):

    • X-INSTANA-T
    • X-INSTANA-S
    • X-INSTANA-L
  • Response Headers (to the frontend):

    • Server-Timing

Sensitive data

Are you collecting data which can uniquely identify users?

The Instana JS agent, by default, does not include data which can unique identify users. Furthermore, the Instana JS agent also does not apply techniques such as device / browser fingerprinting.

User specific data can be made available to Instana via the user API.

What are you doing with the user data transmitted to Instana?

The user API can be configured by customers to transmit user identifying information to Instana. This information is only used to provide the features visible within the product. Instana does not interpret this data in any other way, nor is it correlated across multiple customers.

Is it possible to delete user data after it has been transmitted to Instana?

Infrequent deletion requests, e.g. to comply with GDPR, are supported. If you expect frequent or periodic deletion requests, please instead transmit anonymized data to Instana (e.g. hashed user IDs).

Are you anonymizing IPs?

Yes, IPs are anonymized. Specifically, the last octet of IPv4 addresses, and the last 80 bits of IPv6 addresses are set to zeros.

Impact of web security

We have a Content-Security Policy in place, is there anything we need to do?

The Instana JS agent is asynchronously loaded from eum.instana.io and can be loaded via HTTP(S). Please ensure that loading scripts from this domain is possible.

Data is transmitted to Instana via image loads as well as HTTP GET and POST requests (via XMLHttpRequest). The origins used for data transmission can be seen in the tracking snippet.

The following Content-Security Policy definition shows what is necessary for Instana’s SaaS product:

script-src *.instana.io;
img-src *.instana.io;
connect-src *.instana.io;

What is the impact of same-origin policy on website monitoring?

The same-origin policy is one of the most fundamental website security concepts. Every website is subject to it as it is enforced by all web browsers. As a website monitoring provider, we cannot control your websites’ or browsers’ security. Because of this, we can only work within the imposed security constraints. Unfortunately, this restricts our monitoring abilities.

  • Browsers restrict access to error messages and stacktraces to scripts of the same origin.
  • Browsers restrict allowed HTTP headers for cross-origin requests. This means that backend correlation isn’t always possible.

In order to unlock these features when multiple origins are involved, cross-origin resource sharing (CORS) can be used. CORS is a mechanism with which small controlled holes can be opened within the same-origin policy security mechanism. The following picture describes in detail what needs to be done in order to address the same-origin policy imposed restrictions.

Picture explaining cross-origin capable end-user monitoring.

Why are detailed resource retrieval breakdowns not always available?

The availability of insights into network times, caching statistics and asset sizes relies on resource timing capabilities. These capabilities are available in most modern web browsers when allowed by the same-origin policy.

To enable insights into resources of cross-origin resources, e.g. origin https://cdn.example.com:443 for an HTML document loaded from https://example.com:443, the Timing-Allow-Origin HTTP header can be used. The following picture shows how this header needs to be set. Also see the resource timing specification for more information.

Picture explaining cross-origin capable end-user monitoring.

Instana makes use of Cloudflare as its content-delivery network (CDN) to ensure performance and availability of the JavaScript agent for our customers and their end-users. Cloudflare sets a cookie called __cfduid when serving responses from its CDN that does not yet specify a SameSite attribute. Cloudflare is working on adding the attribute to its cookie. Until this work is finished we kindly ask you to ignore this warning as it doesn’t have any end-user impact.

Should I use Instana for my business analytics use-cases?

While some business analytics use-cases can be addressed with the data collected by Instana, our focus is on delivering a best-in-class performance product, and as such are not a replacement for a dedicated business analytics product.

JavaScript Stack Trace Translation

What is JavaScript Stack Trace Translation?

The JavaScript stack trace translation provides readable and more actionable stack traces within Instana.

Before:
at http://shop-demo-app.instana.io/static/js/main.b1510333.chunk.js:1:1559

After:
at ProductDetails.js 26:11

The problem with untranslated stack trace lines is that the errors aren’t actionable. Developers work with many (typically small) files, and for performance reasons, these files are shipped to end-users’ browsers in a bundled and minified format, resulting in file names, lines, and column numbers in stack traces that are not human-readable nor actionable.

With a translated stack trace, it’s clear that the error occurring at …/main.b1510333.chunk.js:1:1559 is in fact at ProductDetails.js 26:11.

How does JavaScript Stack Trace Translation work?

The translation works by utilizing source maps. Source maps enable us to translate un-actionable stack traces to actionable stack traces. More specifically, they allow us to translate references to files, names, lines, and columns to their actual source code counterparts.

To achieve this, Instana executes the following steps:

  1. The JavaScript agent reports JavaScript errors to Instana’s servers. For example, let’s assume the stack trace contains the line at http://shop-demo-app.instana.io/static/js/main.b1510333.chunk.js:1:1559.
  2. Instana’s servers attempt to download the JavaScript file to identify the source map responsible for this file.
  3. The HTTP response is parsed, and Instana looks for references to source maps.
  4. When a source map file is referenced, Instana downloads the source map file via an HTTP GET request.
  5. When the download is successful, the source map file is used to translate the file, name, line, and column references.

Let’s look at these steps for the stack trace line at http://shop-demo-app.instana.io/static/js/main.b1510333.chunk.js:1:1559.

  1. An error is reported to Instana’s servers.
  2. Instana’s servers issue an HTTP GET request to http://shop-demo-app.instana.io/static/js/main.b1510333.chunk.js.
  3. The source map reference //# sourceMappingURL=main.b1510333.chunk.js.map is located in the JavaScript file.
  4. The source map file http://shop-demo-app.instana.io/static/js/main.b1510333.chunk.js.map is downloaded via an HTTP GET request.
  5. The source map is parsed, and the stack trace made readable.

How exactly are you retrieving files from our servers?

As soon as we learn about the stack trace, Instana automatically issues HTTP requests to retrieve the JavaScript and source map files. The closest representation of the calls we do is the following:

curl -H 'Accept: */*' \
  # Use a fake user-agent to bypass simple bot blockers
  -H 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3809.100 Safari/537.36' \
  {{url of JavaScript or source map files}}

You can use the previous command to identify what kind of configuration Instana would need to download the JavaScript and source map files from your servers. Please note that the HTTP requests are issued from servers running inside of AWS (Amazon Web Services). Advanced bot detection mechanisms might block requests coming from AWS. Therefore, consider configuring additional headers that Instana should send to your servers in order to circumvent bot detection mechanisms.