The central configuration object for OpenTelemetry tracing — what the Tracer Provider owns, how to configure it, and the Lambda and Node.js shutdown gotchas to know about.
The Tracer Provider is the central configuration point for tracing in your application. It owns the Resource, holds the Span Processor pipeline, and hands out Tracer instances on request.It’s a singleton. Set up once during application initialization, then ask it for tracers wherever you need to create spans.
The stateful runtime component that holds references to span processors, exporters, and the resource.
The object used to create spans.
How many
Usually one per application (global singleton).
One per library, module, or component — name it after the thing it traces.
How you get it
Constructed during app init: TracerProvider(...).
Asked from the provider: trace.get_tracer(__name__).
Lifetime
The full process.
Whatever scope you keep the reference.
Trace hierarchy — parent/child relationships between spans — is usually managed automatically by creating active spans with tracer.start_as_current_span(...). You can also manage hierarchy manually by explicitly setting the context for spans, but that’s rare. See Context Propagation for the manual path.
Once the provider is registered as the global, ask it for a tracer wherever you need to create spans:
from opentelemetry import tracetracer = trace.get_tracer(__name__)with tracer.start_as_current_span("my-operation") as span: span.set_attribute("input.value", "User input") # ... do work ...
The convention is to pass __name__ (the Python module name) so spans are tagged with where they came from.
The Tracer Provider is where two of the most common “no traces” failures live, both rooted in process lifecycle:
AWS Lambda — you must call force_flush().When a Lambda handler returns, the OS freezes the process. The background export thread of a BatchSpanProcessor doesn’t get a chance to export any queued spans. They sit in memory until the next invocation, and on cold starts they’re lost entirely. Always call tracer_provider.force_flush() before returning from the handler.Do not call shutdown() in Lambda. Warm starts reuse the process, and a shut-down Tracer Provider can’t be reused.
Node.js — you must call shutdown().A Node.js process can exit on normal completion before the BatchSpanProcessor’s schedule-delay timer fires. The queued spans are dropped. Call tracerProvider.shutdown() on process exit (typically in a SIGTERM or beforeExit handler) to force a final flush.
These same patterns apply to any short-lived execution environment — CI jobs, one-off scripts, serverless functions. If your process doesn’t run long enough for the next batch interval to elapse, you need to flush manually.For the API surface on both methods, see the TracerProvider API reference.
The Tracer Provider is what brings the previous components together:
TracerProvider├── Resource (who is sending — see /concepts/.../resource)├── Span Processor(s) (when to export — see /concepts/.../span-processor)│ └── Exporter (where to send — see /concepts/.../exporter)└── Tracer instances (used in your code to create spans)
Configuring all of this by hand is verbose. The next page covers the Arize AX register() helper, which handles the wiring for you.