DOCS-895 - Remove XHR metrics from RUM docs

docs/apm/real-user-monitoring/browser-traces.md

@@ -6,8 +6,8 @@ sidebar_label: RUM Browser Traces
 
 To collect browser RUM traces, create a [trace query](/docs/apm/traces/view-and-investigate-traces) that specifies traces starting with the value you gave to `<name_of_your_web_service>` as a root service name. You can also include the following filters as an operation name:
 * `documentLoad` as an operation name to find traces that correspond to page loads.
-* `Click on *` as an operation name to detect click actions that most likely resulted in XHR calls
-* `Navigation: *` as an operation name to detect single-page app navigation changes
+* `Click on *` as an operation name to detect click actions (previously used to infer XHR activity, which is currently unsupported).
+* `Navigation: *` as an operation name to detect single-page app navigation changes.
 
 Click on any of the load spans, such as `documentLoad`, `documentFetch`, or `resourceFetch` (for `documentLoad`), to open a right-side panel with detailed span metadata, including timing events.
 

docs/apm/real-user-monitoring/configure-data-collection.md

@@ -41,7 +41,8 @@ Using the RUM HTTP Traces App for Manual Testing.
 :::
 
 ## Prerequisites
-To utilize XHR and navigation/route changes, and errors collection, you must use RUM script version 4 or higher (`https://rum.sumologic.com/sumologic-rum-v4.js`). Make sure you're using the correct version in your pages. For automatic updates, use the script `https://rum.sumologic.com/sumologic-rum.js`. You can find more details about versioning control [later in this document](#step-2-add-rum-script-to-your-page-header).
+
+To utilize navigation/route changes and errors collection, you must use RUM script version 4 or higher (`https://rum.sumologic.com/sumologic-rum-v4.js`). XHR metrics are currently unsupported. For automatic updates, use the script `https://rum.sumologic.com/sumologic-rum.js`. You can find more details about versioning control [later in this document](#step-2-add-rum-script-to-your-page-header).
 
 For full end-to-end visibility, we recommended supplementing your RUM browser auto-instrumentation with the appropriate [back-end tracing instrumentation](/docs/apm/traces/get-started-transaction-tracing).
 
@@ -83,8 +84,8 @@ To configure a RUM HTTP Traces source:
      :::warning **Propagate Trace Header CORS URLs**
      Sumo Logic cannot perform configuration validation of services of other origins. You should always enable context propagation and CORS configuration changes in a test environment before setting it up in production.
      <details>
-     This list is empty by default, which means trace context propagation&#8212;allowing creation of front-end to back-end traces for cross-origin requests&#8212;is not enabled because of browser CORS security restrictions. To connect your front-end and back-end traces, make sure your environment supports [W3C Trace Context](https://www.w3.org/TR/trace-context) HTTP headers. 
-     
+     This list is empty by default, which means trace context propagation&#8212;allowing creation of front-end to back-end traces for cross-origin requests&#8212;is not enabled because of browser CORS security restrictions. To connect your front-end and back-end traces, make sure your environment supports [W3C Trace Context](https://www.w3.org/TR/trace-context) HTTP headers.     
+
      To propagate tracing context to create front-end to back-end traces, set the domain(s) to propagate W3C tracing context to. You must configure your servers/APIs to accept and return the following CORS headers in their response: `Access-Control-Allow-Headers: traceparent, tracestate`.
 
      Valid cross-origin resources must include the prefix `http://` or `https://` and the domain name. The port number is not required unless it differs from the default for HTTP (port 80) or HTTPS (port 443).

docs/apm/real-user-monitoring/dashboards.md

@@ -43,7 +43,7 @@ Once the RUM app has been installed, use the Real User Monitoring view to gain v
    * **deployment.environment**. corresponds to your development environment. To enable this, add the `deployment.environment` tag and desired value (like `us-west-1`, `prod`, `dev`) to your [RUM script](/docs/apm/real-user-monitoring/configure-data-collection/#step-2-add-rum-script-to-your-page-header). Supports up to 10 **deployment.environment** values.
    * **Action Type**: can be one of:
      * **document loads**. Representing loading of actual documents and their resources into the browser
-     * **XHR actions**. Representing any interaction with a page like click or submit that executes AJAX requests in the background to communicate with the backend, or
+     * **XHR actions**. Previously used to represent AJAX-style interactions (XHR metrics are currently unsupported), or
      * **route changes**. Single-page-app specific way to navigate to a new page/view without having to load a new document.
    * **Action Name**. Automatically generated from URLs. No configuration is required. The specifics of it will depend on action type. Action names can contain asterisks (`*`) to replace automatically-detected dynamic parts of the URL. If you have action names that overlap, the action name with an asterisk contains data for page loads NOT contained in more specific action names. For example, `http://www.site.com/path/page.htm` does not contain actions from `http://www.site.com/path/*`.
 
@@ -58,7 +58,7 @@ The **RUM Overview** dashboards (**Application**, **Service**, **Service with En
 
 Use these dashboards to:
 * Analyze load and paint timings for page document loads by application, service, or action.
-* View information about core web vitals, XHR processing times/errors, and log errors.
+* View information about core web vitals and log errors (XHR processing metrics are currently unsupported).
 * Understand what top browsers, operating systems, and geolocations are active with your website.
 
 You can select the timing metric type in the **statistic** dropdown on the dashboard header. This will change the browser time metrics types on charts.
@@ -78,7 +78,7 @@ The **RUM - TopN - Application** and **RUM - TopN - Application Service** dashbo
 Use these dashboards to:
 * Find out top N browsers, operating systems, and geolocations by load or requests.
 * Understand the slowest and fastest browsers from a rendering perspective or geographical locations from a network perspective.
-* Understand XHR and log errors your users are experiencing.
+* Understand log errors your users are experiencing (XHR metrics are currently unsupported).
 * Find out which browsers and operating systems are in use by your users and where are they are geographically located.
 
 You can select the timing metric type in the **statistic** dropdown on the dashboard header. This will change the browser time metrics types on charts. You can also define the top N number for all charts.
@@ -91,7 +91,7 @@ The **RUM Performance Analytics** dashboards for **Application**, **Service**, a
 
 Use these dashboards to:
 * Filter data for specific combinations of browser, operating system, and/or geolocation.
-* Understand XHR, load, timing metrics for the selected user cohort.
+* Understand load and timing metrics for the selected user cohort (XHR metrics are currently unsupported).
 * Compare your selected timings against data for a different time period by selecting the appropriate option in the compare_with dropdown.
 
 You can click on any data point on the charts to open a details panel and view the **Infrastructure** tab to drill-down to traces representing user transactions from the selected time point. For cross-dimensional metrics, only the average statistic type is available.
@@ -132,8 +132,6 @@ In addition to that, we also aggregate that information in form of log-query bas
 
 <img src={useBaseUrl('img/rum/logerrors2.png')} alt="Real User Monitoring log errors per second graphic" />
 
-<img src={useBaseUrl('img/rum/logerrors-xhr.png')} alt="Real User Monitoring log errors XHR per second graphic" />
-
 <img src={useBaseUrl('img/rum/logerrors-by-browser.png')} alt="Real User Monitoring log errors by browser, operating system, and geolocations graphic" />
 
 Logs collection is enabled by default. You can disable by setting `collectErrors=false` in your RUM script options.

docs/apm/real-user-monitoring/index.md

@@ -21,7 +21,7 @@ The [Sumo Logic OpenTelemetry auto-instrumentation for JavaScript](https://githu
 
 This data is gathered directly from your end-user devices and displayed as individual spans representing user-initiated actions (like clicks or document loads) at the beginning of each trace, reflecting its request journey from the client throughout the whole application and back. This includes any unhandled errors, exceptions, and console errors generated by the browser.
 
-All data collected is compatible with OpenTelemetry and doesn't use proprietary vendor code. Real user monitoring supports document load actions as well as XHR communication and route changes for single-page app navigation. The full list of functionalities and configuration is available in the [Sumo Logic OpenTelemetry auto-instrumentation for JavaScript](https://github.com/SumoLogic/sumologic-opentelemetry-js) README file.
+All data collected is compatible with OpenTelemetry and doesn't use proprietary vendor code. Real user monitoring supports document load actions and route changes for single-page app navigation. XHR communication is currently not supported due to a known issue. The full list of functionalities and configuration is available in the [Sumo Logic OpenTelemetry auto-instrumentation for JavaScript](https://github.com/SumoLogic/sumologic-opentelemetry-js) README file.
 
 :::sumo Micro Lesson
 See Real User Monitoring in action.
@@ -64,7 +64,7 @@ Access Traces to confirm that your Sumo Logic service package has been upgraded
 [**Classic UI**](/docs/get-started/sumo-logic-ui-classic). To access Traces, go to the **Home** screen and select **Traces**.
 
 [**New UI**](/docs/get-started/sumo-logic-ui/). To access Traces, in the main Sumo Logic menu select **Observability**, and then under **Application Monitoring** select **Transaction Traces**. You can also click the **Go To...** menu at the top of the screen and select **Transaction Traces**.
- 
+
 
 ## Guides
 

docs/apm/real-user-monitoring/metrics.md

@@ -8,7 +8,7 @@ import useBaseUrl from '@docusaurus/useBaseUrl';
 
 RUM metrics are automatically generated for you from browser traces. They provide insight into your website's overall user experience as well as front-end services, operating systems, geographical locations, and top-loaded page groups and user cohorts categorized by their browsers.
 
-Metrics are collected for user actions representing document loads, which means actual retrieval and execution of web documents in the browser as well as XHR calls and route changes. Measurements include W3C navigation timings, XHR delays, Core Web Vitals KPIs, longtask events (delays) and others.
+Metrics are collected for user actions representing document loads and route changes, which means actual retrieval and execution of web documents in the browser or navigation within single-page apps. While XHR calls may still occur, XHR-specific metrics are currently unsupported. Measurements include W3C navigation timings, Core Web Vitals KPIs, and longtask events.
 
 For ad hoc queries, you can find these metrics in [Metrics Explorer](/docs/metrics/metrics-queries/metrics-explorer.md) by querying for:
 ```sql
@@ -121,47 +121,6 @@ These CWV KPIs are captured and displayed on Overview dashboards for Document Lo
 
 [Cumulative Layout Shift (CLS)](https://web.dev/cls/) measures visual stability. To provide a good user experience, pages should maintain a CLS of **0.1** or less.
 
-## XHR monitoring metrics
-
-An XML HTTP Request (XHR) is a form of communication between the browser and the application backend without reloading the page. A typical example is when a page needs to update a price ticker automatically or after pressing the “update price” button next to it.
-
-The XHR technique is frequently used in _single-page apps_ — apps that load the page once and then provide all interaction and navigation without loading additional documents. These pages can generate one or more XHR requests, typically in the form of HTTP POSTs/GETs, related to various user actions on a page. Sumo Logic provides the following monitoring coverage for XHR interactions:
-
-Pages can generate one or more XHR requests, typically in the form of HTTP POSTs, related to various user actions on a page. The following performance timings are measured:
-
-### `browser_time_to_first_xhr`
-
-Time from the UI interaction until the first HTTP POST appears.
-
-### `browser_time_to_last_xhr`
-
-Time from the UI interaction until the last HTTP POST ends.
-
-### `browser_time_to_xhr_processing_end`
-
-Time from the UI interaction until all browser-side processing of all XHR requests is completed.
-
-### `browser_time_in_xhr_calls`
-
-The total time when the transaction was “busy” executing XHR communication.
-
-In addition to these metrics, the system also measures how many XHR requests have been generated and identifies the user action that triggered the XHRs by blending the UI interaction (e.g., `“click on Pay”`) with the page name (e.g., `http://www.acme.com/checkout`). This results in an action name like `"Click on Pay on http://www.acme.com/checkout"`. Any erroneous HTTP responses to XHR POST calls are counted as XHR errors.
-
-We also measure any erroneous HTTP responses to XHR POST calls, counting them as XHR errors, and provide drill-down capabilities via EI to specific traces that explain the full process of loading and executing each transaction.
-
-<img src={useBaseUrl('img/rum/xhr-action.png')} alt="Interface for monitoring XHR interactions, displaying performance timings and metrics for XMLHttpRequests within a web application" style={{border: '1px solid gray'}} />
-
-<!--
-### Navigation (Route Change) Metrics
-Another browsing technique used by single-page apps is a special way of handling page navigation (e.g., clicking on links, buttons) called route change. It is basically a way to navigate to a new page/view without having to load a new document.
-Every time we open a new tab in Sumo, we do a route change (but we are not loading the whole document at the same time). Such actions typically also generate some XHR calls in the background. What we do with this is:
-* Create a special type of user actions called `route_changes` with the name of the page that is being opened (i.e., “Route to [https://service.us2.sumologic.com/ui#/search/*](https://service.us2.sumologic.com/ui#/search/*)”)
-* Show these actions as third type of action next to document loads and XHR requests
-* Measure same type of metrics for them as for XHR requests
-* Allow drill-down via EI to specific traces that explain full process of loading and execution of each such transaction
-<img src={useBaseUrl('img/rum/nav-action.png')} alt="Real User Monitoring" />
--->
-
 ## Longtask delay metrics
 
 This section describes how to trace and measure [Longtask delays](https://github.com/w3c/longtasks), which is when the main browser UI thread becomes locked for extended periods (greater than 50 milliseconds) and blocks other critical tasks (including user input) from being executed.