تتبّع استدعاء أداة من البداية إلى النهاية

A single tool call may touch your server, a database, and an API. Tracing stitches those hops into one timeline so you see the whole journey. 🧵

A trace is the full request; a span is one step inside it. Each span records a name, a start, and a duration, and spans nest like a tree.

Every span in one request shares a single trace ID. That shared id is what lets a tool reconstruct exactly which steps belonged together.

Spans link through a parent ID. The tool call is the parent; the database query and API call become its children, forming the timeline tree.

The standard for this in Python is OpenTelemetry. It defines traces, spans, and context so your data works with many backends, not just one.

You wrap work in a span using a context manager. Everything inside it is timed and nested under the current trace automatically.

Decorate a span with attributes: small key-value facts like the tool name or result count. They make a trace far easier to read later.

When a step fails, mark its span with the error status. The trace then shows you exactly which hop broke the request, not just that it broke.

To trace across a network call, you pass the trace context along in headers. This propagation keeps the remote step under the same trace.

Put the trace ID into your structured logs too. Now a log line and its full trace point at each other, and debugging gets dramatically faster.

Spans are sent to a backend through an exporter, often via the OTLP protocol. The backend then draws the timeline you click through.

Let us confirm the trace structure.

You can now trace a call end to end with spans under one trace ID, enriched with attributes, error status, and logs that link straight back. 🗺️