Shrutam CCA-F Crash › Domain 5 › d5-l06-telemetry-logging Hinglish English →

Telemetry and Observability — What to Log

Domain 5 · 15% ~12 min Hinglish narration

Audio-only (commute / mobile data)

Same Saavi narration, smaller file. Opus 48k preferred — auto-selected by your browser.

Scenario anchor

Aap Aaranya IT BFSI ke ek large-scale Claude deployment pe kaam kar rahe hain — ek regulatory document review pipeline jo 180,000-token context windows use karta hai RBI circular processing ke liye. Ek fine day, responses suddenly truncate hone lagte hain aur koi nahi jaanta kyun — koi logs nahi, koi trace nahi, bas unhappy compliance officers. Yeh lesson resolve karta hai exactly woh gap: Claude-powered systems mein "what to log" ka decision framework, taaki aap production mein blind na rahein.

Key Takeaways

Log structured telemetry per segment: system-prompt tokens, retrieval-chunk tokens, history tokens, and tool-result tokens as separate fields — not just a single aggregate count — so you can pinpoint budget pressure by layer.
Always capture context-utilization percentage (tokens_used / context_window_limit) as a derived metric and set alerting thresholds at 80% and 95% to catch approaching truncation before users do.
Attach a distributed trace correlation-id that spans the retrieval, prompt-assembly, and inference steps; without this, a truncation event in the Claude response cannot be joined back to the upstream chunking or embedding decision that caused it.
Memory anchor: treat the correlation-id as your distributed-trace contract — same discipline you apply to any service-mesh inter-hop trace header, applied now to every token-budget boundary crossing.

← Previous lesson Same lesson in English Next lesson → Back to overview