[Internal]: OTEL RUM update documents

[david-luna]

Description

OTEL components and instrumentations for browsers have been updated recently. The most important changes are:

• a browser SDK package which simplifies a lot the instrumentations bootstrap
• a new set of instrumentations replacing/deprecating the current ones

These new packages are already available and recommended to use over the legacy ones. Documentation is available at https://github.com/open-telemetry/opentelemetry-browser/blob/main/packages/sdk/README.md

This means our onboarding manual for OTEL users is outdated. The current version is still correct but thanks to the updates in upstream the code can be simplified a lot.

Resources

New SDK package shows a quickStart method in https://github.com/open-telemetry/opentelemetry-browser/blob/main/packages/sdk/README.md

Instrumentations have changed. Refs:

• Migrate or deprecate browser packages from opentelemetry-js and opentelemetry-js-contrib open-telemetry/opentelemetry-browser#209
• feat(browser-instrumentation): add fetch instrumentation open-telemetry/opentelemetry-browser#281
• feat(browser-instrumentation): add XHR instrumentation open-telemetry/opentelemetry-browser#367
• feat: resource timing instrumentation open-telemetry/opentelemetry-browser#162

Which deployment methods does this change impact?

Unknown

Feature differences

No response

What Elastic Stack release is this request related to?

N/A

Serverless release

No response

Collaboration model

Unknown

Point of contact.

Main contact: @david-luna

[github-actions]

Elastic Docs AI Menu

Check one box to run an AI workflow for this issue.

• Scope the docs work (docs-scope). Status: completed. View progress.

Powered by GitHub Agentic Workflows and docs-actions. For more information, reach out to the docs team.

[david-luna]

@alexandra5000 @theletterf

Your feedback on this would be appreciated. I can start a draft PR if you think the change is worth it

[alexandra5000]

@david-luna I'll take a look as soon as possible. Thanks! Fabrizio is now docs engineering, so it's best to ask me directly about any OTel-related docs updates 🙂

[github-actions]

✅ ScopeBot finished. https://github.com/elastic/docs-content/actions/runs/37301231123

Generated from Gh Aw Issue Scope

[github-actions]

🟢 ScopeBot Results: Full assessment

Summary

The issue asks to refresh the OpenTelemetry RUM onboarding manual so it reflects the newer browser SDK and instrumentation packages. The published RUM page still contains a hand-assembled browser SDK setup, while the published EDOT Browser setup and configuration pages provide a newer canonical path. The linked upstream changes confirm merged fetch, XMLHttpRequest, and resource-timing instrumentation work; the current upstream browser README also documents the browser-instrumentation package and examples.

Request accuracy

Partially accurate: the linked changes support the need to revisit browser instrumentation guidance, but the issue's referenced quickStart method is not present in the current upstream README, so the exact replacement API must be confirmed before drafting.

Recommended docs targets

Page	URL	Action	Confidence	Why this page?
OpenTelemetry for Real User Monitoring (RUM)	https://www.elastic.co/docs/solutions/observability/applications/otel-rum	Update existing page	High	This is the onboarding manual named in the issue, and its current setup examples are the clearest place to replace or reconcile the older package and instrumentation instructions.
Set up EDOT Browser	https://www.elastic.co/docs/reference/opentelemetry/edot-sdks/browser/setup	Review only	Medium	This page already documents the current browser setup, including fetch/XHR spans, resource spans, proxy/CORS requirements, and Kibana behavior; review it for consistency after changing the RUM onboarding page.
Configure EDOT Browser	https://www.elastic.co/docs/reference/opentelemetry/edot-sdks/browser/configuration	Review only	Medium	Its instrumentation configuration table already lists the current fetch and XMLHttpRequest names, so it should be checked against the package/API selected for the onboarding update.

How to tackle this

1. Confirm the supported upstream package and initialization API, including whether the intended entry point is the referenced quickStart method or the current EDOT Browser initialization path.
2. Update the RUM onboarding page to use the supported package and current instrumentation names, preserving the reverse-proxy, CORS, authentication, and browser-constraint guidance that remains applicable.
3. Link the onboarding flow to the canonical EDOT Browser setup and configuration pages instead of duplicating detailed setup instructions.
4. Validate every code sample against the selected package version, including fetch, XMLHttpRequest, resource timing, and any default-versus-optional instrumentation behavior.
5. Review the EDOT Browser setup and configuration pages for contradictory package names, defaults, or instrumentation lists after the RUM page is revised.

Scope boundary

The linked evidence does not indicate a need to change RUM dashboards/assets, classic Elastic APM RUM agent documentation, or release-note pages for this onboarding update.

Questions to go deeper

• Should the RUM page migrate fully to EDOT Browser, or should it continue documenting a lower-level upstream OpenTelemetry setup as an alternative?
• Which upstream package and initialization API are supported for the docs version being updated, given that the referenced quickStart method is not present in the current upstream README?
• Are fetch, XMLHttpRequest, and resource-timing instrumentations enabled by default in the supported Elastic package, or should users configure them explicitly?
• Which cumulative documentation versions and deployment variants must retain the existing setup instructions?

Generated from Gh Aw Issue Scope · ◷