Version 2 of Jaeger, a leading open-source distributed tracing platform, has been released. This release contains a significant architectural transformation, as it brings Jaeger and its components into the OpenTelemetry framework.
The most notable change in Jaeger v2 is that it is now architecturally positioned within the OpenTelemetry Collector framework. Jaeger and OpenTelemetry Collector previously shared some code and functionality, but version 2.0 fully embraces the Collector's architecture, creating a more streamlined and extensible platform.
The new version is also shipped as a single binary, replacing the multiple separate binaries of version 1.0. Using a single binary makes the container image leaner (down from 40Mb to 30Mb) and also removes many command-line parameter inconsistencies between Jaeger components. Jaeger and its components can now be enabled at will in a single YAML configuration file.
Jaeger v2 brings several other significant improvements:
- Native OpenTelemetry Processing: To use the OTLP (OpenTelemetry Protocol) data format in older versions of Jaeger, users needed to add an intermediate translation step. The OTLP data format is now natively supported in v2.
- Advanced Sampling Techniques: While Jaeger traditionally supported head-based sampling, the update introduces tail-based sampling capabilities via a sampler previously contributed to OpenTelemetry.
- Expanded Ecosystem Access: Users can now use many pre-existing OpenTelemetry Collector extensions, such as span-to-metric connectors and telemetry processing tools.
- Flexible Storage Implementation: Jaeger's storage layer is now implemented as an abstraction. This means that both querying and exporting functionality can interact with external storage without a dedicated implementation. Batched exporting is also now possible, improving performance with backends such as ClickHouse.
The new version supports all previous storage backends and maintains full backward compatibility. It also introduces support for Kafka as an intermediate queue and provides configurations for various deployment roles including collector, ingester, and query components.
In a post published in the run up to the v2 release, Yuri Shkuro and Jonah Kowall go into more detail on the technical evolution of the changes. Discussing how closely the Jaeger and OpenTelemetry Collector teams have worked together, they say how it's been a goal for some time to bring the projects closer. The alignment means there is less code to maintain in Jaeger. It gives Jaeger more future-proofing due to the close alignment between the two projects - and Jaeger's new status as the preferred tracing system for OpenTelemetry.
Shkuro and Kowall explain that the release of Jaeger v2 marks the third attempt to rebase Jaeger around the OpenTelemetry Collector framework, with this attempt successful thanks to three key factors:
- Breaking command-line compatibility with older versions.
- Importing OpenTelemetry Collector code as a library.
- Building adapters to allow Jaeger v1 code to be reused in v2.
They explain that Jaeger v2's architecture closely mirrors a standard OpenTelemetry Collector, utilising pipelines encompassing receivers, processors, and exporters for telemetry handling. It also incorporates extensions for functions beyond direct telemetry processing, with the Jaeger team making specific design adaptations to the Collector framework.
In a Medium post, CNCF Ambassador Dotan Horovits interviews Shkuro on the new technology in Jaeger v2.
Providing some historical context, Horovits and Shkuro discuss how Jaeger originally provided full SDK and agent capabilities but has been progressively adapting to the OpenTelemetry ecosystem by phasing out its own SDKs, replacing them with OpenTelemetry SDKs. They also discuss how the Jaeger Agent is being deprecated and replaced by the OpenTelemetry Collector.
Further points raised in the interview highlight more flexible data routing from multiple sources like Kafka and Redis, as well as how the OpenTelemetry Builder framework opens up the potential for further dynamic extensions. Horovits also applauds the speed of Jaeger's v2 release. Shkuro explains, "The reason we were able to pull off V2 within a year with not a lot of people working on it is because it was an incremental change rather than a big bang ... let's rewrite everything."
The Jaeger maintainers have also detailed some milestones for 2025, these include:
Native support in the OpenTelemetry Operator
Helm Chart development
Adding ClickHouse as an official storage backend
Improving the user interface so it works natively with OpenTelemetry data
Community reaction to Jaeger v2 has been positive, though with some commentators more reserved around improvements in the UI.
The Jaeger V2 rollout is a pretty big deal - and a huge commitment to OpenTelemetry
The single binary deployment and native OTLP support are nice touches, though we'll need to see how the promised UI improvements pan out.
Jaeger 2.0 is available and easily deployable now. The CNCF announcement recommends the https://www.jaegertracing.io/docs/next-release-v2/getting-started/ getting started page.
