OpenTelemetry specification

A vendor-neutral standard for generating, collecting, and exporting telemetry data across modern distributed systems.

What it is

OpenTelemetry (OTel) is an open-source observability framework and specification managed by the Cloud Native Computing Foundation (CNCF). It provides a unified set of APIs, SDKs, and tooling to instrument applications and collect the three pillars of observability: metrics, logs, and traces.

Crucially, OpenTelemetry is vendor-neutral. It defines exactly how telemetry data should be structured in memory and transmitted over the network (using the OpenTelemetry Protocol, or OTLP), but it does not provide a backend database to store or query that data.

Why it matters

Before OpenTelemetry, observability was heavily vendor-locked. If an organization used Datadog, developers had to write code using the proprietary Datadog SDK. If the company later decided to switch to New Relic to save costs, they had to rewrite the instrumentation code in thousands of microservices to use the New Relic SDK.

OpenTelemetry eliminates this lock-in. Developers instrument their code once using the open OTel SDK. The application emits standard OTLP data. The organization can then route that data to Datadog, New Relic, Jaeger, Prometheus, or all of them simultaneously, simply by changing a configuration file on the edge collector, without touching a single line of application code.

How to implement

1. Instrumentation

Applications must be instrumented to emit telemetry.

Auto-instrumentation: OTel provides language-specific agents (e.g., a Java JAR or a Node.js preload script) that hook into common libraries (like Spring Boot or Express) at runtime. They automatically generate traces for incoming HTTP requests and outgoing database queries without requiring code changes.
Manual Instrumentation: For custom business logic, developers use the OTel API directly in the code to start specific trace spans or increment custom metric counters.

2. The OTel Collector

While applications can send data directly to a backend, it is standard practice to deploy the OpenTelemetry Collector as a sidecar or a DaemonSet in the cluster.

The Collector acts as a vendor-neutral proxy. It receives OTLP data from the applications, buffers it, batches it, scrubs sensitive data (like PII), and then exports it to the final destination using vendor-specific exporters (e.g., translating OTLP to the Datadog API format).

Common mistakes

Mixing Vendor SDKs with OTel

Organizations migrating to OpenTelemetry often leave old vendor SDKs in the codebase while adding OTel. This causes applications to emit duplicate telemetry, doubling network overhead and polluting dashboards. A migration must be a clean cutover: strip the proprietary agents and exclusively rely on the OTel SDK.

Emitting Too Much Data (No Sampling)

Because auto-instrumentation is incredibly aggressive, a busy microservice might emit tens of thousands of trace spans per second. If the OTel Collector is not configured to sample this data (e.g., only exporting 5% of successful requests but 100% of failed requests), it will overwhelm the backend database and exhaust the network bandwidth of the physical node.

Neglecting Context Propagation

OpenTelemetry relies on the W3C Trace Context standard to stitch traces together across microservices. If an intermediate proxy (like an older Nginx version or an API Gateway) is not configured to forward the traceparent HTTP header, the trace breaks. The OTel backend will display two separate, disconnected traces instead of a single cohesive user journey.

Verification

To verify that an application is emitting valid OTLP data without sending it to a paid vendor, configure a local OTel Collector to use the logging exporter.

receivers:
  otlp:
    protocols:
      grpc:
      http:

exporters:
  logging:
    loglevel: debug

service:
  pipelines:
    traces:
      receivers: [otlp]
      exporters: [logging]

Run the collector locally. When you trigger a request in your application, the collector will print the raw, structured OpenTelemetry JSON payload to the console, confirming that the SDK is correctly instrumenting the code and transmitting it over OTLP.

Sources & further reading

OpenTelemetry Specification - CNCF