OpenTelemetry API, SDK, and Collector

WHAT THIS TESTS This evaluates whether you understand OpenTelemetry's layered design and the deliberate separation that lets teams instrument once and send telemetry anywhere.

A GOOD ANSWER COVERS The API is a lightweight, vendor-neutral set of interfaces your application and instrumentation libraries call to create spans, record metrics, and emit logs. It is intentionally minimal and does nothing by itself, so a library can depend on the API without forcing any particular implementation; absent an SDK it is a no-op. The SDK is the concrete implementation of the API that you wire up in your application. It manages how telemetry is processed and emitted: sampling decisions, batching, resource and context attributes, and exporters that serialize data, typically over OTLP, the OpenTelemetry protocol. The Collector is a standalone service, deployed as an agent or gateway, that receives telemetry from many sources, runs it through configurable pipelines of receivers, processors, and exporters, and forwards it to one or more backends. Processors can batch, filter, redact, enrich, or apply tail-based sampling before export.

HOW THEY WORK TOGETHER Application code calls the API, the SDK implements that call and exports via OTLP to the Collector, and the Collector processes and fans the data out to backends like a tracing or metrics store. The Collector is optional, since the SDK can export directly to a backend, but it adds central control and decoupling.

COMMON WRONG ANSWERS Conflating the API and SDK as one thing, or claiming the Collector is mandatory. Another error is thinking the API performs export itself rather than delegating to the SDK.

LIKELY FOLLOW-UPS Why separate the API from the SDK for library authors? Agent versus gateway Collector deployment? What is OTLP? Where does tail-based sampling fit, in the SDK or Collector? How do processors enrich data?

ONE CONCRETE EXAMPLE A Python service uses the OTel API to start a span around a database call. The configured SDK samples it, batches it, and exports it via OTLP to a Collector running as a sidecar. The Collector batches and redacts a sensitive attribute, applies tail-based sampling, then exports traces to a tracing backend and metrics to a separate store. Swapping vendors later means changing only the Collector's exporter config, not a line of instrumented application code.