Route complete traces to the intended OpenTelemetry processing gateway

Ordinary traffic distribution may be insufficient when a processor needs all spans from one trace.

Source facts

OpenTelemetry’s gateway pattern can place a load balancer in front of multiple Collectors. For processing tied to a specific Collector, the documentation describes a two-tier design using a trace-ID or service-aware load-balancing exporter. Tail sampling is an example: spans from a given trace must reach the same processing instance. Gateway topology therefore needs to match processing semantics.

Source: OpenTelemetry documentation — Gateway deployment pattern.

Applicability

Review the documented two-tier Collector gateway when processing needs spans of a trace at one instance.

DSE recommendation

DSE recommends identifying which processing stages require shared context before choosing a distribution strategy. Record the gateway endpoint, routing key, failure behavior, and ownership of each tier. Keep application SDK configuration separate from the gateway’s downstream backend settings. Review how membership changes affect in-flight data and stateful processing. Avoid calling multiple replicas redundant without verifying that clients actually distribute traffic and that the chosen processor receives the context it needs.

Verification

In a controlled distributed trace, inspect which processing instance receives its spans and compare behavior during an approved gateway membership change. Confirm the trace-aware stage sees complete expected context. Check destination delivery separately and document any loss or interruption boundary observed during the exercise. Retain the trace identifier and per-instance span observations with the routing configuration. Ask the processor owner to compare that complete expected context with the sampling decision, rather than accepting balanced request counts as proof of correct routing.

Official reference

OpenTelemetry documentation — Gateway deployment pattern. Reviewed October 20, 2026.