What is OpenTelemetry, and what problem does it solve?

An open-source, vendor-neutral standard for producing observability data — metrics, logs and traces — so that you instrument an application once and can send its data to any back end.

Before it, every observability vendor shipped its own agent, its own SDK and its own data format. Instrumenting an application meant binding it to that vendor: switching later meant re-instrumenting everything, which is why vendor lock-in in this market was so effective.

OpenTelemetry (a CNCF project, and the de-facto standard) defines the parts that had no reason to be proprietary:

• The data model and formats for the three signals — metrics, logs, traces.
• The APIs and SDKs applications call to emit them, across a long list of languages.
• The collector, a separate process that receives, processes and forwards the data.

It runs wherever the workloads do — Kubernetes, Azure, AWS, Google Cloud, on-premises — and its stated goals are exactly the three things a standard is for: uniform instrumentation, vendor independence and standardised data formats.

Tip: the line worth remembering — OpenTelemetry is the common language of the observability world. It produces and transports the data; it does not store or visualise it, which is what the back ends are still for.

Go deeper:

• OpenTelemetry official documentation — concepts, language SDKs and collector configuration.
• OpenTelemetry Demystified: An Observability Tutorial for Beginners (Is it Observable) — a hands-on walk-through from instrumentation to a first trace.