revert edits, add note

Author: kimsauce

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

@@ -6,7 +6,7 @@ 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 (previously used to infer XHR activity, which is currently unsupported).
+* `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 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

@@ -26,7 +26,7 @@ Using the RUM HTTP Traces App for Manual Testing.
   allowfullscreen
 />
 
-<!-- old 
+<!-- old
 <Iframe url="https://www.youtube.com/embed/CduT1sqSPmE?rel=0"
         width="854px"
         height="480px"
@@ -37,12 +37,11 @@ Using the RUM HTTP Traces App for Manual Testing.
         allow="accelerometer; clipboard-write; encrypted-media; gyroscope; picture-in-picture"
         allowfullscreen
         />
---> 
+-->
 :::
 
 ## Prerequisites
-
-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).
+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).
 
 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).
 

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**. Previously used to represent AJAX-style interactions (XHR metrics are currently unsupported), or
+     * **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
      * **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 and log errors (XHR processing metrics are currently unsupported).
+* View information about [core web vitals, XHR processing times/errors, and log errors](/docs/apm/real-user-monitoring/metrics/#xhr-monitoring-metrics).
 * 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 log errors your users are experiencing (XHR metrics are currently unsupported).
+* Understand [XHR and log errors](/docs/apm/real-user-monitoring/metrics/#xhr-monitoring-metrics) your users are experiencing.
 * 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 load and timing metrics for the selected user cohort (XHR metrics are currently unsupported).
+* Understand [XHR, load, timing metrics](/docs/apm/real-user-monitoring/metrics/#xhr-monitoring-metrics) for the selected user cohort.
 * 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,6 +132,8 @@ 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 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.
+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.
 
 :::sumo Micro Lesson
 See Real User Monitoring in action.

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 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.
+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.
 
 For ad hoc queries, you can find these metrics in [Metrics Explorer](/docs/metrics/metrics-queries/metrics-explorer.md) by querying for:
 ```sql
@@ -121,6 +121,51 @@ 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
+
+:::note
+Currently, XHR metrics extraction in RUM is only supported for applications that use the `fetch` API to perform XHR calls. If your application uses `XMLHttpRequest`, metrics may not be collected at this time. A fix to support `XMLHttpRequest`-based calls is in progress and expected to roll out in mid 2025. We will update this page when that support becomes available.
+:::
+
+An **XMLHttpRequest (XHR)** is a way for browsers to communicate with a backend server without reloading the page. For example, a page may use XHR to update a price ticker automatically or after clicking an “Update Price” button.
+
+XHR is commonly used in *single-page applications* (SPAs), which load once and then handle all interactions without refreshing the page. These apps often generate multiple XHR requests—typically HTTP `POST` or `GET` calls—based on user actions.
+
+Sumo Logic provides monitoring coverage for XHR interactions, including the following performance timings:
+
+### `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.