OpenTelemetry democratises access to observability data & will enable massive innovation

  1. Automate and speed up development & deployment cycles for new features and innovation.
  2. Provide five 9s (99.999%) of availability and great app performance to customers.
  3. Seamless access to prod telemetry data for debugging critical and time-sensitive issues.

Observability World before OpenTelemetry

Before OpenTelemetry came to the fore, the telemetry data collection was proprietary and fragmented. For collecting and exposing telemetry data, four components usually worked in tandem:

  1. Telemetry SDKs: A set of proprietary programming language SDKs provided by vendors to developers. Developers added these SDKs to their codebase, implemented vendor specific interfaces for spitting telemetry data, which was then piped to the collector.
  2. Instrumentation: Many vendors provided, easy to use, language specific instrumentation libraries for initialising and collecting telemetry data from different applications. Some even provided ways to auto instrument telemetry data collection for certain areas like metrics. The data was typically traces, metrics or logs.
  3. Collector: Vendors ran agents in customer environments, which acted as brokers to efficiently transmit telemetry data to vendor cloud. The wire format and protocol of telemetry data collection and transmission was defined by the vendor.
  4. Vendor cloud storage and user interface: Once the data was available in cloud, developers were able to access and analyse it using vendor provided user interface.
Visual representation of vendor specific telemetry data collection
  1. Vendor Lock-in: Organisation got locked in with vendors since implementation of the telemetry instrumentation & data collection was vendor specific and arduous. Replacing vendor meant, going through the whole process again.
  2. Vendor Differentiation: Since telemetry instrumentation & data collection was almost common across vendors, it was not the core value proposition.Vendors were wasting resources on an area which was table-stake rather than putting those efforts in differentiating the functionality offered on the collected telemetry data.

OpenTelemetry and its Components

Let’s first talk about what OpenTelemetry isn’t. OpenTelemetry doesn’t deal with visualisation or analysis of telemetry data collected using it’s standard, APIs and collector.

  1. Define open wire format for telemetry data.
  2. Provide language specific SDKs for collecting and transforming data into open wire format.
  3. Provide specification for semantic convention of different events which result in telemetry data.
  4. Provide opentelemetry collector, which is a software component, used to collect and ingest telemetry data from any source. It can subsequently export that data to any destination based on configuration. It doesn’t store any data by itself but is more of a broker to publish data to different destination.
Courtesy: NewRelic

Data Pillars of OpenTelemetry

There are three key telemetry data pillars of observability stack; Tracing, Metrics and Logs. In the past, they have often been collected and analysed in silos.

Courtesy: Dynatrace

Impact of OpenTelemetry on Observability World

With democratisation of telemetry data collection, OpenTelemetry will increase the pace of innovation in observability world. The days of vendor lock-in and arduous process of vendor specific data collection will be a thing of past.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Pawan Bhadauria

Pawan Bhadauria


Engineer at Heart | Team Builder | Perpetually curious & always learning