Skip to main content
AI & Agents

LLM Observability

LLM observability is the practice of tracing and measuring every model call in production — prompts, completions, tool invocations, latency, token usage and cost — so that non-deterministic systems can be debugged and regressions caught. It fills the gap conventional monitoring leaves, because an AI feature can be up, fast and wrong at the same time.

Traditional APM assumes deterministic execution: same request, same response, and a 200 status means success. A language model can return 200 with a fabricated answer, and a provider can shift behaviour underneath you with a silent model update. Uptime and latency dashboards remain necessary and become insufficient; the missing layer records what the model actually did.

The core artefact is the trace: one record per request with a span per model call and tool call, capturing the prompt template version, model name and parameters, token counts, cost and latency. Tool outputs and retrieved passages belong in the trace too, because most agent failures are explained by what the model was shown. PII redaction happens at the collector, before anything is stored, since prompts routinely contain user data.

The metrics that matter are outcome-shaped rather than infrastructure-shaped: cost per successful task, refusal and empty-response rates, groundedness scores from online evaluation, and latency percentiles including time to first token for streaming. OpenTelemetry's GenAI conventions standardise the instrumentation; Langfuse, LangSmith and Helicone provide the backends; and the most valuable feedback loop is the one where production failures are promoted into the evaluation set, so every incident becomes a permanent regression test.

Alerting has to change shape as well. Thresholds on error rates and latency still apply, but the incidents that matter announce themselves differently: a slow drift in groundedness scores after a provider model update, a step change in cost per request after a prompt edit, a refusal rate climbing because a policy tweak backfired. Canary evaluations — a small eval set run continuously against sampled production traffic — catch these within hours rather than in the next quarterly review.

Trace data is sensitive by construction, because prompts contain whatever users typed and whatever the retrieval layer fetched on their behalf. Where traces are stored, who can read them and how long they are kept are architectural decisions with compliance weight, not logging defaults. Redaction at the collector, role-based access to the trace store and retention windows matched to your data policy are the baseline a serious deployment starts from, and retrofitting them after an incident is markedly harder.

Codazz builds this in production — Evaluation & Observability.

FAQ

LLM Observability
FAQ.

Common questions about llm observability.

Ask Us Anything

Normal monitoring answers "is it up and fast"; LLM observability answers "was the output right, what did it cost, and why did the model do that". It adds traces of prompts, completions and tool calls, quality signals from online evaluation, and cost accounting per request — the dimensions that matter when the system is non-deterministic and a green dashboard can hide a wrong answer.

Traces with token and cost accounting, from day one — they are nearly free to add and impossible to backfill. Quality signals come next: user feedback capture, then automated checks on groundedness and policy adherence. Teams that defer tracing end up debugging agent behaviour from anecdote, which does not scale past the first incident.

Partly. Metrics and cost rollups fit into existing dashboards, and OpenTelemetry GenAI spans flow into any compatible backend. Where general-purpose stacks strain is the qualitative side: inspecting prompts and completions, scoring outputs, annotating traces into datasets. Teams typically end up with a specialist tool for trace inspection alongside the existing stack for alerting, rather than forcing either to do both jobs.