OpenTelemetry

OpenTelemetry (often shortened to “OTel”) is an open-source, vendor-neutral standard for generating, collecting, and exporting telemetry — metrics, traces, and logs — from applications and infrastructure. It’s a CNCF project, and today it’s the closest thing the industry has to a common instrumentation layer across every observability pillar.

Why OpenTelemetry exists

Before OpenTelemetry, every observability vendor shipped its own proprietary agent and SDK. Switching vendors meant re-instrumenting your entire codebase. OpenTelemetry decouples instrumentation from the backend: you instrument your code once using OpenTelemetry’s APIs and SDKs, and then choose — or later change — which backend receives that data, whether that’s an open-source tool like Prometheus and Jaeger or a commercial platform like Datadog or Honeycomb.

Core components

• SDKs and APIs — language-specific libraries that let application code emit spans, metrics, and log records in a standard format.
• Instrumentation libraries — pre-built integrations for popular frameworks and libraries (HTTP servers, database clients, message queues) that add telemetry automatically, with little or no code changes.
• The Collector — a standalone service that receives telemetry, can process it (batching, filtering, redacting sensitive fields), and exports it to one or more backends simultaneously.
• Semantic conventions — standardized naming for common attributes (like http.method or db.system) so telemetry from different languages and frameworks stays consistent and comparable.

How it maps to the four pillars

OpenTelemetry’s tracing API was its original, most mature signal. Its metrics API has since reached stability and is widely adopted. Its logs support is newer, focused on correlating log records with traces via shared trace and span IDs. A continuous profiling signal is the newest addition, aiming to bring the same standardization to profile data that OpenTelemetry already brought to traces.