OpenTracing is a set of APIs and libraries that enables developers to integrate distributed tracing into their applications, providing visibility into the performance and behavior of complex, distributed systems. In 2019 it was deprecated and merged with OpenCensus to form OpenTelemetry.
Distributed tracing provides an end-to-end, causal, and latency-oriented view of a system. It enables developers to trace requests as they traverse through various services in an application, understanding the sequence of events, dependencies, and paths within the system. This is crucial in identifying bottlenecks and latency issues and diagnosing failures.
OpenTracing was proposed as an open standard for instrumentation, offering vendor-neutral APIs, allowing one to switch between different tracing systems without changing the instrumentation code.
While some organizations still use OpenTracing, the project is now ” archived “. It is recommended to migrate from OpenTracing to OpenTelemetry, and we’ll explain how to do it further in this article.
In this article
The tracer is the component that creates the spans and understands how to record and report them. It is responsible for tracking the execution of a program and generating trace data. It hooks into the application, records the operations, and sends this information to a trace collector.
Each trace is made up of multiple spans, and it’s the tracer’s job to make sure these spans are created, context is managed, and the data is sent out correctly. The tracer provides methods to create and manage spans according to the OpenTracing specification.
A span represents a logical unit of work in OpenTracing with an operation name, start time, and duration. A span could be as simple as a read from a database or as complex as a multi-step operation in a microservice. Each span is part of a trace and can have zero or more causal relationships to other spans.
Spans are the building blocks of a trace. They store the timing data for their operations, along with any relevant tags or logs. A span can have references to other spans, which allows for the construction of a graph that represents the execution flow of the application.
The SpanContext is the state that accompanies a span as it propagates throughout a system. It carries metadata from the span, like trace identifiers and trace-level flags. The SpanContext enables end-to-end trace continuity, even across process boundaries like distributed architectures. SpanContext is the ingredient that allows a trace to provide a coherent, complete picture of a transaction as it moves through a distributed system.
The SpanContext is not meant to be modified once created; it’s intended to be propagated and used as-is. It’s a crucial part of the OpenTracing specification as it ensures that trace context is propagated across process boundaries correctly.
References in OpenTracing are used to establish relationships between spans. There are two types of references:
OpenTracing was sunsetted and merged with OpenCensus to form OpenTelemetry in 2019. The goal was to create a unified, comprehensive standard for distributed tracing and metrics. Both OpenTracing and OpenCensus were similar solutions aiming to solve the same problem—providing developers with a standardized method for capturing distributed traces and metrics.
However, having two separate projects led to fragmentation and confusion in the community. Many developers had to choose between the two or attempt to bridge them, which was not ideal. The decision to sunset OpenTracing and OpenCensus was made in favor of building one standard that would be more beneficial to the developer community.
OpenTelemetry, the successor of OpenTracing and OpenCensus, provides a single set of APIs, libraries, agents, and collector services to capture distributed traces and metrics. It’s built to be more flexible, extensible, and compatible with modern cloud-native software.
OpenTracing was a notable project that set the foundation for standardized distributed tracing. However, OpenTelemetry has expanded on this foundation and introduced more improvements. While OpenTracing was focused primarily on distributed tracing, OpenTelemetry goes beyond tracing to include metrics and logging, providing a more comprehensive observability framework.
OpenTelemetry is also more extensible, providing a broader range of APIs and SDKs that cover more languages and platforms. It also supports more integrations and exporters, making plugging into different backends and analysis tools easier.
However, the most significant difference is the vendor neutrality of OpenTelemetry. While OpenTracing did provide a vendor-neutral API, OpenTelemetry takes this a step further by providing a complete, vendor-neutral observability stack, including APIs, SDKs, and collector services. This means developers can instrument their applications once and choose the backend that best suits their needs without worrying about vendor lock-in.
Learn more in our detailed guide to OpenTelemetry vs OpenTracing
Below, we provide a high-level overview of the migration process. For more details, see the official migration guide.
The OpenTelemetry SDK is a set of libraries that implements the OpenTelemetry API and includes additional features for control and configuration. You can find SDKs for different languages, including Java, Python, Go, and more.
Installing the OpenTelemetry SDK is typically straightforward. Once the SDK is installed, you can remove the current OpenTracing implementation in your application.
Removing the current OpenTracing implementation must be done carefully, ensuring no critical tracing functionality is lost during the transition. The OpenTelemetry SDK is designed to provide equivalent or superior functionality to OpenTracing, so you should be able to replace all existing OpenTracing capabilities.
The next step in the migration process is to install the OpenTelemetry instrumentation libraries. These libraries provide automatic instrumentation for various frameworks and libraries, significantly reducing the amount of manual work required to instrument your application.
Installing these libraries usually involves adding a dependency to your project. Once installed, they automatically generate telemetry data from your application, which can then be collected and analyzed.
After installing the OpenTelemetry instrumentation libraries, you can proceed to remove the OpenTracing equivalents. Like removing the OpenTracing SDK, this process must be done carefully to ensure no important functionality is lost.
After installing the OpenTelemetry SDK and instrumentation libraries, you need to update your observability dashboards, alerts, and other tools to consume the new OpenTelemetry data.
Because OpenTelemetry data is structured differently from OpenTracing data, this step might require modifications to your existing dashboards and alerts. However, the benefits of using OpenTelemetry—such as improved consistency and the ability to collect a wider range of data—make this effort worthwhile.
When you start writing new application code after migrating to OpenTelemetry, it’s important to write all new instrumentation using the OpenTelemetry API. This approach helps you take full advantage of the features provided by OpenTelemetry and ensures consistency throughout your application.
It’s important to realize that OpenTelemetry is backward compatible with OpenTracing. So you do not need to go back and change instrumentation previously done for OpenTracing. However, over time, it is recommended that the instrumentation be updated to take advantage of new features available in OpenTelemetry.
This process involves going through your application and replacing the old OpenTracing instrumentation with new OpenTelemetry instrumentation.
Re-instrumenting your application is a significant task, especially for large and complex applications. By implementing this step progressively, you can spread the work over time and minimize disruption to your development process.
OpenTelemetry offers a pluggable architecture that enables you to add technology protocols and formats easily. Using OpenTelemtry, Lumigo provides containerized applications with end-to-end observability through automated distributed tracing.
