Instrument your Python code with the Tracing SDK.
with
statements). This approach automatically handles span start and end times, associates spans with the correct trace context, and captures exceptions, significantly reducing boilerplate and potential errors.
tracing.create_trace()
as a context manager to define a new top-level workflow. This automatically creates the root span for your trace, setting the context for all child spans created within its block.
tracing.create_trace
block, use tracing.create_span()
as a context manager. These spans will automatically:
trace_id
from the current trace.create_span
is active) or the root span.start()
and end()
are always called, and consistency is maintained across your trace.
Span
objects and explicitly control their trace_id
and parent_id
for fine-grained hierarchy management. This is particularly useful when you need to bridge tracing across different processes, services, or when a context manager is not practical.
Remember to manually call span.start()
to begin the span’s lifecycle and span.end()
to complete it. For error handling, you’ll need to wrap your logic in a try...finally
block.
start_time
, end_time
, span_id
, parent_id
, and trace_id
when creating a span. This is useful for reporting historical data, replaying events, or reconstructing traces from external sources. After setting these attributes, call span.flush()
to send the data.
span.flush()
by default blocks the main thread until the request has finished. For non-blocking behavior, use span.flush(blocking=False)
to enqueue the request for the background worker. This is generally recommended for performance-sensitive applications.