The Cloud Native Computing Foundation (CNCF) has made available an update to its Jaeger distributed tracing project that now makes use of OpenTelemetry agent software to collect data.

Jonah Kowall, a maintainer of the Jaegar project and senior vice president for product and design at Paessler, said Jaeger v2 streamlines the collection of telemetry data by, for example, making it possible to collect batches of data. In addition, Jaegar is now able to natively support the OpenTelemetry protocol, which eliminates the need to translate data into another format as it is collected.

Jaeger v2 also inherits all the core features of the Collector, including auth, cert reloading, internal monitoring and health checks. It also adds support for tail-based sampling, using the upstream OpenTelemetry-contrib processor, along with existing remote and adaptive head-based sampling methods.

In addition, Jaegar v2 is now packaged in a single binary that makes it simpler to deploy.

Mitch Ashley, vice president and practice lead for DevOps and application development at The Futurum Group, added the new release brings together the best of Jaeger and OpenTelemtry. There’s no translation step from OTLP to Jaeger’s internal data format, and Jaeger v2 can use a multitude of extensions available for OpenTelemetry Collector.

As OpenTelemetry has emerged as a de facto standard the need for the Jaegar team to continue to develop its own agent software is now obviated. In fact, many of the contributors that work on Jaegar also work on OpenTelemetry so the two projects are already closely aligned, noted Kowall.

In the wake of adding support for OpenTelemetry, the project is now working on revamping the user interface for Jaegar to make that data more easily discoverable in addition to normalizing dependency views.

In addition, the project is moving toward adding support for the Storage v2 interface to consume OpenTelemetry data natively along with adding support for ClickHouse as the official storage backend for tracing data.

Finally, the project intends to add support for Helm Charts and an Operator that will make deploying Jaegar on Kubernetes clusters simpler.

Originally developed by Uber, it’s not clear to what degree DevOps teams are incorporating Jaegar into their observability platforms. In most cases, DevOps teams that are experimenting with distributed tracing find Jaegar to be a good place to start, said Kowall. However, the organization may ultimately standardize on an observability platform that could be based on a different approach to distributed tracing.

Regardless of approach, a Techstrong Research survey finds 63% working for organizations that will be making additional investments in observability over the next two years, with 21% describing those investments as significant. Nearly half (48%) of respondents work for organizations that already practice observability regularly.

The challenge, of course, has been first finding the funding for observability initiatives, followed then by the issues that arise as DevOps teams move to consolidate tooling. Many software engineers naturally become attached to a particular monitoring tool. Convincing them to swap it out for another platform requires effort and, most importantly, training. Each organization will individually decide to what degree they may want to drive tool consolidation, however, in many cases, the cost of acquiring an observability platform assumes savings will be generated by eliminating the need for other tools.

As application environments become more complex the number of dependencies that exist between various services only continues to multiply. In fact, there will soon come a day when DevOps engineers are not going to want to work for organizations that don’t provide the class of tools needed to make sense of those dependencies simply because the odds of being successful, coupled with the likely level of stress and toil to be encountered, is now simply too high.