AI Engineer Portal
Your personal operating system for career transition.
Exercise
Implement distributed tracing spans for LLM calls
Implement Distributed Tracing Spans for LLM Calls
Standard application tracing shows HTTP latency. For LLM pipelines you need per-span visibility: retrieval, prompt assembly, model call, and postprocessing — each with its own latency and metadata.
What to build
A lightweight tracing system (no external dependencies):
-
Spandataclass:trace_id,span_id,parent_id,name,start_time,end_time,attributes: dict,status("ok"/"error"),error_message. Includeduration_msproperty. -
Tracer:start_span(name, parent=None) -> Span— child spans inheritparent.trace_idfinish_span(span, status="ok", error=None)add_attribute(span, key, value)get_trace(trace_id) -> list[Span]— sorted by start_timeexport_trace(trace_id) -> list[dict]— serializable dicts withduration_ms
-
trace_span(tracer, name, parent=None)context manager — starts, yields, finishes (error status on exception).
Why it matters
Without spans, "the request took 3 seconds" tells you nothing about where time was spent. Spans reveal whether the bottleneck was retrieval, prompt assembly, or the model call.
Api Async / medium / Step 17 of 23
Async and provider control
Make waiting behavior explicit. Timeouts, retries, and concurrency limits matter more than squeezing everything into one helper.
- - Uses async boundaries coherently
- - Makes timeout and retry decisions legible
- - Would be maintainable under provider instability
- - Is timeout behavior explicit?
- - Is retryable failure separate from terminal failure?
- - Would logs reveal what actually timed out?
Practice
Generate a variation
Generate a new exercise variation to deepen understanding or practice a related concept.
Attempt history
Recent submissions
Before you submit, decide what a strong answer should make obvious to the reviewer.
No attempts yet.