Introduction
Let's start at the end to give some context: The Signals of today's OpenTelemetry standard are: Distributed Traces, Metrics and Logs (along with the Profiling Signal which is in Alpha).
The main points of this post is that the history of telemetry demonstrates:
- Telemetry is powerful.
- Telemetry is everywhere.
- Well-structured telemetry is lasting.
Telemetry means "measuring at a distance". The word "telemetry" comes from Greek "tele" (far) + "metron" (measure) and is older than computing.
Telemetry is all around you. This is a microwave dish at a railroad station near the border between Italy and France. It communicates data in a straight line to a receiver at another station.
A microwave relay dish at a railroad station near the Italy–France border. © Michael Bushe 2026.
A Brief History of Telemetry
"The Tsar's Wire" was built in 1845 and is one of the earliest recorded data-transmission circuits in history. It was built between the House of Romanov's Winter Palace and the Army Headquarters, both in Saint Petersburg, Russia. It automatically transmitted structured logs and metrics (two of the Signals of OpenTelemetry), distinguishing it from humans typing text on a telegraph wire.
General K.I. Konstantinov built a specialized 16-contact commutation switch, a simplistic multiplexer, connected to dials. Humans set the dials to communicate important measures like "Rations," "Infantry Tally," "Cavalry Tally," "Ammunition Stocks" and eventually "Cannonball Speed".
General K.I. Konstantinov, whose 16-contact commutator drove the Tsar's Wire. (Public domain)
In 1874, French engineers built a system of weather and snow-depth sensors on Mont Blanc that transmitted real-time information to Paris.
Measurement moved to the summit: the Janssen Observatory atop Mont Blanc (4,810 m), on a period postcard. (Public domain)
In 1912, Commonwealth Edison developed a system of telemetry to monitor electrical loads on the power grid in Chicago. This is the forebear of the modern Supervisory Control and Data Acquisition (SCADA) systems that workers use to operate pumps, valves and other industrial equipment today. A similar system was used to operate the Panama Canal just a few years later.
Commonwealth Edison's Fisk Street Station turbine room, Chicago, photographed in 1918. (National Archives)
By the 1960s, Project Mercury's spacecraft transmitted continuous biometric data on the astronaut (heart rate, respiration, body temperature) plus dozens of vehicle channels.
Mercury Control Center before the MA-8 flight, 1962. Every console is rendering spacecraft telemetry. (NASA)
The first wearable cardiac telemetry (a small radio transmitter) appeared in 1961 and is still routine equipment in every cardiology ward today.
Cardiac telemetry today: a 3-lead Holter monitor. (Photo: K6ka, CC BY-SA 4.0)
Software Telemetry
The earliest mainframe operating systems wrote structured records about what their workloads were doing. IBM's System Management Facility (SMF), introduced with OS/360 around 1966–1967, wrote per-job records of CPU time, channel I/O, dataset access, and operator commands to a dedicated dataset.
The console of an IBM System/360 Model 65 — the platform where SMF started writing records that are still read today. (Photo: Living Computers Museum+Labs, CC BY-SA 4.0)
These weren't "at a distance" since batch jobs on the same mainframe would process them later, but many
SMF record types defined in the 1960s are still in use on z/OS today. The important point is that telemetry
schemas are long-lasting and should be structured well. This is why OpenTelemetry is very careful about versioning.
A 1.0 OpenTelemetry release not only has a stable API, but its output — the structure of the data — is stable too.
That structure is partly defined in OpenTelemetry's Semantic Conventions.
For example, it's host.name, not hostname, everywhere.
The first time a computer running networking software continuously reported its operational state to a remote management system was ARPANET IMP statistics, in 1969. Each Interface Message Processor (the BBN-built minicomputer that sent ARPANET packets) emitted regular statistics packets back to BBN's Network Control Center in Cambridge, Massachusetts with metrics for line throughput, error rates, queue depths, routing-table sizes and more.
Standardized Telemetry
SNMP (Simple Network Management Protocol), RFC 1067 in 1988, was the first widely deployed standardized software telemetry protocol. Every router, switch, printer, UPS, and server-side daemon for the next thirty years exposed an SNMP MIB. Massive opsware products were built around SNMP. They could monitor and control any device on a network from a printer to a storage array. These were among the most complex software applications ever made, among them IBM Tivoli, HP OpenView and EMC ControlCenter.
A Cisco AGS router (1986) — for thirty years, every box like this exposed an SNMP MIB. (Photo: Michael Hicks, CC BY 2.0)
Proprietary Telemetry
By the 1990s, applications often "phoned home" from end-user devices, usually to report errors: Mozilla telemetry, Windows telemetry, Chrome usage statistics.
Telemetry drove quality. Vendors fixed the errors with the highest count across all users.
Wily Technology's Introscope, usually credited as the first commercial application performance monitoring (APM) tool, was released in 1998. A Java agent that instrumented JVMs, it reported method-level latency and exception data to a central console. Wily was acquired by CA in 2006 for $375M, an early signal of the value of telemetry.
The contemporaries that built the modern APM space — AppDynamics (2008), New Relic (2008), Dynatrace (2005) —
all derive their architectural DNA from Introscope.
For decades the answer was vendor-specific agents, log shippers, and metric collectors. Every observability vendor had their own SDK, their own tagging conventions, their own performance tradeoffs. Switching vendors meant re-instrumenting every service and every app.
The Road to OpenTelemetry
Large organizations have many systems that need to work together. Different systems using different proprietary telemetry SDKs created painful silos, and made systems hard to manage. Actions that started in one system and ended in another could not be traced between the systems - distributed tracing was difficult or impossible.
The incompatibility pain finally pushed the industry toward a common standard, twice.
Google's 2010 Dapper paper described how Google traced a single request across thousands of services, and it lit a fuse. Twitter open-sourced Zipkin in 2012; Uber followed with Jaeger, which joined the CNCF in 2017. In 2016, OpenTracing joined the CNCF offering a vendor-neutral tracing API.
In January 2018 Google open-sourced its internal Census libraries as OpenCensus, covering both traces and metrics.
Two competing "standards" threatened to split the community.
Every one of those tracers worked, yet none of them could read each other's trace context. Zipkin
propagated X-B3-* headers, Jaeger used uber-trace-id, Dynatrace had x-dynatrace, and
Microsoft's Application Insights used Request-Id. A distributed trace died the moment a request
crossed from a service instrumented with one system into a service instrumented with another — or
passed through a cloud load balancer that silently dropped headers it didn't recognize.
The fix came from a then-unlikely alliance. Engineers from Microsoft, Google, and Dynatrace started
meeting in 2017 to standardize the headers themselves, and in 2018 the effort was chartered as the
W3C Distributed Tracing Working Group,
co-chaired by the three companies. The resulting
Trace Context specification — edited by Sergey Kanzhelev
(Microsoft), Morgan McLean (Google), and Alois Reitbauer (Dynatrace) — defined the traceparent
and tracestate headers and became a W3C Recommendation in February 2020: one universal way to say
"this request belongs to this trace" that any SDK, proxy, or cloud service can propagate.
Competitors were now agreeing on how observability should work.
Though W3C Trace Context solved the connection between services, it didn't solve the SDKs inside them. OpenTracing and OpenCensus were still two competing "standards" splitting the community's instrumentation effort. In May 2019, at KubeCon Barcelona, the two projects announced they were merging into a single CNCF project: OpenTelemetry.
Rivals who had spent two decades locking customers into proprietary agents — Google, Microsoft, Dynatrace, Splunk, New Relic, Lightstep, Honeycomb, and nearly every other observability vendor — now co-author one specification, one wire protocol (OTLP), and one set of semantic conventions. The pain of the agent era was solved: instrument once, and your telemetry goes wherever you point it.
Summary
Telemetry has one continuous story from 1845 to the present: measurements about something running, transmitted somewhere else for analysis. The substrate kept changing from telegraph wire, radio, RS-232, TCP, OTLP; but the shape and function stayed remarkably stable. OpenTelemetry is now the software standard for observability.
We pick up the story of OpenTelemetry with its current state in the next post: Why OpenTelemetry?
Read more: Why OpenTelemetry? · Pricing