Multiple different contexts for various backend needs

[ssukienn]

Hi!

What is the optimal and suggested way, if even possible, to somehow be able to host configurations for various different backends that could not adhere to the spec completely? In the same process.

For example, I use Sentry, which treats traceId more like a session ID - i.e. multiple requests on the same navigation page are part of the same trace and Sentry has a concept of transaction as an individual part of the trace. Sentry uses sentry-trace as a propagation carrier set through the SDK or manually.

At the same time, I use GCP loadbalancer, which will use the provided W3C traceparent or set one in the logs and ongoing request to the backend. But for those I don't want Sentry behaviour I would like to be able to differentiate otel trace from trace in GCP logs.

Also I could have different OTel-compliant backends like Jaeger, Datadog, whatnot.

How to connect those things so I have kind of duality between processing/propagating context and creating spans for different backend needs and in the same time keep them as close as possible.

Seems like because of how Sentry works I will need a pair of different traceId to use for it and the rest. Does it mean I would also need to have completely different spans?

Is there an example that deals with those issues? Or way of thinking about it?

Thanks!

[LarryHu0217]

A useful boundary here is: one OpenTelemetry span can be exported to multiple backends, but it cannot have two trace IDs.

A SpanContext has one traceId and one spanId, and a child span inherits its parent’s trace ID. A CompositePropagator can inject several propagation formats, but they represent the same active context; it does not create another trace. tracestate is intended for vendor-specific state within that W3C trace.

For Jaeger, Datadog, GCP, and other OTel-compatible destinations, prefer one TracerProvider with multiple span processors/exporters—or export once to an OpenTelemetry Collector and fan out there. This preserves one trace topology and consistent IDs across backends. Current NodeSDK supports a spanProcessors array.

If Sentry must intentionally use different navigation/session boundaries, treat it as a parallel trace system rather than mutating the OTel context:

• Let OTel propagate traceparent/tracestate for GCP and OTel-compatible backends.
• Let the Sentry SDK propagate its own context.
• Add a stable correlation attribute, or a span link when a valid second SpanContext is available.
• Avoid making two providers compete for the global Node API and context manager.

Before maintaining separate traces, check whether your current Sentry integration can ingest the same OTel spans. If it can, exporting the canonical OTel trace to Sentry is simpler and preserves cross-backend correlation.

References: Tracing API, Propagators API, and NodeSDK configuration.