All Products
Search
Document Center

Application Real-Time Monitoring Service:Correlate frontend and backend traces

Last Updated:May 08, 2026

ARMS RUM lets you start from a user session to track errors, slow performance, and anomalies during user interactions. By integrating with ARMS Application Monitoring, it provides end-to-end analysis, enabling a complete path for problem diagnosis. This topic describes how to correlate frontend and backend traces for web monitoring.

Prerequisites

  • Ensure that your frontend application (including web and mini-programs) is integrated with RUM. For details, see Integrate a Web & H5 Application and Integrate a Mini Program.

  • Ensure that your backend application is integrated with ARMS Application Monitoring or Managed Service for OpenTelemetry. For more information, see Integration Guide.

  • Ensure that your backend application provides an HTTP web service capable of parsing trace context from request headers.

Important

Cross-region correlation between frontend and backend applications is no longer supported. If your frontend and backend applications are in different regions, go to the CloudMonitor Console and integrate your frontend application in the same region and workspace as your backend application.

Supported trace protocols

RUM trace correlation currently supports the following mainstream trace context propagation protocols:

  • w3c: Includes OpenTelemetry clients and ARMS agents.

  • b3/b3multi: Zipkin

  • Jaeger

  • sw8: SkyWalking

Enable RUM trace correlation

When you integrate the RUM agent with your frontend application, enable the Tracing configuration option.

Important

Enabling RUM trace correlation generates additional trace data, which may affect the billing for your Application Monitoring or Managed Service for OpenTelemetry service.

CDN sync

Simple mode

Important

This method is recommended for browsers only. As mini-programs lack the concept of same-origin requests, you must use Complete Mode and configure allowedUrls.

This mode is typically used for same-origin requests where the backend uses the OpenTelemetry standard by default. The allowedUrls type is undefined, but same-origin requests are automatically allowed.

<script>
  window.__rum = {
    pid: "<your pid>",
    endpoint: "<your endpoint>",
    //... Other configuration options are omitted here.
    // Tracing configuration switch, disabled by default.
    tracing: true // Equivalent to { enable: true,  sample: 100, tracestate: true, allowedUrls:[], baggage: false }
  };
</script>
<script type="text/javascript" src="https://sdk.rum.aliyuncs.com/v2/browser-sdk.js " crossorigin></script>

Complete mode

Provides full control over all configuration settings. The allowedUrls type is Array<TraceOption>.

<script>
  window.__rum = {
    pid: "<your pid>",
    endpoint: "<your endpoint>",
    //... Other configuration options are omitted here.
    // Tracing configuration switch, disabled by default.
    tracing: {
      enable: true, // Enables tracing. Disabled by default.
      sample: 60, // Sampling rate: 60%. Default: 100%.
      tracestate: true, // Enables tracestate propagation. Enabled by default.
      baggage: false, // Disables baggage propagation. Disabled by default.
      allowedUrls:[
        {match: 'https://api.aliyun.com', propagatorTypes:['tracecontext', 'b3']}, // Match URLs starting with 'https://api.aliyun.com'. Propagators: tracecontext, b3.
        {match: /api\.alibaba\.com/i, propagatorTypes:['b3multi']}, // RegExp match for URLs containing 'api.alibaba.com'. Propagator: b3multi.
        {match: (url)=>url.includes('.api'), propagatorTypes:['jaeger']}, // Function match for URLs containing '.api'. Propagator: Jaeger.
      ]
    }
  };
</script>
<script type="text/javascript" src="https://sdk.rum.aliyuncs.com/v2/browser-sdk.js " crossorigin></script>

CDN async

Simple mode

Important

This method is recommended for browsers only. As mini-programs lack the concept of same-origin requests, you must use Complete Mode and configure allowedUrls.

This mode is typically used for same-origin requests where the backend uses the OpenTelemetry standard by default. The allowedUrls type is undefined, but same-origin requests are automatically allowed.

<script>
  !(function(c,b,d,a){c[a]||(c[a]={});c[a].config=
    {
      pid: "<your pid>",
      endpoint: "<your endpoint>",
      //... Other configuration options are omitted here.
      // Tracing configuration switch, disabled by default.
      tracing: true
    }
   with(b)with(body)with(insertBefore(createElement("script"),firstChild))setAttribute("crossorigin","",src=d)
  })(window,document,"https://sdk.rum.aliyuncs.com/v1/bl.js","__bl");
</script>
Complete mode

Provides full control over all configuration settings. The allowedUrls type is Array<TraceOption>.

<script>
  !(function(c,b,d,a){c[a]||(c[a]={});c[a].config=
    {
      pid: "<your pid>",
      endpoint: "<your endpoint>",
      //... Other configuration options are omitted here.
      // Tracing configuration switch, disabled by default.
      tracing: {
        enable: true, // Enables tracing. Disabled by default.
        sample: 100, // Sampling rate. Default: 100%.
        tracestate: true, // Enables tracestate propagation. Enabled by default.
        baggage: true, // Enables baggage propagation. Disabled by default.
        allowedUrls:[
          {match: 'https://api.aliyun.com', propagatorTypes:['tracecontext', 'b3']}, // Match URLs starting with 'https://api.aliyun.com'. Propagators: tracecontext, b3.
          {match: /api\.alibaba\.com/i, propagatorTypes:['b3multi']}, // RegExp match for URLs containing 'api.alibaba.com'. Propagator: b3multi.
          {match: (url)=>url.includes('.api'), propagatorTypes:['jaeger']}, // Function match for URLs containing '.api'. Propagator: Jaeger.
        ]
      }
    }
    with(b)with(body)with(insertBefore(createElement("script"),firstChild))setAttribute("crossorigin","",src=d)
   })(window,document,"https://sdk.rum.aliyuncs.com/v1/bl.js","__bl");
</script>

NPM package

Simple mode

Important

This method is recommended for browsers only. As mini-programs lack the concept of same-origin requests, you must use Complete Mode and configure allowedUrls.

This mode is typically used for same-origin requests where the backend uses the OpenTelemetry standard by default. The allowedUrls type is undefined, but same-origin requests are automatically allowed.

import ArmsRum from '@arms/rum-browser';

ArmsRum.init({
  pid: 'your pid',
  endpoint: 'your endpoint',
  //... Other configuration options are omitted here.
  // Tracing configuration switch, disabled by default.
  tracing: true, // Equivalent to { enable: true,  sample: 100, tracestate: true, allowedUrls:[], baggage: false }
});
Complete mode

Provides full control over all configuration settings. The allowedUrls type is Array<TraceOption>.

import ArmsRum from '@arms/rum-browser';

ArmsRum.init({
  pid: "your pid",
  endpoint: "your endpoint",
  //... Other configuration options are omitted here.
  tracing: {
    enable: true, // Enables tracing. Disabled by default.
    sample: 100, // Sampling rate. Default: 100%.
    tracestate: true, // Enables tracestate propagation. Enabled by default.
    baggage: true, // Enables baggage propagation. Disabled by default.
    allowedUrls:[
      {match: 'https://api.aliyun.com', propagatorTypes:['tracecontext', 'b3']}, // Match URLs starting with 'https://api.aliyun.com'. Propagators: tracecontext, b3.
      {match: /api\.alibaba\.com/i, propagatorTypes:['b3multi']}, // RegExp match for URLs containing 'api.alibaba.com'. Propagator: b3multi.
      {match: (url)=>url.includes('.api'), propagatorTypes:['jaeger']}, // Function match for URLs containing '.api'. Propagator: Jaeger.
    ]
  }
});

Tracing parameters

Parameter

Type

Default

Description

tracing.enable

Boolean

true

If you specify a non-Boolean value, it is reset to true.

tracing.sample

Number

100

The value must be in the range of [0, 100]. Values outside this range are reset to 100.

tracing.tracestate

Boolean

true

Enabled by default. This parameter is effective only in W3C tracecontext mode, as other modes do not use the tracestate header.

If set to false, the tracestate request header is not included in W3C mode.

tracing.baggage

Boolean

false

When tracing is enabled, RUM includes the baggage header with relevant information in requests, regardless of the tracing standard.

tracing.propagatorTypes

PropagatorType | PropagatorType[]

null

Specifies the propagation standard for the current trace.

Note:

  • If propagatorTypes is configured in allowedUrls, this setting is overridden.

  • If the configuration includes sw8, all other types are ignored, and only the sw8 standard is used.

tracing.allowedUrls

Array<MatchOption | TraceOption> | undefined

undefined

Specifies the request URLs for which tracing is enabled.

  1. In browsers, same-origin requests are allowed by default. For cross-domain requests, you must configure allowedUrls.

  2. In mini-programs, you must configure allowedUrls for tracing to take effect.

In browsers, the following rule is added to tracing.allowedUrls:

{
  match: (url) => (/^https?:\/\/*/.test(url) || startsWith(url, location.origin)),
  propagatorTypes: ['tracecontext']
}

MatchOption

type MatchOption = string | RegExp | ((value: string) => boolean);

allowedUrls matches the full URL. It accepts the following types:

  • string: Matches any URL that starts with the specified value. For example, https://api.aliyun.com matches https://api.aliyun.com/v1/resource.

  • RegExp: Uses the provided regular expression to test the URL.

  • function: Executes a function with the URL as a parameter. A return value of true indicates a match.

PropagatorType

By default, tracecontext is used for OpenTelemetry-based tracing.

type PropagatorType = 'tracecontext' | 'b3' | 'b3multi' | 'jaeger' | 'sw8';

The following table lists the request headers propagated by each trace protocol.

Propagation format

Format

tracecontext

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

tracestate: rum={version}&{appType}&{pid}&{sessionId}

b3

b3: {TraceId}-{SpanId}-{SamplingState}-{ParentSpanId}

b3multi

X-B3-TraceId: {TraceId}

X-B3-SpanId: {SpanId}

X-B3-ParentSpanId: {ParentSpanId}

X-B3-Sampled: {SamplingState}

Jaeger

uber-trace-id : {trace-id}:{span-id}:{parent-span-id}:{flags}

sw8

sw8: {sample}-{trace-id}-{segment-id}-{0}-{service}-{instance}-{endpoint}-{peer}

Important

The request headers passed through by the protocols mentioned above are not standard HTTP request headers and are not on the CORS safelist (also known as CORS-safelisted request-headers). Therefore, when your website or application makes cross-domain requests (especially in scenarios such as mini programs), you must explicitly specify these headers in the server-side Access-Control-Allow-Headers. Otherwise, cross-domain requests will be blocked by the browser due to the CORS policy.

Verify RUM trace correlation

Web and H5

  1. Visit your website or Web H5 page.

  2. Open your browser's developer tools and switch to the Network tab.

  3. Inspect an API request initiated by the frontend (type: XHR/Fetch) and check if its request headers contain the corresponding propagation protocol header.

Mini programs

  1. Run the mini-program in the developer simulator.

  2. Open the developer tools debugger and switch to the Network tab.

  3. Check if the request headers of a request initiated by the mini-program contain the corresponding propagation protocol header.

Configure backend trace correlation

To enable complete end-to-end tracing, you must also configure your backend application. The following backend application types and integration methods are supported.

Java applications

ARMS agent

The ARMS Application Monitoring agent has built-in support for the OpenTelemetry protocol, so no additional configuration is required to correlate with RUM traces. However, you must ensure the following:

  • Supported ARMS Application Monitoring agent versions: 2.x, 3.x, and 4.x. For a better experience, we recommend upgrading to version 4.x.

  • The agent supports mainstream web containers such as Tomcat, Jetty, WebLogic, and Undertow, and frameworks such as Spring Boot and Spring MVC. For a complete list of supported components and frameworks, see Java Components and Frameworks Supported by Application Monitoring.

For instructions on how to integrate the ARMS Application Monitoring agent, see Start Monitoring a Java Application.

OpenTelemetry

You can integrate your application with ARMS (Managed Service for OpenTelemetry) by using OpenTelemetry. Two methods are available: auto instrumentation and manual instrumentation.

  • For auto instrumentation, OpenTelemetry already supports most mainstream frameworks. No extra configuration is needed to correlate with RUM traces.

    Note

    For a list of Java frameworks supported by OpenTelemetry, see Report Java Application Data by Using OpenTelemetry.

  • For manual instrumentation, you must use the extension mechanism provided by the OpenTelemetry SDK to correlate with RUM traces. This involves parsing the trace context from the frontend request headers (traceparent, tracestate). The following is a code sample for a Spring Boot scenario:

    1. Add the OpenTelemetry dependencies.

      <dependency>
        <groupId>io.opentelemetry</groupId>
        <artifactId>opentelemetry-api</artifactId>
      </dependency>
      <dependency>
        <groupId>io.opentelemetry</groupId>
        <artifactId>opentelemetry-sdk-trace</artifactId>
      </dependency>
      <dependency>
        <groupId>io.opentelemetry</groupId>
        <artifactId>opentelemetry-extension-annotations</artifactId>
        <version>1.18.0</version>
      </dependency>
      <dependency>
        <groupId>io.opentelemetry</groupId>
        <artifactId>opentelemetry-exporter-otlp</artifactId>
      </dependency>
      <dependency>
        <groupId>io.opentelemetry</groupId>
        <artifactId>opentelemetry-sdk</artifactId>
      </dependency>
      <dependency>
        <groupId>io.opentelemetry</groupId>
        <artifactId>opentelemetry-semconv</artifactId>
        <version>1.30.1-alpha</version>
      </dependency>
      <dependency>
        <groupId>io.opentelemetry</groupId>
        <artifactId>opentelemetry-sdk-extension-autoconfigure</artifactId>
        <version>1.34.1</version>
      </dependency>
      <dependency>
        <groupId>io.opentelemetry</groupId>
        <artifactId>opentelemetry-extension-incubator</artifactId>
        <version>1.35.0-alpha</version>
      </dependency>
    2. Add the W3C Propagator during OpenTelemetry initialization.

      Resource resource = Resource.getDefault()
              .merge(Resource.create(Attributes.of(
                      ResourceAttributes.SERVICE_NAME, "otel-demo",
                      ResourceAttributes.HOST_NAME, "xxxx"
      )));
      
      SdkTracerProvider sdkTracerProvider = SdkTracerProvider.builder()
              .addSpanProcessor(BatchSpanProcessor.builder(OtlpHttpSpanExporter.builder()
                      .setEndpoint("Your Endpoint")
                      .addHeader("Authentication", "Your Token")
                      .build()).build())
              .setResource(resource)
              .build();
      
      openTelemetry = OpenTelemetrySdk.builder()
              .setTracerProvider(sdkTracerProvider)
              // Add the W3C Propagator here.
              .setPropagators(ContextPropagators.create(
                      TextMapPropagator.composite(W3CTraceContextPropagator.getInstance(), W3CBaggagePropagator.getInstance()))
               ).buildAndRegisterGlobal();
      // Use the extended Tracer here.
      tracer = ExtendedTracer.create(openTelemetry.getTracer("com.example.tracer", "1.0.0"));
    3. In your controller method, add a headers parameter and parse the trace context from the request headers to set the parent.

      // Add a request header parameter to the Controller to parse the trace context.
      @RequestMapping("/test")
      public String test(@RequestHeader Map<String, String> headers) {
          Span span = OpenTelemetrySupport.getTracer()
                  .spanBuilder("/test")
                  // Parse the parent span from the headers.
                  .setParentFrom(OpenTelemetrySupport.getContextPropagators(), headers)
                  .setSpanKind(SpanKind.SERVER)
                  .startSpan();
          try (Scope scope = span.makeCurrent()) {
              // do something
          } catch (Throwable t) {
              span.setStatus(StatusCode.ERROR, "handle parent span error");
          } finally {
              span.end();
          }
          return "success";
      }

Jaeger

Jaeger provides two methods for web scenarios: manual instrumentation and instrumentation with a Spring Cloud component. For complete integration instructions, see Report Java Application Data by Using Jaeger.

  • If you use instrumentation with a Spring Cloud component, no extra configuration is needed to correlate with RUM traces.

  • For manual instrumentation, you need to parse the trace context from the frontend request header. See the code below.

    1. Add the dependency.

      <dependency>
        <groupId>io.jaegertracing</groupId>
        <artifactId>jaeger-client</artifactId>
        <version>Latest Version</version> <!-- Make sure to use the latest Jaeger version. -->
      </dependency>
    2. Initialize the Tracer.

      Replace <endpoint> with the endpoint for the corresponding client and region from the Cluster Configurations > Endpoint Information page in the Managed Service for OpenTelemetry console.

      // Replace manualDemo with your application name.
      io.jaegertracing.Configuration config = new io.jaegertracing.Configuration("manualDemo");
      io.jaegertracing.Configuration.SenderConfiguration sender = new io.jaegertracing.Configuration.SenderConfiguration();
      // Replace <endpoint> with the endpoint for the corresponding client and region from the console overview page.
      sender.withEndpoint("<endpoint>");
      config.withSampler(new io.jaegertracing.Configuration.SamplerConfiguration().withType("const").withParam(1));
      config.withReporter(new io.jaegertracing.Configuration.ReporterConfiguration().withSender(sender).withMaxQueueSize(10000));
      GlobalTracer.register(config.getTracer());
    3. Create a span in your business interface. You can refer to the following code to correlate the trace.

      // Add a request header parameter to the Controller to parse the trace context.
      @RequestMapping("/test")
      public String test(@RequestHeader Map<String, String> headers) {
          Tracer tracer = GlobalTracer.get();
          SpanContext parentCtx = tracer.extract(Format.Builtin.HTTP_HEADERS, new TextMapAdapter(headers));
          Span span;
          if (parentCtx != null) {
              span = tracer.buildSpan("/test").asChildOf(parentCtx).start();
          } else {
              span = tracer.buildSpan("/test").start();
          }
          try (Scope ignored = tracer.activateSpan(span)) {
              tracer.activeSpan().setTag("methodName", "test");
              // do something
          } catch (Throwable t) {
              TracingHelper.onError(e, span);
              throw e
          } finally {
              span.finish();
          }
          return "success";
      }

Zipkin

For complete integration instructions, see Report Java Application Data by Using Zipkin.

Follow the integration instructions in the document, then parse the context from the request header in your server-side code to correlate with the RUM trace.

// Extract the context from the request header.
extractor = tracing.propagation().extractor(Request::getHeader);

// convert that context to a span which you can name and add tags to
oneWayReceive = nextSpan(tracer, extractor.extract(request))
.name("process-request")
.kind(SERVER)
... add tags etc.

// start the server side and flush instead of finish
oneWayReceive.start().flush();

// you should not modify this span anymore as it is complete. However,
// you can create children to represent follow-up work.
next = tracer.newSpan(oneWayReceive.context()).name("step2").start();

SkyWalking

For complete integration instructions, see Java Agent Plugin.

SkyWalking integration is handled by a Java agent. You only need to follow the instructions in the document to correlate RUM and backend traces.

To ensure protocol compatibility with RUM, the sw8 (v3) protocol corresponds to the SkyWalking 8.x agent.

Go applications

OpenTelemetry

For complete integration instructions, see Report Go Application Data by Using OpenTelemetry.

Follow the integration instructions, then generate a span from the request context in the HTTP request handler to correlate with the RUM trace.

// Initialize the tracer.
tracer := otel.Tracer(common.TraceInstrumentationName)
// Generate a span from the request context.
handler := http.HandlerFunc(func(w http.ResponseWriter, req *http.Request) {
    ctx := req.Context()
    span := trace.SpanFromContext(ctx)
    // do something
    w.Write([]byte("Hello World"))
})

Jaeger

For complete integration instructions, see Report Go Application Data by Using Jaeger.

Follow the integration instructions, then parse the span context from the HTTP request header to correlate with the RUM trace. See the code below.

// Extract spanCtx from the HTTP object.
spanCtx, _ := tracer.Extract(opentracing.HTTPHeaders, opentracing.HTTPHeadersCarrier(r.Header))
span := tracer.StartSpan("myspan", opentracing.ChildOf(spanCtx))
...
defer  span.Finish()

Zipkin

For complete integration instructions, see Report Go Application Data by Using Zipkin.

Follow the integration instructions, then parse the span context from the HTTP request header to correlate with the RUM trace. See the code below.

// Initialize the tracer.
tracer, err := exampletracer.NewTracer("go-frontend", frontendPort)
// Generate a span from the request context.
router.Methods("GET").Path("/").HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
    // retrieve span from context
	span := zipkin.SpanFromContext(r.Context())
    // add some tag
    span.Tag("some_key", "some_value")
    // do something...
	span.Annotate(time.Now(), "some_event")
})

SkyWalking

For complete integration instructions, see Report Go Application Data by Using SkyWalking.

Follow the integration instructions. We recommend using the skywalking-go integration method, which supports mainstream web frameworks such as gin, go-restful, http, go-kratos v2, go-micro, and go-resty, and correlates with RUM traces without requiring code changes.

If you want to manually parse the trace context from the HTTP request header, you can also use the following code:

//Extract context from the HTTP request header `sw8`.
span, ctx, err := tracer.CreateEntrySpan(r.Context(), "/api/test", func(key string) (string, error) {
		return r.Header.Get(key), nil
})

Python applications

OpenTelemetry

For complete integration instructions, see Report Python Application Data by Using OpenTelemetry.

Follow the integration instructions, then parse the span context from the HTTP request header to correlate with the RUM trace. See the code below.

# Initialize the tracer.
trace.set_tracer_provider(TracerProvider())
trace.get_tracer_provider().add_span_processor(BatchSpanProcessor(ConsoleSpanExporter()))

tracer = trace.get_tracer(__name__)

@app.route('/test')
def test():
    headers = dict(request.headers)

    # Extract the trace context from the headers.
    carrier ={'traceparent': headers['Traceparent'], 'tracestate': headers['Tracestate']}
    ctx = TraceContextTextMapPropagator().extract(carrier=carrier)

    with tracer.start_span("test", context=ctx):
        # do something
        return "success"

Jaeger

For complete integration instructions, see Report Python Application Data by Using Jaeger.

Follow the integration instructions, then parse the span context from the HTTP request header to correlate with the RUM trace. See the code below.

import logging
from flask import Flask
from jaeger_client import Config
from opentracing.ext import tags
from opentracing.propagation import Format

# Initialize the tracer.
def init_tracer(service, scope_manager=None):
    logging.getLogger('').handlers = []
    logging.basicConfig(format='%(message)s', level=logging.DEBUG)

    config = Config(
        config={
            'sampler': {
                'type': 'const',
                'param': 1,
            },
            'logging': True,
            'reporter_batch_size': 1,
        },
        service_name=service,
        scope_manager=scope_manager
    )
    return config.initialize_tracer()

# The trace decorator.
def trace(tracer, span_name):
    def decorator(f):
        @functools.wraps(f)
        def wrapped(*args, **kwargs):
            # Extract the trace context from headers.
            span_ctx = tracer.extract(Format.HTTP_HEADERS, request.headers)
            span_tags = {tags.SPAN_KIND: tags.SPAN_KIND_RPC_SERVER}

            with tracer.start_active_span(span_name, child_of=span_ctx, tags=span_tags) as scope:
                rv = f(*args, **kwargs)

            return rv
        return wrapped
    return decorator

# API test example.
@app.route('/test')
@trace(tracer, 'test')
def test():
    return "success"

SkyWalking

For complete integration instructions, see Report Python Application Data by Using SkyWalking.

Follow the integration instructions, then parse the span context from the HTTP request header to correlate with the RUM trace. See the code below.

from skywalking import config, agent
from skywalking.trace.context import SpanContext, get_context
from skywalking.trace.carrier import CarrierItem

# Configure SkyWalking. Adjust parameters as needed.
config.init(agent_collector_backend_services='<endpoint>',
            agent_authentication='<auth-token>')

agent.start()

# Example HTTP request handler. Pass the HTTP request headers.
def handle_request(headers):
    # Extract trace information from the request headers.
    carrier_items = []
    for item in SpanContext.make_carrier():
        carrier_header = headers.get(item.key.lower())
        if carrier_header:
            carrier_items.append(CarrierItem(item.key, carrier_header))

    carrier = SpanContext.make_carrier(carrier_items)

    # Extract the trace context from the Carrier.
    context = get_context().extract(carrier)
    
    # Create a new span to handle the request.
    with get_context().new_entry_span(op='operation_name') as span:
        # Handle the request here. The span is submitted automatically when finished.
        ...

# Simulate received HTTP headers containing sw8.
incoming_headers = {
    'sw8': '1-My40LjU=-MTY1MTcwNDI5OTk5OA==-xxxx-xx-x-x==',  # Example value. Use the actual value from the request.
    # other headers...
}

# Call the function to handle the request.
handle_request(incoming_headers)

View end-to-end trace data

After correlating the frontend and backend traces, you can view the complete end-to-end traces for frontend requests in the ARMS RUM console.

In the ARMS RUM console, go to the API Requests tab. In the API request list, find the View Trace link in the Actions column.

Click View Trace to see the complete trace and application topology. You can then analyze slow or erroneous requests by combining the RUM request details with the backend trace data.

This opens the API Request Details page. The left side lists the requests. On the right, switch to the Tracing > Trace Details tab to view a waterfall chart. This chart shows the call sequence and latency of each service, from the browser (rum-browser), through the ingress and frontend (Node.js), to the backend (Java).

The top-level span represents the RUM entry span. Its name varies based on the client integration type:

  • Web & H5: Application name is rum-browser, span name prefix is "browser.request:".

  • Mini-programs: Application name is rum-miniapp, span name prefix is "miniapp.request:".

  • Android: Application name is rum-android, span name prefix is "android.request:".

  • iOS: Application name is rum-ios, span name prefix is "ios.request:".

You can also use the application topology to visualize the upstream and downstream services for the entire request.

On the Topology View tab, you can switch between Force-directed, Hierarchical, and Circular layouts to view the service topology. Each node displays metrics such as call count, latency, and error count.