Back to course overview
Module 3Observability 22 min
Lab: Add tracing
Instrument your feature with span-based tracing, generate real traffic, build the metrics view, and debug a planted failure from its trace.
Your feature gets eyes. You'll wrap it in tracing, run varied traffic through it, aggregate a metrics view, and then debug a failure using only its trace — the full observe-and-diagnose loop.
Step 1 — Instrument
- 1Add the
Tracerfrom the lesson. Wrap your feature's entry point so every request emits a trace with: full prompt sent, full response, model+version, tokens in/out, cost, latency, and atrace_id. - 2If your feature is multi-step (RAG or agent), open a child span per stage (retrieval, each model call, each tool). The trace should read as the request's whole journey.
- 3Stamp each trace with the feature/prompt version (a constant for now; Module 4 makes it real).
Step 2 — Generate traffic
- 1Run 40–50 varied inputs through the feature: your golden set plus a dozen deliberately weird ones (empty, huge, adversarial, off-topic). You want a realistic spread of traces to aggregate.
- 2Confirm traces are landing in
traces/and are complete — open two by hand and verify you could reconstruct exactly what happened.
Step 3 — The metrics view
- 1Write
dashboard.py: read all traces and print the health view — count, cost total + per-request, latency p50/p95, token averages, and a table of any flagged/validator-rejected requests. - 2Add a sampled online-eval: run your Module 2 judge over a random 20% of the traces and report the average score. This is your production-quality proxy.
- 3Add 'top failures' — group the low-scoring or flagged traces and show the most common pattern.
Step 4 — Debug from a trace
- 1Introduce a planted bug: truncate assembled context to 200 chars before the model call (simulating a retrieval/assembly failure). Re-run traffic.
- 2From the dashboard, spot the quality drop. Pull one bad trace. Practice the debugging order: read what the model saw → localize the span → classify (it's 'bad input to the model', not a dumb model) → confirm.
- 3Fix it, add the failing case to
golden/v2, re-run evals to confirm, and note inLAB-NOTES.md: how the metrics showed it, how the trace localized it, and that the eval now guards it.
Problem set 3
In the workbook: three production traces of wrong-but-fluent outputs. For each, use only the trace to identify the failing span and classify the failure type — and spot the one where the model was fine and the pipeline was the culprit.