Requirements for Jaeger to OpenTelemetry transition

The OpenTelemetry (OTEL) Collector serves as the middleware centerpiece of the modern observability stack. Its primary architectural value lies in its ability to receive disparate telemetry protocols simultaneously and standardize them into the single OTEL data model for efficient routing.

Prerequisites:

• Jaeger/Zipkin
• OpenTelemetry

In this lesson, you will:

• Get a deeper understanding of how the data will be converted into OTEL post transition.

Data flow components (receivers)

To achieve a seamless transition from legacy Jaeger/Zipkin clients to OTEL, the collector must simultaneously perform two key, but separate, functions: data reception and dynamic sampling configuration.

Enabling the following receivers in the receivers: section within OTEL and including them in the traces pipeline will convert all trace data to the standardized OTEL data model:

1. zipkin receiver: Must be enabled to listen on the standard Zipkin port (typically 9411) to handle traces from services using the Zipkin wire format (e.g., JSON or Thrift).
2. otlp receiver (Google Remote Procedure Call (gRPC/HTTP)): Must be enabled on standard OpenTelemetry Protocol (OTLP) ports (e.g., 4317/4318) to accept traces from all newly instrumented OTEL services and browser clients.

Unified export (exporters)

The traces collected from all receivers are combined, processed (e.g., batched), and sent to the final observability systems:

• OTLP exporter: The pipeline must terminate in an OTLP exporter. This ensures that, regardless of the initial protocol (Zipkin, OTLP, or even Jaeger if an additional jaeger receiver was present), the data is consistently sent to the final endpoints (Jaeger and Tempo) using the extension and the vendor-neutral OpenTelemetry Protocol.

This architecture ensures a zero-downtime path for data migration while simultaneously managing the legacy clients' essential remote sampling feature.

Next, we’ll proceed to creating our test Jaeger instance.