Type to search.

Set up EDOT Browser

Serverless Observability

Elastic Cloud Serverless projects are autoscaled environments, fully managed by Elastic and available on Elastic Cloud.

Availability

  • Generally available

    This functionality is generally available and ready for production usage.

Stack

The Elastic Stack includes Elastic's core products such as Elasticsearch, Kibana, Logstash, and Beats.

Availability

  • Generally available

    This functionality is generally available and ready for production usage.

Unless stated otherwise on the page, this functionality is available when your Elastic Stack is deployed on Elastic Cloud Hosted, Elastic Cloud Enterprise, Elastic Cloud on Kubernetes, and self-managed environments.

This documentation corresponds to the latest patch available for each minor version. If you're not using the latest patch, check the release notes for changes.

EDOT Browser Preview

The Elastic Distribution of OpenTelemetry (EDOT) Browser SDK (RUM) collects performance metrics, traces, and logs from web applications in OpenTelemetry format, and sends them to Elastic Observability.

Availability

  • Preview

    This functionality is in technical preview and is ready for evaluation. Use with caution in production; it is not recommended for mission-critical workloads. Elastic will work to fix any issues, but features in technical preview are not subject to the support SLA of official GA features. Specific Support terms apply.

This documentation corresponds to the latest patch available for each minor version. If you're not using the latest patch, check the release notes for changes.

This guide shows you how to set up the Elastic Distribution of OpenTelemetry Browser (EDOT Browser) in a web application and export browser telemetry to Elastic Observability.

EDOT Browser runs directly in users' browsers. To send data securely without exposing secrets, use a reverse proxy. When your OTLP endpoint is available (Elastic Cloud managed OTLP or an EDOT Collector), do the following:

  • Install the agent: Add EDOT Browser to your application (package or bundle) and initialize it.
  • Configure proxy and CORS: Set up a reverse proxy in front of your OTLP endpoint and configure CORS so the browser can export telemetry securely.
Note

Do not run EDOT Browser alongside another APM or RUM agent (including classic Elastic APM browser agents). Multiple agents can cause conflicting instrumentation, duplicate telemetry, or unexpected behavior.

Before you set up EDOT Browser, you need:

  • An Elastic Observability deployment (Elastic Cloud or self-managed)
  • An OTLP ingest endpoint (Elastic Cloud Managed OTLP or an EDOT Collector)

EDOT Browser exports telemetry using the OpenTelemetry Protocol (OTLP) over HTTP. Data flows as follows (assuming you set up the proxy as recommended):

Mermaid diagram

The browser sends OTLP data to the reverse proxy endpoint that you configure. The reverse proxy then forwards data either to the Elastic Cloud Managed OTLP endpoint or to an EDOT Collector, depending on your chosen ingest path.

After EDOT Browser is sending telemetry to Elastic Observability, your browser app surfaces in the following Kibana experiences:

  • APM Service Inventory: Your browser app appears as a service.

  • APM trace view: Distributed traces including browser spans are visible.

  • Service Maps: Frontend-to-backend service dependencies are shown when your backend services are also instrumented and reporting telemetry to Elastic Observability.

  • Discover: Traces, metrics, and logs are indexed and queryable.

    Note

    EDOT Browser emits log records automatically for user actions, navigation, page and resource timing, Core Web Vitals, and errors. Your application can emit additional log records using the OpenTelemetry Logs API. Refer to Logs for details on each record type.

The User Experience app currently shows only data from classic Elastic APM Browser agents and does not display EDOT Browser data. For RUM-style dashboards compatible with EDOT Browser, install the RUM OpenTelemetry Assets integration from the Kibana Integrations catalog. The integration is currently in preview, requires Kibana 9.2.1 or later, and on the Integrations page you must turn on Display beta integrations to find it.

Outgoing HTTP requests made with the browser fetch API or XMLHttpRequest are captured as external.http spans. Each request to your backend APIs or third-party domains appears as an external.http span with attributes such as URL, HTTP method, and status code. These spans represent the client-side portion of the request (time in the browser) and, when your backend is instrumented with EDOT, link to the corresponding server-side trace using the trace context (trace ID and span ID) propagated in HTTP headers. In the trace view, you see the browser's external.http span as part of the same trace as the backend service spans when propagation is correctly configured.

Frontend-to-backend trace continuity depends on W3C Trace Context (traceparent and tracestate) headers being propagated from the browser request to the backend service. When propagation is configured correctly:

  • In the APM trace view, the browser's external.http span and the backend service spans appear in the same waterfall, so you can follow a request from the user action through the frontend to backend services.
  • In Discover, you can filter by trace.id (or by the frontend service.name) to retrieve every document that belongs to the same trace, including both browser-originated and backend spans.
  • In Service Maps, the browser external.http span's destination is matched to a backend service that is also instrumented and reported to Elastic Observability, producing the dependency edge between the frontend and that service.

If trace context is not propagated, browser and backend spans appear as separate traces, and no dependency edge is drawn between them in Service Maps.

After completing setup: