OpenTelemetry Python SDK

OpenTelemetry Python SDK is the official reference implementation of the OpenTelemetry API for Python. It turns the no-op API that libraries instrument against into a fully working telemetry pipeline, capturing distributed traces, metrics, and logs and exporting them to any OpenTelemetry-compatible backend such as the OTLP Collector, Jaeger, or Prometheus.

Applications install the SDK to configure providers, processors, samplers, resource attributes, and exporters, while the libraries they depend on stay coupled only to the lightweight API. This clean split lets you standardize observability across services and vendors without rewriting instrumentation, and it is governed as a CNCF project under the vendor-neutral OpenTelemetry specification.

What You Get

• Production-ready TracerProvider, MeterProvider, and LoggerProvider implementations of the OpenTelemetry API
• Batch and simple span/log processors plus metric readers with configurable export intervals
• Built-in samplers (always-on/off, trace-ID ratio, parent-based) and metric views for aggregation control
• Resource detection and semantic-convention attributes that describe the emitting service and environment
• Environment-variable and entry-point based auto-configuration for exporters, propagators, and samplers

Common Use Cases

• Instrumenting a Python web service to emit distributed traces to an OTLP Collector
• Collecting and exporting application and runtime metrics for Prometheus or a vendor backend
• Standardizing observability across microservices without vendor lock-in
• Correlating logs, traces, and metrics through shared context and resource attributes

Under The Hood

Architecture

The SDK is organized under src/opentelemetry/sdk into three signal pipelines - trace, metrics, and _logs - each exposing a concrete provider (TracerProvider in trace/__init__.py, MeterProvider, LoggerProvider) that implements the corresponding abstract API type. Each provider fans records out to pluggable processors/readers, which in turn hand batches to exporters; the trace/export and metrics/_internal/export packages supply batch and in-memory implementations. Cross-cutting concerns live in resources (service/environment attributes), _configuration (env-var and entry-point driven auto-setup), and _shared_internal, while samplers and metric views gate what data is recorded before it reaches an exporter. Providers register atexit and shutdown hooks so buffered spans and metrics flush cleanly on process exit.

Tech Stack

Pure Python targeting 3.10+ and marked Production/Stable. It is built with Hatchling, depends only on opentelemetry-api, opentelemetry-semantic-conventions, and typing-extensions, and ships as a PEP 561 typed package. Entry points expose environment-variable handlers, id generators, samplers, and exporters for discovery-based configuration, keeping the core dependency footprint minimal.

Code Quality

The repository is a mature, well-tested monorepo with roughly 75 test modules covering the SDK alone, benchmarks, and CI enforced via GitHub Actions and tox. Code is fully type-annotated, follows semantic-convention constants rather than magic strings, and uses bounded attribute collections and explicit limits to guard against unbounded memory growth. As a CNCF project it carries an OpenSSF Best Practices badge and a large, active contributor base.

API Design

The public API mirrors the OpenTelemetry specification, so provider/processor/exporter names are consistent across languages and signals. Getting started requires deliberate wiring - create a provider, attach a processor, register an exporter - which is more boilerplate than a single-call helper, but that explicitness gives fine-grained control. Extensive online documentation, getting-started guides, and entry-point auto-configuration reduce the ceremony for common setups.