Jaeger

Jaeger helps explain what happened to a request as it passed through several application services. Instrumented applications send records of the individual operations, which Jaeger makes available as a connected trace for investigation. It is useful when a slow response or failure cannot be understood from one service's logs alone. Collecting those records, storing them and preserving their parent-child relationships remain essential, even when changing to a newer Jaeger deployment model.

Current guidance

The historical article describes Jaeger v1 and its older instrumentation model. The project now distributes Jaeger v2 around the OpenTelemetry Collector framework, while its download page explicitly ends v1 updates on 31 December 2025. Existing tracing requirements still include receiving spans, storing them, querying traces and controlling retention; a new binary does not remove those responsibilities.

Inventory application exporters and protocols before changing collectors. Confirm that the selected v2 configuration enables the receivers applications use, preserves service names and resource attributes, and applies the intended sampling behavior. For Kubernetes, upstream documents a v2 Helm chart and deployment through the OpenTelemetry Operator. Choose a release-specific example instead of combining v1 command-line flags with a v2 container.

Test a recognizable request across several services and compare its parent-child relationships, errors and searchability. Also check the query interface against retained historical data and the actual storage backend. Replacing the collector deployment does not copy trace storage or establish that all old indexes remain compatible. Bound any temporary dual export to avoid unexpected ingestion cost, then retire old receivers only after confirming application traffic has moved.