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, you can inspect traces and spans in the Observability app. The following describes what you see and how to interpret 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.

Traces that start in the browser (from a user interaction) and continue to your backend appear as end-to-end traces in Elastic Observability:

  • Discover: When you search or filter by your frontend service name or by trace ID, you see trace documents that include both browser-originated spans (for example, user interaction, external.http) and backend service spans, as long as trace context is propagated from the browser to the server. You can inspect the full path of a request from the user action through the frontend to backend services.
  • Service Maps: Your frontend application appears as a service node. Connections from that node to backend services are derived from the same trace data: when a browser external.http span targets a backend that is also instrumented and reported to Elastic Observability, a dependency link is shown between the frontend and that backend service. This gives you a map of how browser traffic flows to your backend services.

For more on how RUM and distributed traces appear in the Observability app, refer to User experience (RUM).

After completing setup: