Jaeger and OpenTelemetry

Recently, OpenTelemetry has been announced as a new CNCF sandbox project resulting from a merger of OpenTracing and OpenCensus [1], [2], [3], [4]. Several people have already asked me what OpenTelemetry means for the Jaeger project (incubating at CNCF), and whether it is going to replace Jaeger. I will attempt to answer these questions in this post.

I’ve been working on OpenTracing from its inception at a Zipkin workshop back in the Fall of 2015. We had just begun deploying distributed tracing at Uber, and I knew that we needed an open, vendor-neutral API to incorporate into the source code of Uber’s rapidly growing microservices ecosystem. Today, OpenTracing APIs exist in 9+ languages, enjoys wide support from vendors, and has over 100 integrations with various open source projects (https://opentracing.io/registry).

OpenCensus is an open-source reincarnation of Google’s internal Census libraries used for collecting tracing and metrics data. It took a different approach by providing a concrete, opinionated implementation for capturing observability signals. By employing “batteries included” approach it had an advantage over OpenTracing for software that was shipped as binaries, such as database engines, Kubernetes components, etc., because the binaries could link to a known implementation rather than use late binding to concrete tracers that was required by the OpenTracing approach.

On the downside, since OpenCensus APIs were tightly coupled to the implementations, it was difficult and often impossible to bind the instrumentation to different implementations even when users wanted it.

Source: medium.com