Loading

OpenTelemetry for Real User Monitoring (RUM)

Serverless Observability Stack Preview

Important

Using OpenTelemetry for Real User Monitoring (RUM) with Elastic Observability is currently in technical preview and should not be used in production environments. This feature may be changed or removed in a future release and has known limitations. Features in preview are not subject to support SLAs like GA features.

You can instrument your web application with OpenTelemetry browser instrumentation for use with Elastic Observability. The following sections detail the required components and their proper configuration to acquire traces, logs, and metrics from the application to visualize them within Kibana.

You need an OTLP endpoint to ingest data from the OpenTelemetry RUM instrumentation. If you're setting up a new deployment, create an Elastic Cloud hosted deployment or Serverless project, which includes the Elastic Cloud Managed OTLP Endpoint. If you own a self-hosted stack or your deployment does not have the Elastic Cloud Managed OTLP Endpoint, configure an EDOT Collector in Gateway mode.

After you have prepared the OTLP endpoint, set up a reverse proxy to forward the telemetry from your web application origin to the Collector. You need a reverse proxy for the following reasons:

  • EDOT Collector requires an Authorization header with an ApiKey to accept OTLP exports. Setting up the required key in a web application makes it publicly available, which is not advisable. A reverse proxy can help you manage this key securely.
  • If you have set up your own EDOT Collector, it's likely to have a different origin than your web application. In this scenario you have to set up CORS for the web application in the EDOT Collector configuration file. This procedure can be cumbersome if you have to manage many applications.
  • You can apply rate limiting or any other mechanisms to control traffic before it reaches the EDOT Collector.

The following snippet shows the configuration for an NGINX reverse proxy to forward all telemetry to the EDOT Collector located at collector.example.com from the origin webapp.example.com:

Warning

Avoid using the OTel RUM agent alongside any other APM agent, including Elastic APM agents. Running multiple agents might lead to conflicting instrumentation, duplicate telemetry, or other unexpected behavior.

The minimal configuration you need to instrument your web application with OpenTelemetry includes:

  • OTEL_EXPORTER_OTLP_ENDPOINT: The full URL of the proxy you have configured in the OTLP endpoint section.
  • OTEL_RESOURCE_ATTRIBUTES: A JavaScript object that will be used to define the resource. The most important attributes to define are:
    • service.name (string): Name of the application you're instrumenting.
    • service.version (string, optional): A string representing the version or build of your app.
    • deployment.environment.name (string, optional): Name of the environment where the app runs (if applicable); for example, "prod", "dev", or "staging".
  • OTEL_LOG_LEVEL: Use this configuration to set the log level of the OpenTelemetry components you're going to use. Supported values are: error, warn, info, debug, verbose.

To instrument your web application with OpenTelemetry in the browser, you need to add a script that configures the essential components, including the context manager, signal providers, processors, and exporters. After adding the script, you can register the instrumentations so they can observe your app and send telemetry data to your endpoint.

The following starter script is in plain JavaScript. If you use TypeScript, you can adapt this script by changing the file extension to .ts and adding the necessary type definitions. OpenTelemetry packages are written in TypeScript, so they include the appropriate type definitions for TypeScript.

Note

Each signal configuration is independent of the others and has to be configured independently. The OpenTelemetry API defaults to no-op providers for traces, metrics, and logs.

  1. Set the configuration

    Start by setting the options to be used by all the signals and the instrumentation code, as well as initializing the internal logger.

    For this step, you need the following dependencies:

    • @opentelemetry/api: All the packages are included. Each signal configuration uses it to register the providers for each signal.
    • @opentelemetry/core: Contains core types and some utilities for the rest of the packages. It parses strings to the correct type.

    To install the dependencies, run the following command:

    npm install @opentelemetry/api @opentelemetry/core
    		

    After the dependencies are installed, configure the following options:

  2. Define the resource

    A resource is an entity that generates telemetry, with its characteristics captured in resource attributes. An example is a web application operating within a browser that produces telemetry data.

    A standardized set of attributes is specified in Browser resource semantic conventions, which can be included alongside those outlined in the configuration section. OpenTelemetry offers resource detectors like browserDetector to help set these attributes like brands, mobile, and platform.

    To define the resource, you need the following dependencies:

    • @opentelemetry/resources: This package helps you to define and work with resources because a Resource is not a plain object and has some properties (like immutability) and constraints.
    • @opentelemetry/browser-detector: Detectors help you to define a resource by querying the runtime and environment and resolving some attributes. In this case, the browser detector resolves the language, brands, and mobile attributes of the browser namespace.

    To install the dependencies, run the following command:

    npm install @opentelemetry/resources @opentelemetry/browser-detector
    		

    After the dependencies are installed, define the resource for your instrumentation with the following code:

  3. (Optional) Configure tracing

    Configure a TracerProvider to enable instrumentations to transmit traces and allow for the creation of custom spans. A TracerProvider requires several components:

    • Resource: The resource to be associated with the spans created by the tracers. You defined this in the second step.
    • Span Processor: A component that manages the spans generated by the tracers and forwards them to a SpanExporter. The exporter should be configured to direct data to an endpoint designated for traces.
    • Span Exporter: Manages the transmission of spans to the Collector.
    • Context Manager: A mechanism for managing the active Span context across asynchronous operations and threads. It ensures that when a new Span is created, it correctly identifies its parent Span.

    For this step, you need the following dependencies:

    • @opentelemetry/sdk-trace-base: This package contains all the core components to set up tracing regardless of the runtime they're running in (Node.js or browser).
    • @opentelemetry/sdk-trace-web: This package contains a tracer provider that runs in web browsers.
    • @opentelemetry/exporter-trace-otlp-http: This package contains the exporter for the HTTP/JSON protocol.
    • @opentelemetry/context-zone: This package contains a context manager which uses on zone.js library.
    npm install @opentelemetry/sdk-trace-base\
          @opentelemetry/sdk-trace-web\
          @opentelemetry/exporter-trace-otlp-http\
          @opentelemetry/context-zone
    		

    After the dependencies are installed, configure and register a TracerProvider with the following code:

    Now you can use the OpenTelemetry API to get a tracer and start creating your own spans. Instrumentations are also using OpenTelemetry API to get tracers and send telemetry data. Registering intrumentations after having the tracer provider set up ensures they have the right tracers when requested to the API.

  4. (Optional) Configure metrics

    Similar to traces, configure a MeterProvider for metrics. A MeterProvider requires several components:

    • Resource: The resource to be associated with the metrics created by the meters. You defined this in the second step.
    • Metric Reader: Used to determine how often metrics are collected and what destination they should be exported to. In this case, use a PeriodicExportingMetricReader configured to collect and export metrics at a fixed interval.
    • Metric Exporter: Responsible for serializing and sending the collected and aggregated metric data to a backend observability platform. Use the OTLP/HTTP exporter.

    For this step, you need the following dependencies:

    • @opentelemetry/sdk-metrics: This package contains all the required components to set up metrics.
    • @opentelemetry/exporter-metrics-otlp-http: This package contains the exporter for the HTTP/JSON protocol.

    To install the dependencies, run the following command:

    npm install @opentelemetry/sdk-metrics @opentelemetry/exporter-metrics-otlp-http
    		

    After the dependencies are installed, configure and register a MeterProvider with the following code:

  5. (Optional) Configure logs

    Like traces and metrics, configure a LoggerProvider if you want to record relevant events that are happening in your application using the API or instrumentations. A LoggerProvider requires several components:

    • Resource: The resource to be associated with the log records created by the loggers. You defined this in the second step.
    • LogRecord Processor: A component that manages the log records generated by the loggers and forwards them to a LogExporter. The exporter should be configured to direct data to an endpoint designated for logs.
    • Log Exporter: Manages the transmission of log records to the Collector.

    For this step, you need the following dependencies:

    • @opentelemetry/api-logs: This package contains the logs API. This API is not yet included in the generic API package because logs are still experimental.
    • @opentelemetry/sdk-logs: This package contains all the required components to set up logs.
    • @opentelemetry/exporter-logs-otlp-http: This package contains the exporter for the HTTP/JSON protocol.

    To install the dependencies, run the following command:

    npm install @opentelemetry/api-logs @opentelemetry/sdk-logs @opentelemetry/exporter-logs-otlp-http
    		

    After the dependencies are installed, configure and register a LoggerProvider with the following code:

  6. Register the instrumentations

    The final step for setting up Real User Monitoring (RUM) through OpenTelemetry is registering the instrumentations. Instrumentations are modules that automatically capture telemetry data, like network requests or DOM interactions, by using the OpenTelemetry API.

    With the OpenTelemetry SDK, resource attributes, and exporters already configured, all telemetry data generated by these registered instrumentations is automatically processed and exported.

    Install the following dependencies:

    • @opentelemetry/instrumentation: This package contains the core components of instrumentations along with some utilities.
    • @opentelemetry/auto-instrumentations-web: This package contains the more common instrumentations for web apps. Which are:
      • @opentelemetry/instrumentation-document-load: This instrumentation package measures the time it took the document to load and also the load timings of its resources. More info at instrumentation-document-load.
      • @opentelemetry/instrumentation-fetch: This instrumentation keeps track of your web application requests made through the Fetch API. More info at instrumentation-fetch.
      • @opentelemetry/instrumentation-xml-http-request: This instrumentation keeps track of your web application requests made through the XMLHttpRequest API. More info at instrumentation-xml-http-request.
      • @opentelemetry/instrumentation-user-interaction: This instrumentation measures user interactions in your web application. More info at instrumentation-user-interaction.
    • @opentelemetry/instrumentation-long-task: This instrumentation is not part of the auto instrumentations package. It gathers information about long tasks being executed in your browser, helping to spot issues like unresponsive UI in your web application. More info at instrumentation-long-task.

    To install the dependencies, run the following command:

    npm install @opentelemetry/instrumentation\
          @opentelemetry/auto-instrumentations-web\
          @opentelemetry/instrumentation-long-task
    		

    After the dependencies are installed, configure and register instrumentations with the following code:

  7. Complete the setup script

    All these pieces together give you a complete setup of all the signals for your web site or application. For convenience, it's better to have it in a separate file which can be named, for example, telemetry.js. This file should export a function that accepts the configuration allowing you to reuse the setup across different UIs.

    To install all the dependencies needed for the complete setup, run the following command:

    After the dependencies are installed, you can wrap the setup in a function with the following code:

With the setup script in a single file, you can now apply it to your web application. You can choose from two main approaches:

  1. Import the code: Use your build tooling to manage the dependencies and integrate the code into the application bundle. This is the simplest option and is recommended, although it increases the size of your application bundle.

  2. Bundle in a file: Use a bundler to generate a separate JavaScript file that you include in the <head> section of your HTML page. This approach keeps the telemetry code separate from your application bundle.

This approach is recommended, especially if you're using a web framework. The build tooling manages the dependencies and integrates the code into the application bundle. However, this approach increases the size of your application bundle.

For example, if you're using Webpack, you can import the code like this:

If you're using a framework, there are some suitable places for it, depending on which one you're using:

Framework Method
React Create a component which initializes the instrumentation when mounted. The component should be added as child of the <App/> component.
VueJs Create a plugin which does the initialization when installed in the app. Refer to the VueJS docs for more details.
Angular Add the initialization snippet in ./src/main.ts which is the entry point of the application. Refer to the Angular docs for more details.

You can use a bundler like Webpack, Rollup, or Vite to generate a separate JavaScript file.

This is an example of a webpack.config.js to author a library as described in the Webpack documentation in UMD format.

This is an example of a vite.config.js file in library mode to get a bundle in UMD format.

Place the file within the application's assets folder and include it in the <head> section of the HTML page. Assuming the files are in a folder named js you can load the telemetry file in a synchronous or asynchronous way.

By using the OpenTelemetry API directly, you can send highly specific, custom telemetry to augment automatic collection. This custom instrumentation allows you to:

  • Create explicit spans around unique critical business logic or user interactions (for example, complex calculations, multi-step forms) for granular detail.
  • Generate high-fidelity logs that directly correlate with the flow of a trace for better debugging.
  • Record application-specific KPIs not covered by standard RUM metrics (for example, UI component render counts, client-side transaction success rates).

With the instrumentations configured in the previous section, a span is generated for each request, each part of a separate trace, meaning they're treated as independent operations. While this provides a clear breakdown of each individual request, you might need to consolidate multiple related requests within a single, cohesive trace.

An example is a recurring task that updates the user interface at regular intervals to display various datasets that fluctuate over time. Grouping all the API calls necessary for a single UI refresh into one trace allows you to view the overall performance and flow of the entire update cycle.

By using the startActiveSpan callback mechanism, you can wrap the asynchronous data fetching logic within a dedicated active trace.

Relevant events occurring within your application can be recorded using a logger. A typical scenario involves documenting business-critical occurrences, such as conversions or purchases.

Review the following constraints in your web application to avoid any data transmission issues.

If your website is making use of Content Security Policies (CSPs), make sure that the domain of your OTLP endpoint is included. If your Collector endpoint is https://collector.example.com:4318/v1/traces, add the following directive:

connect-src collector.example.com:4318/v1/traces
		

If your website and the configured endpoint have a different origin, your browser might block the export requests. If you followed the instructions in the OTLP endpoint section, you already set up the necessary CORS headers. Otherwise you need to configure special headers for CORS in the receiving endpoint.

These are the known limitations of using OpenTelemetry for RUM with Elastic Observability:

  • Metrics from browser-based RUM might have limited utility compared to backend metrics.
  • Some OpenTelemetry instrumentations for browsers are still experimental.
  • Performance impact on the browser should be monitored, especially when using multiple instrumentations.
  • Authentication using API keys requires special handling in the reverse proxy configuration.

This section provides solutions to common issues you might encounter when setting up OpenTelemetry for RUM with Elastic Observability.

If you continue to experience issues:

  1. Ensure your target browsers support the OpenTelemetry features you're using.
  2. Consult the OpenTelemetry JavaScript documentation for additional troubleshooting guidance.
  3. Set the log level to verbose for maximum detail:
const OTEL_LOG_LEVEL = 'verbose';
		
  1. Start with only traces (no metrics or logs) and one instrumentation to isolate the issue.
  2. Review the code examples throughout this guide and compare with your implementation.