The New RUM Experience provides gapless end-to-end visibility by linking RUM data with the distributed traces captured on your application's backend. This connection lets you analyze performance and errors from frontend to backend. Two mechanisms are used, depending on the frontend and request type:
Server-Timing response header is used on web frontends for the requests for the HTML document and its included resources, because the RUM JavaScript can't add request headers to these requests. The header also serves as a fallback when the W3C trace context isn't added.The RUM JavaScript adds the trace context on web frontends, and the OneAgent for Mobile adds it on mobile frontends. The trace context consists of two request headers:
traceparent header provides the trace and span IDs to identify the request as part of a distributed trace.tracestate header carries additional Dynatrace-specific context in the dtr entry.For example:
traceparent: 00-5b9e8443aa84b5cb5c329fbd8dc9a520-97039bf817c8584a-01tracestate: 2ead957c-980df25b@dtr=1;97039bf817c8584a;1;745a78fe5b6e57f6;1777270045450K7QJCFPI7NLPJ913DJBJK2MLMAS2UG2F;VAELUWHBCWKLNEOKJHEPMSKMITTKOBUT-0
If your frontend already sets a trace context, the existing traceparent is preserved, and the tracestate is augmented with the dtr entry.
Both headers must be forwarded unchanged across all services and intermediaries, such as reverse proxies, API gateways, and OpenTelemetry Collectors. If the traceparent or the Dynatrace dtr entry in tracestate is removed or altered, frontend-backend linking either fails entirely or works only partially.
When the trace context is set successfully, RUM populates the trace.id and span.id fields on the corresponding request event, which are used to link to the backend trace. For details, see RUM span and trace fields.
The RUM JavaScript doesn't add the trace context to cross-origin XHRs and Fetch requests by default, because doing so would cause CORS errors. You need to configure your endpoints to set the required CORS headers before the trace context can be added. For instructions, see Add the W3C trace context to cross-origin requests.
If you use a custom networking stack on your mobile frontend, you need to propagate the trace context manually. For instructions and examples, see Android, iOS, or .NET MAUI.
OneAgent version 1.331+
For web frontends, the requests for the HTML document and its included resources can't carry a W3C trace context, because the RUM JavaScript can't add request headers to these requests. Instead, frontend-backend linking is established through the Server-Timing response header.
The Server-Timing response header is added by the OneAgent technologies listed in Technology support – Real User Monitoring – Web servers and applications. Therefore, frontend-backend linking for the HTML document and its included resources can only be achieved for these technologies. This approach isn't supported for backends instrumented with OpenTelemetry, because the Server-Timing header is added by OneAgent.
The Server-Timing header contains a comma-separated list of entries, and a single response can include more than one Server-Timing header field. Dynatrace RUM adds the following three entries:
dtTrId—the trace IDdtSInfo—sampling informationdtRpid—the (proprietary) response ID, which is required for RUM Classic correlationFor example:
Server-Timing: dtTrId;desc="2fdcef91d451fdffd6e5e36abc6bb609", dtSInfo;desc="0"Server-Timing: dtRpid;desc="-609157671"
The RUM JavaScript evaluates the header via the PerformanceServerTiming API and populates the trace.id field on the corresponding request event, which is used to link to the backend trace. It also populates trace.is_sampled to indicate whether the trace was sampled. For details, see RUM span and trace fields.
For cross-origin requests, the RUM JavaScript can access the Server-Timing header value only if the response includes a Timing-Allow-Origin header that permits the request's origin. To grant this access, OneAgent automatically adds a Timing-Allow-Origin header to your web application's response if your application doesn't already set one. By default, the added header uses a wildcard (*) value.
If this permissive default doesn't meet your requirements, you can define rules that restrict which origins receive these two headers. For details, see Control the addition of the Server-Timing and Timing-Allow-Origin headers in cross-origin scenarios.
To help you diagnose issues with frontend-backend linking, RUM adds two hint fields to each request event:
request.trace_context_hint indicates whether and why the W3C trace context headers were set on the request. It is added by the RUM JavaScript and the OneAgent for Mobile.request.server_timing_hint indicates whether and why the Server-Timing header was available on the response. It is added by the RUM JavaScript.For possible values, see RUM request trace context hint fields.