OpenTelemetry, OpenTracing, OpenCensus: An Introduction and Glossary

OpenTelemetry, OpenTracing, OpenCensus: An Introduction and Glossary

 

There’s been a fair bit of buzz lately about OpenTelemetry, which is the next major version of the OpenTracing and OpenCensus projects. The leadership of those two projects have come together to create OpenTelemetry, which combines the best parts of OpenTracing and OpenCensus to create one open source project to help with your instrumentation needs.

But, don’t worry! The instrumentation you’ve put all those engineering hours into writing doesn’t need to be ripped out and replaced just yet. OpenCensus and OpenTracing have both been sunset, meaning there will be no new features and there will be minimal bug fixes, but both projects will still be supported by Honeycomb. While there will be no new features in those projects, the OpenTelemetry community is writing bridges into the code so that users won’t have to re-instrument everything. They will be able to add an OpenTelemetry configuration and exporter and have their same OpenTracing data sent to their providers.

Honeycomb loves being involved in the cutting edge of new instrumentation, and we’ve been involved in the OpenTelemetry project for a while now. We are helping run some workshops on how to get started with using this new package, and have our first exporter (for Golang) ready to send your OpenTelemetry traces to Honeycomb. This is still in Alpha, but so is OpenTelemetry. We’re going to keep updating this as the OpenTelemetry project keeps adding functionality and fixing bugs.

But what does it all mean?

All those open standards are so confusing. Even internally at Honeycomb, people have been mixing up the names, and have been confused about which one’s which, what the new one is, and which terminology belongs to which project.

I put together this glossary to help one of my teammates figure out what they all meant after she’d spent a while googling and couldn’t find something that translated one term in a project to the similar term in the other.

Some definitions

OpenTracing: (Sunset) Provides APIs and instrumentation for distributed tracing

OpenCensus: (Sunset) Provides APIs and instrumentation that allow you to collect application metrics and distributed tracing.

OpenTelemetry: (New) An effort to combine distributed tracing, metrics and logging into a single set of system components and language-specific libraries. (Combines the best of OpenTracing + OpenCensus)

Distributed tracing: Provides insights into the full lifecycles, aka traces of requests to a system, allowing you to pinpoint failures and performance issues.

Span: Represents a single unit of work in a system, similar to Honeycomb’s structured events. In fact, in Honeycomb a span is a single event. Typically encapsulates: operation name, a start and finish timestamp, the parent span identifier, the SpanContext identification of the span

Trace: Defined implicitly by its spans. A trace can be thought of as a tree of spans where the edges between spans are defined as parent/child relationships.

SpanContext: Contains the tracing identifiers and the options that are propagated from parent to child spans.

Words still mean things

OpenTelemetry/OpenCensus/OpenTracing all use different terms to mean the same thing. Here’s a list of the synonyms across each project:

OpenTelemetry OpenCensus OpenTracing Honeycomb Definition
Attribute Tag Tag Field:Value Extra information about a span. In the land of Honeycomb, we think of those as fields on the event. In OpenTelemetry and OpenCensus, they are just fields on the span. Baggage in OTracing specifically refers to whole-trace context-propagated fields rather than single-span fields.
MessageEvents Annotations Log Span Events You can think of these as logs at specific timestamps that happen at some point over the course of a span. Prior to OpenTelemetry, Honeycomb didn’t do much with these. In our OpenCensus exporter, we added them as a json field on the event – which is not ideal. In OpenTelemetry, we add them as sub-spans to the span on which they were created. You can find them in the sidebar in a section marked Span Events.
Links Links References Not implemented yet, but will be Links. A Span may be linked to zero or more other Spans (defined by SpanContext) that are causally related. Links can point to SpanContexts inside a single Trace or across different Traces. Links can be used to represent batched operations where a Span was initiated by multiple initiating Spans, each representing a single incoming item being processed in the batch.
Baggage
(Baggage in OpenTelemetry is scheduled for v0.3 of the spec.)
Baggage Baggage Not captured Baggage refers to trace context-propagated fields. Baggage carries data across process boundaries and has two major components:

  • An implementation-dependent state to refer to the distinct span within a trace. i.e., the implementing Tracer’s definition of spanID and traceID
  • Any Baggage Items. These are key:value pairs that cross process-boundaries. These may be useful to have some data available for access throughout the trace.

I hope you find all these definitions to be helpful as you start learning more about OpenTelemetry and how it relates to both OpenCensus and OpenTracing. You can keep an eye on the project as it evolves at https://opentelemetry.io/, or if you’d like to contribute, you can join the Gitter community.


Want to be at the forefront of the Future of distributed telemetry? Start today with a free trial of Honeycomb.