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.
What do the timings mean?
The timings are explained in the detail on the metric definition page.
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.
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.
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.
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 meta data API. Please be aware of the respective data protection laws.
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.
How does backend correlation work with AJAX calls?
What kind of ineum calls can we make?
Details about the global
ineum function are available within the website monitoring API documentation.
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.
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
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.
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.
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 the Google’s blog post about this subject or the respective Mozilla Firefox Page Visibility API to learn more.