Software systems are becoming increasingly distributed daily, and monitoring the performance in real-time of applications siloed in these systems is becoming more challenging for SRE and DevOps teams. OpenTracing and OpenTelemetry, both open-source projects, have helped ease the monitoring process for distributed systems, microservices, and Kubernetes-based cloud-native environments, but how do you know which solutions best suit your use case? This article will walk you through the distinguishing features of each solution and provide steps to migrate between data formats and outputs.

What is OpenTelemetry?

OpenTelemetry (OTel) is an open-source framework with a collection of SDKs, APIs, and libraries that capture, transform, emit, and export telemetry data to optimize system performance. It unifies the capabilities of OpenTracing and OpenCensus projects into a comprehensive framework with logging, distributed tracing, and metrics collection features. OpenTelemetry project was accepted to the Cloud Native Computing Foundation (CNCF) on May 7, 2019, and moved to the incubating maturity level on August 26, 2021.

What is OpenTracing?

OpenTracing is an open-source, vendor-neutral framework that includes a set of APIs for distributed tracing of applications. OpenTracing sought to solve problems associated with adopting distributed tracing, for example, the inability to reuse instrumentation across networks and libraries. OpenTracing solved this problem via its unified instrumentation API, compatible with several programming languages—such as Java, Python, Go, PHP, C#, and JavaScript—and multiple tracing systems and backends.

OpenTracing provides a set of primitives for creating and manipulating traces and spans. A trace represents the journey of a single request, while spans represent individual work units within that trace. Spans are linked to visualize the complete path and relationships between different components with a trace ID.

Features of OpenTelemetry

OTel offers several critical features for instrumenting applications and collecting telemetry data.

Three Pillars of Observability

Observability has three pillars: Metrics, Logs, and Traces. The table below gives an overview of how OTel eases the collection and aggregation of each pillar.

Vendor Neutral

An essential feature of OTel is that its OpenTelemetry Collector integrates with and can send different metrics to popular observability solutions, allowing you to choose your preferred telemetry backends and avoid vendor lock-in.

Compatibility with OpenTracing and OpenCensus

OTel combines the functionalities of OpenTracing and OpenCensus projects, which individually cannot fully and flexibly capture and export all telemetry data. By combining both and enhancing their features, OTel provides a framework for collecting metrics, traces, logs, and accompanying metadata. It also provides a bridge API for compatibility, enabling developers to migrate from OpenTracing or OpenCensus to OpenTelemetry efficiently.

Extensibility

OTel defines APIs as allowing extension points to incorporate other components and technologies and a flexible architecture that allows for compatibility. This enables the addition of custom instrumentation, exporters, and telemetry backend, ensuring that OTel can be adapted to fit different application requirements and environments.

Features of OpenTracing

OpenTracing offers the following essential features.

Highly consistent and functional API

OpenTracing has two API categories: Tracers and Spans.

Tracers are highly interoperable and are used to create, insert, and extract span contexts. They can be initiated to automate span creation. After span creation, tag aggregation and the addition of baggage items follow.

Tracing Instrumentation

As a transaction—such as query transmission to the server—progresses, one or more spans are created to encapsulate single work units in the lifecycle of a request. The spans can be stopped so you can annotate them using metadata.

Distributed Context Propagation

OpenTracing allows for the correlation of performance data across multiple systems to be reassembled into coherent traces (of individual request lifecycles), which enable end-to-end visibility. Context propagation links span together to create a complete picture of request execution, providing insights into system behavior as the request journeys through the path.

Span Nesting

Nested spans provide a granular view of the execution path within individual services and components. OpenTracing allows you to attach baggage items that facilitate cross-span propagation, easing the establishment of relationships between spans. This allows you to represent parent-child and follows-from relationships between spans.

Why were they unified?

OpenTracing was developed to be a vendor-agnostic solution for distributed tracing. However, it did not cater to distributed metrics. This prompted the creation of OpenCensus to cater to distributed traces and metrics. However, OpenTracing was not completely phased out, and this resulted in telemetry rivalry, leading to poor support and adoption, irregular patches, and poor interoperability between the two frameworks.

OTel was then developed to douse this rivalry via its numerous language-specific instrumentation libraries and SDKs.

OpenTelemetry vs. Other Observability Solutions

Jaeger and Zipkin are also distributed tracing systems like OpenTracing, which is trace-focused. Jaeger embodies the OpenTracing API and offers a user interface for trace exploration and analysis. On the other hand, Zipkin is a standalone open-source distributed tracing system with an ecosystem of instrumentation libraries and integrations. It functions similarly to Jaeger.

Prometheus is also worthy of mention. It is a monitoring and alerting toolkit designed to collect time series data—such as metrics—from applications and systems. With powerful PromQL query language and visualization capabilities via Grafana, Prometheus allows users to monitor their applications and set up custom alerts based on defined thresholds.

Prometheus run into scaling challenges with high cardinality metrics and Last9's Levitate - a managed Prometheus solution provides a cost effective alternative. Book a demo to know more.

The most important differentiator is OTel’s incorporation of metrics and logs alongside distributed traces, making it the most comprehensive of the currently available solutions.

Choosing between OpenTelemetry and OpenTracing

Your choice must be influenced by factors such as existing codebase, preferred programming language, ecosystem support, and the level of integrations you require.
OpenTracing and OpenTelemetry are complementary rather than competing. Moreover, since OTel addresses the limitations of existing observability frameworks (one of which is OpenTracing), it is considered a next-generation solution, and several OpenTracing users are transitioning to OpenTelemetry already.

Migrating from OpenTracing to OpenTelemetry

OpenTelemetry provides a bridge API for compatibility with OpenTracing and it involves updating your instrumentation code, dependencies, and configuration. A high-level overview of the migration process—including language version support—is provided below.

Language Version Support

Before implementing an OpenTracing shim (a component that allows you to consume OpenTracing traces and export them as OpenTelemetry data) in your project, check the language and runtime versions of your project. If necessary, update them to meet the minimum language versions required. Below is a table of the minimum language versions supported by OpenTracing and OpenTelemetry APIs.

Conclusion

OpenTracing and OpenTelemetry are valuable, vendor-neutral observability projects. OpenTelemetry, however, offers expanded functionality than OpenTracing. Its unified approach that allows you to gather performance metrics, trace data, and log events is also leveraged. It is also consistently updated and has strong community support, making it more suitable for your current and future applications.

FAQs

Can I use OpenTracing and OpenTelemetry together?

Yes, OpenTelemetry provides a bridge API that allows you to use OpenTracing alongside OpenTelemetry.

Is OpenTelemetry source code available on GitHub?

Yes, it is available on GitHub here. http://github.com/open-telemetry

Does OpenTelemetry support multiple programming languages?

OpenTelemetry supports several popular programming languages, including Java, Python, Go, JavaScript, .NET, and more. The experience of using OTel is consistent across the board.

Is OpenTracing deprecated?

OpenTracing is now deprecated, and its users are advised to migrate to OpenTelemetry. There will be no new features or bug fixes for OpenTracing. Thus, old, existing, and new tracing projects must be instrumented using OpenTelemetry.

Can I use OpenTelemetry without vendor lock-in?

Yes, OpenTelemetry is vendor-agnostic, and you can switch between multiple backends using the OpenTelemetry Collector.

Is OpenTelemetry backward compatible with OpenTracing?

The OpenTelemetry project aims to provide backward compatibility with the OpenTracing project to ease the migration of instrumented codebases.

This functionality is provided as a bridge layer implementing the OpenTracing API using the OpenTelemetry API.

What is OTLP?

The OpenTelemetry Protocol (OTLP) outlines the encoding methods, transmitting and conveying telemetry data from its sources, passing through intermediary nodes like collectors, and finally to telemetry backends.

Designed within the framework of the OpenTelemetry project, OTLP serves as a universal protocol for transmitting telemetry information.

Is there an OpenTelemetry Tutorial available?

Yes. You can find various OpenTelemetry tutorials. There is also an official demo app that demonstrates the capabilities of OpenTelemetry SDKs, which you can combine with Grafana and even debug application performance like an APM would do.