Recipe: metrics against limits
Ten records summarised and compared with limits. Cost is in micro-dollars (1,000,000 = 1 dollar) using example prices.
One wrapper around any model that leaves a redacted JSON log line, a trace span and a metrics record for every call, plus a small summary that checks the metrics against limits. Copy it and plug in your real client.
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 a Recorder class with a method record(status, latency_ms) and a method summary() that returns "calls=N errors=N". Use it with three calls: ok, error, ok.
Write check_limits(summary, limits) where both are dicts; return a sorted list of the names whose summary value is greater than the limit.
Explain it without notes
Why wrap the model in one place instead of logging at each call site?
Why should the wrapper record a failed call and then re-raise the error?
How do you make sure instrumentation does not leak private data?
Expected output
error_rate_percent: 10 (limit 15) -> ok
p95_latency_ms: 3100 (limit 2500) -> ALERT
cost_per_request_micro_dollars: 634 (limit 900) -> ok
1 of 3 checks need attention