How to Achieve End-to-End Traceability with RUM and OpenTelemetry

Background

With the continuous evolution of observability technologies, most enterprises have adopted APM, tracing, and logging solutions. In the internet industry, product experience directly influences user reputation and market success, making Real User Monitoring (RUM) increasingly important. The key challenge is correlating RUM data with backend APM and tracing data when backend failures cause user‑side issues such as app white‑screens or slow page loads.

Challenges of End-to-End Traceability

Complex technical architecture with multi‑endpoint, multi‑language, and multi‑team scenarios.

High integration cost requiring cooperation among front‑end, back‑end, middleware, and operations teams.

After traceability is achieved, linking RUM, APM, and logging data for root‑cause analysis and impact assessment remains difficult.

Incompatible propagation protocols across tracing systems (e.g., OpenTelemetry vs. SkyWalking).

Trace Propagation Protocols

OpenTelemetry: W3C trace‑parent / trace‑state.

SkyWalking: sw8 (v3) protocol.

Zipkin: B3 / B3‑multi.

Jaeger: Jaeger protocol.

Because different tracing projects define their own propagation formats, a full call chain requires all components to use the same or compatible protocol and to forward the protocol headers through gateways and proxies.

W3C Trace Context

The W3C Trace Context specification defines two HTTP headers, traceparent and tracestate, to carry trace information across processes and protocols.

traceparent: {version}-{trace-id}-{parent-id}-{trace-flags}

tracestate: {vendor1Key}={vendor1Value},{vendor2Key}={vendor2Value},...

Propagator Mapping

OpenTelemetry supports most propagation protocols except SkyWalking’s sw8. The compatibility matrix can be summarised as:

OpenTelemetry: supports tracecontext, b3, b3multi, jaeger, opentracing.

SkyWalking: only supports its own sw8 protocol.

Zipkin: supports b3 and b3multi.

Jaeger: supports tracecontext, b3, b3multi.

RUM Integration Best Practices

RUM can generate a TraceID on the client side and propagate it via HTTP headers, allowing back‑end services to initialise and continue the trace.

Integrating RUM with tracing avoids the need to embed open‑source SDKs in the client, reduces integration cost, and enables one‑stop monitoring for multi‑domain applications.

Two Integration Approaches

Approach 1: RUM → Span

Collect RUM data on the client, transmit the trace context using the chosen propagation protocol, and convert RUM events into standard Trace Span data on the back‑end. User, session, and view information are injected into Span attributes, enabling seamless correlation between user‑side metrics and back‑end traces.

Approach 2: Span → RUM

Deploy the OpenTelemetry SDK on the client, then use a custom exporter in the OTel Collector to transform Span data into RUM events. Alternatively, run both RUM and OTel SDKs side‑by‑side and use an OTel SpanProcessor to emit RUM events, as done by the open‑source Sentry RUM implementation.

Practical Applications

Full‑Link Insight: After linking RUM and tracing, teams can view the complete user‑to‑service path, quickly narrow down failure domains, and assess user impact without switching tools.

Impact Analysis: When a back‑end outage occurs, RUM records all user actions during the incident, and combined with trace data it reveals which requests, devices, carriers, or regions are affected, helping prioritize remediation.

Conclusion

The article presents an end‑to‑end solution built on OpenTelemetry and the W3C Trace Context protocol, and shares best practices for integrating RUM into full‑stack observability. By unifying user‑side monitoring with back‑end tracing, organisations gain powerful capabilities such as root‑cause localisation, impact assessment, and even session replay for hard‑to‑reproduce production issues.