Loading

Set up EDOT Browser

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):

flowchart LR
    A["Browser<br/>(EDOT Browser)"]
    B["Reverse Proxy"]
    C["Elastic Cloud<br/>Managed OTLP Endpoint"]
    D["EDOT Collector"]
    E["Elastic<br/>Observability"]
    A --> B
    B --> C
    B --> D
    C --> E
    D --> E

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 (if emitted by your application) are indexed and queryable.

    Note

    Logs are only present in Discover if your application uses the OpenTelemetry Logs API to emit them. Refer to Logs for more information on what EDOT Browser emits and how to configure log export.

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.

EDOT Browser measures how long it takes a user's browser to fully load the initial HTML document served by your web server by creating document load spans. It also generates spans to measure the download time of additional resources (such as JavaScript, CSS, fonts, and images) referenced by the initial document.

In the trace view, the documentLoad span appears as the root span, with resource spans as its children.

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.

EDOT Browser creates user interaction spans for events such as "click" and "submit". These spans represent the user action that triggered subsequent work (for example, a button click that leads to a fetch call). In Kibana, user interaction spans are used to group related spans: the interaction span is the logical parent or anchor for the cascade of operations that follow (for example, external.http requests and any child spans). When you analyze a trace, look for the user interaction span (for example, userinteraction or similar) to understand which click or submit caused the associated network and backend activity. This grouping makes it easier to attribute frontend and backend work to specific user actions.

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: