OpenTelemetry — Trivia & Interesting Facts¶
Surprising, historical, and little-known facts about OpenTelemetry.
OpenTelemetry was born from merging two competing projects¶
OpenTelemetry (OTel) was created in 2019 by merging OpenTracing (created by Ben Sigelman at LightStep) and OpenCensus (created at Google). The two projects had overlapping goals and competing instrumentation libraries, fragmenting the observability ecosystem. The merger was pragmatic — competing standards helped no one — and unified the community under a single project.
OpenTelemetry is the second most active CNCF project after Kubernetes¶
By contributor count and commit velocity, OpenTelemetry consistently ranks as the second most active project in the CNCF, after Kubernetes itself. The project has over 1,000 contributors across dozens of language SDKs, the Collector, and specification work. This activity level reflects how fundamental observability is to cloud-native infrastructure.
The OpenTelemetry Collector was designed as a "universal telemetry pipeline"¶
The OTel Collector can receive data in multiple formats (Jaeger, Zipkin, Prometheus, OTLP), process it (filter, sample, enrich), and export it to dozens of backends (Datadog, New Relic, Grafana, AWS X-Ray). This "universal adapter" approach means organizations can switch observability backends without re-instrumenting their applications.
Google's Dapper paper from 2010 started the distributed tracing movement¶
Ben Sigelman's work on Google's Dapper system, published as a 2010 paper, described how Google traces requests across thousands of microservices. This paper directly inspired Zipkin (Twitter, 2012), Jaeger (Uber, 2017), and ultimately OpenTelemetry. Nearly every concept in modern distributed tracing — spans, traces, context propagation — originated in the Dapper paper.
Auto-instrumentation can add tracing without changing a single line of code¶
OpenTelemetry's auto-instrumentation agents (available for Java, Python, .NET, Node.js, and others) can inject tracing into applications without any code changes. They use language-specific mechanisms (Java agents, Python monkey-patching, .NET CLR hooks) to intercept framework calls and generate spans automatically. This "zero-code" approach has been critical for adoption.
The W3C Trace Context standard ensures traces work across any system¶
The W3C Trace Context standard (which OpenTelemetry implements) defines how trace IDs are propagated across HTTP headers. Before this standard, every tracing system used its own propagation format, making cross-system tracing impossible. W3C Trace Context, ratified in 2020, means a trace started in a Go service using OTel can be continued in a Java service using Datadog.
OTLP (OpenTelemetry Protocol) is becoming the lingua franca of observability¶
OTLP, the native protocol for OpenTelemetry data, is increasingly supported as a direct ingest format by observability vendors. Datadog, New Relic, Grafana Cloud, and AWS CloudWatch all accept OTLP natively. This standardization means applications instrumented with OTel can send data directly to any backend without vendor-specific exporters.
Metrics in OpenTelemetry were the hardest signal to get right¶
While traces reached stability first, OpenTelemetry's metrics API took years to stabilize because it had to reconcile fundamentally different approaches: Prometheus's pull-based model with histograms and counters versus push-based systems like StatsD and OTLP. The metrics specification went through multiple breaking changes before reaching GA in 2023.
Sampling is essential because collecting every trace is prohibitively expensive¶
At scale, collecting and storing every trace is too expensive. A service handling 100,000 requests per second generates terabytes of trace data daily. OpenTelemetry supports head sampling (decide at the start), tail sampling (decide after seeing the full trace), and probabilistic sampling. Getting sampling right — keeping interesting traces, dropping boring ones — is one of OTel's trickiest operational challenges.
OpenTelemetry logs are the newest and least mature signal¶
OpenTelemetry's logging support reached stable status after traces and metrics. The challenge: the logging ecosystem (log4j, Winston, syslog, structured JSON) is far more fragmented than tracing or metrics. OTel's approach correlates existing logs with traces and metrics through shared context, rather than replacing existing logging libraries.