Lightstep from ServiceNow Logo





Lightstep from ServiceNow Logo
< all blogs

OpenTracing vs OpenTelemetry: Building a Bridge with OpenTelemetry

This year at KubeCon EMEA, the OpenTracing and OpenCensus teams announced that the two projects were mergingtwo projects were merging to form OpenTelemetryOpenTelemetry.

One of the main priorities for the merger is straightforward backwards compatibility with both OpenTracing and OpenCensus, via software bridges.

In this post, we’ll discuss the OpenTracing to OpenTelemetry bridge.

Backwards Compatible — from Day One

By joining two similar-yet-not-identical projects, OpenTelemetry aims to reduce confusion for developers and make robust, portable telemetry a built-in feature of cloud-native software.

Again, one of the core aspects taken into account as part of the new OpenTelemetry effort has been to provide backwards compatibility with existing instrumentation code (libraries instrumentation, such as opentracing-django, as well as concrete application instrumentation).

At this moment, there is an ongoing effort for the Java scenario, but such bridges will be implemented for other languages as well.

In order to help with this, the OpenTracing bridge will take any OpenTelemetry Tracer and expose it as an OpenTracing Tracer:

io.opentracing.Tracer tracer = TracerShim.createTracerShim(openTelemetryTracer);

Once this is achieved, it’s possible to simply pass this instance to the initialization code:

static void startApplication () {
  io.opentelemetry.trace.Tracer tracer = ...;
  io.opentracing.Tracer openTracingTracer = TraceShim.createTracerShim(tracer);

static void setUpExistingInstrumentation(io.opentracing.Tracer tracer) {
  // Set up the existing OkHttp instrumentation as usual.
  client = TracingInterceptor.addTracing(new OkHttpClient.Builder(), tracer);

  // ... and create Spans as usual too.
  Span initSpan = tracer.buildSpan("initialization").start();

Although this layer is currently being hosted in the OpenTelemetry Java repository, it will be released as a standalone library that users can later import.

Writing Code: OpenTracing vs OpenTelemetry

OpenTracing vs OpenCensus

Here is the code you would use to write using OpenTracing Java.Let’s look at some simple code. In our example, we have a database call to a hypothetical billing application.

Span span = tracer.buildSpan("distributed-cache-lookup").start();
result = cache.Lookup(key);
span.setTag(“cache-hit”, result != null);

Now, here's the code that you would write for that same call with OpenTelemetry.

Span span = tracer.buildSpan("distributed-cache-lookup").start();
result = cache.Lookup(key);
span.setTag(“cache-hit”, result != null);

It’s the same code! And the result? Nothing changes. OpenTracing concepts like spansspans and tags map one-to-one to those in OpenTelemetry.

Bridges are one part of our strategy to make it as easy as possible for existing OpenTracing and OpenCensus projects send data to OpenTelemetry based observabilityobservability systems.

Initializing the OpenTelemetry Bridge with the Lightstep Tracer

Lightstep Tracers for the new OpenTelemetry API will be released on a language by language basis. After release it will be possible to use them with the bridge for existing OpenTracing instrumentationOpenTracing instrumentation. Continuing with our example in Java, this will only require two steps:

1. Importing the OpenTracing Shim as a dependency in Maven/Gradle (single dependency).


2. Creating a Tracer Shim around the updated LS Tracer, and provide it to the existing OpenTracing-based instrumentation.

// Initialize the OpenTracing Tracer with Lightstep's implementation
Tracer tracer = new com.lightstep.tracer.jre.JRETracer(new com.lightstep.tracer.shared.Options.OptionsBuilder().withAccessToken("{your_access_token}").build());
// Down the initialization, expose it as an OpenTracing Tracer instance:
io.opentracing.Tracer openTracingTracer = TraceShim.createTracerShim(tracer);

// Optionally register it as the OpenTracing GlobalTracer

No more changes will be required for using OpenTracing-based instrumentation, as the Shim will be handling the logic behind the scenes.

OpenTelemetry Bridge: Technical Details

  • OpenTracing Java recently released the 0.33 version, which removes many deprecated members. This was done to ease the incoming migration from OpenTracing instrumentation code to the new OpenTelemetry API, as well as to simplify the requirements for the OpenTracing bridge.

  • The bridge layer (called Shim in the codebase) will internally automatically map logic in both sides. This includes Tags and Logs, which will be mapped to Attributes and Events in the new API. Tags with special meaningspecial meaning will also be translated. For example, the error tag (used, as it name implies, to declare an error happened) will be translated and used to set Span.setStatus(Status.UNKNOWN).

  • Currently such Shim layer has been tested with a port of the OpenTracing testbedtestbed, which covers a few advanced scenarios. Once this is fully achieved, testing will be done using a few instrumentation libraries (such as OkHttp or Mongo instrumentation). Further testing will happen mixing OpenTracing with OpenTelemetry instrumentation, making sure the entire pipe works smoothly.

  • The most important detail/challenge in the OpenTracing bridge is the support for Baggage, which in OpenTracing was part of SpanContext, whereas in OpenTelemetry exists as a standalone component (also currently known as Tags). A few alternatives will be tested in this case to make sure the OpenTracing behavior is kept.

Looking into the Not-So-Distant Future

So, what’s next?

OpenTelemetry is planning on reaching parity with Golang, Java, NodeJS, and Python for OpenTracing and OpenCensus by September 6th of this year.

To clarify, “parity” implies all of the following:

  • A set of interfaces which manifest the OpenTelemetry specification in each programming language

  • An SDK implementing OpenTelemetry specification

  • Backward compatibility with OpenTracing and OpenCensus

  • Metadata helpers for recording common operations defined in the OpenTelemetry semantic conventionssemantic conventions

  • Tests which provide evidence of interoperability

  • Benchmarks which provide evidence of expected resource utilization

  • Documentation and getting started guide

It’s going to take a lot of work, but we’re making good progresswe’re making good progress.

Want to be a Part of OpenTelemetry?

Join us on GitterGitter or GithubGithub, or say hello on TwitterTwitter! We’re always looking for help building the future of high-quality, portable, built-in telemetry.

June 26, 2019
4 min read

Share this article

About the author

Carlos Alberto Cortez

Carlos Alberto Cortez

Read moreRead more

Tracing in Angular: How to get started

Forrest Knight | Sep 30, 2019

Angular is a very opinionated front end framework that utilizes Typescript. In this article, we add traces in two approaches. The first being more of a drop in, the second a more directed and opinionated approach.

Learn moreLearn more

Introducing Java SpecialAgent: Start Tracing without Writing Any Code

Ted Young | May 14, 2019

We’re excited to announce Java SpecialAgent! It’s an extensible OSS Java agent for OpenTracing that enables end-to-end tracing without having to write any code.

Learn moreLearn more

Best Practices for Instrumenting Applications with OpenTracing

Alex Masluk | Jan 30, 2019

The biggest risk in the process of getting started with distributed tracing is only doing partial instrumentation. This article discusses how instrumentation is vital to get started with distributed tracing successfully.

Learn moreLearn more

Lightstep sounds like a lovely idea

Monitoring and observability for the world’s most reliable systems