Open in ChatGPTOpen in Claude

Trace exporter

What is trace exporter

With the Trace Exporter feature, you can take full control of how to handle trace data collected by the Coralogix RUM SDK. By configuring a tracesExporter callback, you can intercept trace data, inspect or modify it, and decide if and where to forward it. This supports advanced use cases such as server-side filtering, enrichment, and tail-based sampling, where decisions are made after traces are collected rather than at capture time.

Trace Exporter is supported in the Coralogix RUM Browser SDK and the Coralogix Android SDK (2.11.0 and later).

Why it matters

• Control trace volume by filtering or sampling traces before ingestion.
• Enrich trace data with business or environment context in your own backend.
• Implement tail-based sampling based on trace outcomes, such as errors or latency.
• Integrate with existing OpenTelemetry-compatible collectors running in your infrastructure.

How it works

When you set tracesExporter, the SDK calls your callback with the collected spans in OTLP/JSON format, which mirrors the official OpenTelemetry Protobuf schema for traces and is the shape used when OTLP is sent over HTTP.

Both the Browser and Android SDKs behave the same way:

• Your callback receives the OTLP trace payload.
• The span data is removed from what the SDK sends to Coralogix, so the traces reach your callback instead of Coralogix.
• Everything else the SDK reports - views, errors, network events - keeps going to Coralogix as usual.

So setting the callback redirects your traces rather than duplicating them. If you want them in Coralogix as well, forward them yourself from inside the callback.

What you need

• Coralogix RUM Browser SDK or Android SDK (2.11.0 and later) with tracing enabled
• An endpoint capable of receiving OTLP/JSON trace payloads (for example, your own backend or the Coralogix OTLP ingestion endpoint)

Configuration

Browser

Define the tracesExporter callback as a top-level property in CoralogixRum.init.

CoralogixRum.init({
tracesExporter:(data) => {
  // Forward trace data to your backend or OTLP-compatible endpoint
  }
});

Android

Set the tracesExporter callback in CoralogixOptions. The callback receives a CoralogixTraceExporterData object holding the raw OTLP span payload.

val options = CoralogixOptions(
    // ...
    tracesExporter = { data ->
        // Forward OTLP span payload to your backend or OTLP-compatible endpoint
    }
)

For Android SDK setup, see the Android SDK installation guide.

Forwarding traces to Coralogix

Once you set the callback, Coralogix no longer receives your traces. To keep them there, forward the payload to the Coralogix OTLP endpoint from inside the callback, alongside whatever else you do with it. Forwarding it unchanged sends every collected trace; add your own conditions to filter, enrich or reroute first.

Your other RUM data is unaffected either way - views, errors and network events keep flowing to Coralogix without you doing anything.

Payload format

The callback receives a TraceExporterData object that follows the OpenTelemetry Collector trace format. At a high level, the payload includes resources, scopes, and spans grouped into batches.

{
  "resource_spans": [
    {
      "resource": {
        "attributes": [
          { "key": "service.name", "value": { "string_value": "my-service" } }
        ]
      },
      "scope_spans": [
        {
          "scope": { "name": "rum-sdk" },
          "spans": [
            {
              "trace_id": "7f3a2c1e9b4d4f0a8c7d6e5f4a3b2c1d",
              "span_id": "1a2b3c4d5e6f7081",
              "name": "fetch-data",
              "start_time_unix_nano": "1665753217736722000",
              "end_time_unix_nano": "1665753217737156416"
            }
          ]
        }
      ]
    }
  ]
}

User responsibility and limitations

Inside the callback you are responsible for:

• Delivery to your own destination, including error handling and retries. The SDK does not retry on your behalf.
• Keeping the callback cheap, so it does not block the main thread.

The two SDKs differ in how they contain a callback that throws:

• Android wraps the call and logs a warning, so the SDK's own reporting carries on.
• Browser does not wrap it, and the call sits on the path that sends the RUM payload. An exception escaping your callback also stops that batch reaching Coralogix, so wrap your own work in a try/catch.