A tracer built by hand
Ids come from a counter and time from a simulated clock, so the tree is the same every run. A real tracer reads the real clock and generates random ids.
A trace shows one request as a tree of timed steps: retrieval, model calls, tools. It answers where the time went and links the services a request crosses. OpenTelemetry is the standard way to produce traces.
Change the code and press Run (Ctrl+Enter). Predict what will happen first, then break it on purpose and read what changes. Your edits are saved and match the lesson page.
Ready for more? This phase has 5 hands-on exercises with automatic checks.
Practice questions
Write the code in the editor, run it, then open the model answer to compare.
Write self_times(spans) for spans given as (id, parent, name, start, end) that returns a list of "name self_ms" strings in input order. Self time is total minus the total of direct children.
Write parse_traceparent(header) that returns (trace_id, span_id) as integers, and raises ValueError if the header does not have exactly four parts or the trace id is all zeros.
Explain it without notes
What is a span, and how does a set of spans become a trace?
What is the difference between a span's total time and its self time, and why does it matter?
How does a second service join the trace of the first one?
What should and should not go into span attributes of a model call?
Expected output
span-1 request 1255 ms
span-2 retrieval 45 ms [3 chunks]
span-3 model_call 620 ms [tokens_in=1450]
span-4 tool search_orders 180 ms [status=ok]
span-5 model_call 410 ms [tokens_in=1710]