Resources
4 min read
Last updated:
OpenTracing was an open-source project developed to provide vendor-neutral APIs and instrumentation for distributed tracing across a variety of environments. As it is often extremely difficult for engineers to see the behaviour of requests when they are working across services in a distributed environment, OpenTracing aimed to provide a solution to heighten observability.
Our purpose in this article is to explain to you why you should stop using OpenTracing and what alternatives are available to use instead that will allow you to instrument tracing into your codebase. Leveraging an alternative for this particular use case will also allow you to gain a much greater level of insight into how your operating environment is behaving.
Contents
What is OpenTracing?
OpenTracing was a standard for tracing distributed trace events (here a distributed trace by its definition includes more than one transaction occurring across various parts of a system). It allowed users to unlock key information about interactions so that we could track the flow of data through a system and know which service system component encountered latency, an error or another type of issue. In addition, it allowed users to add transaction references and identify the types of requests occurring.
Through the transaction reference and timestamp, monitoring tools such as Yeager or Zipkin can link together a set of interactions. This will create a trace which represents the entire transaction that has taken place.
Traces consist of spans (a span could be any timed unit of work) which are explained in greater detail along with examples in this guide. Spans are hierarchical and contain tags and other information to add context to logs. Development teams can then use this level of insight to debug distributed systems, and operations teams can filter performance monitoring based on the current business needs.
Before being archived in January 2022, OpenTracing had provided an API that could be used to enable developers to add tracing as a feature to their codebase.
Many developers who have used OpenTracing previously have reported that it was very unobtrusive and had virtually no negative effects on the performance of the system on which it was deployed.
Among other reasons why OpenTracing was so popular was due to its extensive support for various programming languages. A wide range of languages and frameworks were supported by OpenTracing, including Java, Python, Go, Node.js and Ruby. Therefore, no matter your programming language of choice, instrumenting your code was much easier to do when using OpenTracing Standards.
In addition, the use of OpenTracing could also potentially reduce the costs of demonstrating compliance to regulators for cases such as MiFID II & GDPR. Adding OpenTracing to a legacy platform would help add context to events, thereby making it easier to map them to a regulator's processes.
Why shouldn’t I use OpenTracing?
The main reason why you shouldn’t use OpenTracing to instrument your code is that since January 2022 the project has been sunsetted.
Sunsetting is when a piece of software is intentionally phased out or retired. This is common when a solution is no longer profitable to run, or in the case of OpenTracing, a more cohesive solution is proposed and adopted moving forward.
Why was OpenTracing sunsetted?
As OpenTelemetry was able to provide all of the benefits of both OpenCensus and OpenTracing, it made it much easier for many engineers to switch over and use the newer project rather than choose between using the two older solutions.
What solution should I use instead of OpenTracing?
OpenTelemetry takes over from its predecessors, OpenTracing & OpenCensus and thus should be used for ongoing distributing tracing activities.
By taking the best features of OpenTracing and OpenCensus, OpenTelemetry makes telemetry an integral component of cloud-native applications.
OpenTelemetry provides a collection of APIs, libraries, and collectors that are automatically bundled together. It is possible to collect all the telemetry data you need by using these resources, allowing you to monitor your systems directly in an external tool of your choice (such as Grafana).
Furthermore, OpenTelemetry makes it possible to measure the performance of a distributed system or application remotely, universally across various operating systems and programming languages.
OpenTelemetry vs OpenTracing
Due to the history of OpenTracing in these regards, when it comes to comparing OpenTelemetry vs OpenTracing, we have to look at it as more of an evolution of one tool evolving into another rather than an exact comparison.
A new project called OpenTelemetry was incorporated from two previous projects OpenCensus and OpenTracing. It was both of these projects together that were able to make observability easier to attain whilst expediting the wider adoption of distributed tracing by the software industry as a whole.
It is also important to note that, prior to the merging of the two projects, developers had to choose between the two different options that existed (OpenCensus and OpenTracing). In order to reduce the unnecessary administration from comparing the two solutions against each other, an idea was brought forward to eliminate the need for two competing standards by instead having one combined standard for observability.
Due to the fact that both of these solutions worked towards many of the same end goals, in late 2019, Opencensus and OpenTracing were merged into OpenTelemetry.
Continue learning about OpenTelemetry
Jaeger vs OpenTracing
It is important to keep in mind that OpenTracing & Jaeger have a number of differences which will be discussed in the following sections in order to avoid confusion between the two.
Here is a short summary of the main differences between Jaeger and OpenTracing, which can be summed up as follows:
- While Jaeger is a distributed tracing tool that enables end-to-end tracing, OpenTracing is a library that can be used to instrument systems.
- In the case of Jaeger, there is a web UI component, however, if you are going to use an instrumentation library such as OpenTracing, then you need to select an analysis backend tool for visualisation purposes.
- Compared to Jaeger, OpenTracing is no longer actively maintained because of the reasons discussed previously in this article, while Jaeger is an active open-source project.
- As for data storage, OpenTracing also does not offer a choice, while Jaeger supports two open-source projects that are widely used for data storage: Cassandra and ElasticSearch.
OpenTracing users considering switching to OpenTelemetry can use a platform like Logit.io for OpenTelemetry to handle monitoring, alerting and analysis of telemetry data.
While OpenTelemetry by itself is not an observability platform, Logit.io is, OpenTelemetry is simply a standard for creating OpenTelemetry data itself. With Logit.io, you can centralise any data for reporting, monitoring, and alerting purposes to highlight the status of your distributed system once you have gathered this data.
If you found this article to be informative, perhaps you would like to check out our previous article on Grafana dashboards or our article about ELK stack versus Splunk if you want to keep learning more.