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.
OpenTelemetry vs OpenTracing
What is OpenTracing? OpenTracing is vendor-neutral APIs and instrumentation for distributed tracing. As a project, it defines a specification for tracing and an API that library and framework authors can implement.
OpenTelemetry picks up the same attributes as OpenTracing, but goes further by defining a specification for SDKs themselves, and comes with default distributions of these SDKs that developers can use. This enables OpenTelemetry to be more broadly adopted because it removes a layer of decision-making developers need to make when picking their tracing client. OpenTelemetry also comes with the OpenTelemetry Collector, a “swiss army knife” proxy that allows for receiving, transforming, and emitting telemetry data in many different forms. This makes OpenTelemetry also compatible with different observability data.
What is OpenCensus?
OpenCensus is a set of libraries for various languages that allow you to collect application metrics and distributed traces, then transfer the data to a backend of your choice in real time. Compared to OpenTracing, OpenCensus is more opinionated in how traces are defined, and also defines a proxy that lets you transform data in different ways before egress to a telemetry backend of choice.
OpenTelemetry incorporates aspects of OpenCensus—namely, having an opinionated set of SDK distributions and the OpenTelemetry Collector. OpenTelemetry also goes further by defining APIs that allow other components to be compatible with OpenTelemetry, making it more extensible and accessible than OpenCensus.
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 projec
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.
Related Terms and 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.
OpenTelemetry, OpenCensus, OpenTracing: Glossary
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:
|
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.
