Lightstep from ServiceNow Logo





Lightstep from ServiceNow Logo
< all blogs

OpenTelemetry specification: a year in review

2020 was a banner year for OpenTelemetry, by any account. From modest beginnings, the project grew to hundreds of contributors across many languages, all working together to make real the vision of open source observability. The heart of the project, however, is the specification -- a set of design and specification documents intended to describe both the why, and the how, of OpenTelemetry itself.

Why do we need specifications?

A project like OpenTelemetryOpenTelemetry is a great example of the importance of specifications, and of specification work. Trying to create and coordinate hundreds of contributors working in different programming languages to create a shared model of telemetry data would be a herculean task without the tireless efforts of our specification writers and maintainers. The work being performed to build the specification also builds upon itself, providing future authors a reference to implement OpenTelemetry in languages that it doesn’t currently support, or to be used in ways we can’t even conceive of right now.

With that said, let’s take a look back at some interesting statistics about the year that was, and then briefly discuss where the specification is going in 2021.

Looking Back on OpenTelemetry Specification

2020 was a year of firsts for many of us, and it also marks the first official semantically versioned release of the specification, 0.4.0 on May 12th. This was also a huge milestone, as this was the first major iteration on the OpenTelemetry Metrics API. Indeed, 2020 in the specification was a year where the metrics API and SDK design was (perhaps endlessly) litigated and iterated upon.

The summer brought 0.5 and 0.6, which continued to improve the metrics specification while also fleshing out the tracing API and SDK. A new area of the specification was added here as well, the initial logging specification. While logging support in OpenTelemetry isn’t likely to be ready for production in 2021, we’re looking forward to the community further iterating on this part of the project.

Late summer saw a flurry of activity -- as a matter of fact, August and September saw the greatest number of contributions all year, with 1977 contributions in August and 2081 in September. Why did activity increase? Several reasons. First, adoption of the OpenTelemetry APIs and SDKs was picking up, and critical end-user feedback was being integrated into the specification process. Second, the project was beginning to move towards a specification freeze for trace components. At a certain point, we needed to provide some stability guarantees to maintainers of language SDKs that nothing else would be changing in the specification, so that they could provide better guidance to their users about the stability of the API and SDK. After months of work, the specification reached 0.7.0 in November, and the trace specification was frozen.

Specification by the numbers

Did you know…

  • The spec has had contributors from well over 35 companies?

  • On average, the specification repository nets 37 PR comments a day!

  • The single-day record for PR comments was in August of 2020, with 89.

  • You might think PR’s tend to linger, but that’s not necessarily the case! Most PR’s are merged within 16 hours. We like to move fast!

  • Frequent specification contributors include observability companies such as Lightstep, Dynatrace, New Relic, and Splunk but also include end-users such as Shopify, Zillow, Postmates, and Uber!

  • The specification really is a community effort - we had over 100 individuals contribute in one month of 2020 alone!

What’s next for OpenTelemetry specification?

With our announcement of the tracing specification reaching the 1.0 milestone1.0 milestone, what’s next? We’ve been working on OpenTelemetry in one form or another since late 2018, and everyone’s very excited to get to the point where it’s stable for integrators and end-users. To that end, the project is kicking off initiatives to stabilize the metrics specification, expand semantic conventions, and define performance and scalability standards for the OpenTelemetry SDKs. Want to know what’s on our plate? The best way to keep up-to-date is to follow the required-for-garequired-for-ga tag on the specification GitHub, or attend the weekly specification meetingweekly specification meeting.

Interested in joining our team? See our open positions herehere.

February 17, 2021
4 min read

Share this article

About the author

Austin Parker

Austin Parker

Read moreRead more

From Day 0 to Day 2: Reducing the anxiety of scaling up cloud-native deployments

Jason English | Mar 7, 2023

The global cloud-native development community is facing a reckoning. There are too many tools, too much telemetry data, and not enough skilled people to make sense of it all.  See how you can.

Learn moreLearn more

OpenTelemetry Collector in Kubernetes: Get started with autoscaling

Moh Osman | Jan 6, 2023

Learn how to leverage a Horizontal Pod Autoscaler alongside the OpenTelemetry Collector in Kubernetes. This will enable a cluster to handle varying telemetry workloads as the collector pool aligns to demand.

Learn moreLearn more

Observability-Landscape-as-Code in Practice

Adriana Villela, Ana Margarita Medina | Oct 25, 2022

Learn how to put Observability-Landscape-as-Code in this hands-on tutorial. In it, you'll use Terraform to create a Kubernetes cluster, configure and deploy the OTel Demo App to send Traces and Metrics to Lightstep, and create dashboards in Lightstep.

Learn moreLearn more

Lightstep sounds like a lovely idea

Monitoring and observability for the world’s most reliable systems