OpenTelemetry SDK: The Engine for Your Telemetry

WHY IT EXISTS OpenTelemetry separates the standard from the implementation. The API defines what telemetry is (a span, a metric) but doesn't provide code to actually collect or send it. Applications need a concrete library to make telemetry real, which is why the SDK exists: to be that configurable, language-specific implementation.

THE MENTAL MODEL Think of the OpenTelemetry API as the blueprint for your car's dashboard gauges (speedometer, fuel gauge). The SDK is the actual engine and wiring under the hood. It reads raw data from sensors (instrumentation), decides how often to check them (sampling), bundles the readings together (batching), and sends them to the dashboard via a specific protocol (the exporter). You don't interact with the SDK in your business logic; you configure it once at startup.

HOW IT WORKS The SDK is a library you add to your application, specific to its language (e.g., Java, Python, Go). At application startup, you configure it with several key components. First, Processors and Readers manage how signals like traces and metrics are received and batched. Second, Samplers make decisions on whether to keep or drop a trace to manage volume. Third, Exporters are configured to send the processed data to a specific destination, such as an OpenTelemetry Collector, Jaeger, or Prometheus, often using the OpenTelemetry Protocol (OTLP).

WHEN TO USE IT You use an SDK in every application you want to observe with OpenTelemetry. It is the required component for turning the potential telemetry from instrumentation libraries into actual, exported data. You typically configure it once when your application starts up and then let it run in the background.

WHEN NOT TO USE IT Avoid using the SDK directly within your application's business logic. For creating spans or recording metrics, your code should only depend on the OpenTelemetry API package. This decouples your instrumentation from the implementation, allowing the SDK to be swapped or reconfigured without changing your core logic. The SDK is for initialization, not for ongoing interaction.

ONE CANONICAL EXAMPLE In a Python application, you initialize the SDK at startup. You might create a TracerProvider, add a BatchSpanProcessor to it, and configure an OTLPSpanExporter to send traces to a collector. Then, you register this provider globally. From that point on, any library or application code that calls trace.get_tracer(__name__) from the OTel API will have its spans automatically processed and exported by this configured SDK pipeline.