Trace

What it means

A trace ties together everything that happened while handling one request. It is the parent container for a tree of spans, where each span is one timed step. A trace for a RAG chatbot answer might contain a span for query embedding, a span for the vector search, a span for prompt assembly, and a span for the final model call - all grouped under one trace id. Because the spans are timestamped and nested, the trace reconstructs both the sequence and the timing of the whole operation.

Why it matters

LLM applications are non-deterministic and multi-step, which makes plain log lines hard to reason about. A trace turns a scatter of log entries into one coherent story you can replay. It answers the questions that matter in production - why was this response slow, where did the cost go, what context was actually retrieved, and at which step did the output go off the rails. Traces also make debugging reproducible, because you can open the exact request a user complained about and inspect every input and output along the way.

In practice

Tracing is the backbone of LLM observability, and every serious platform is built around it. Langfuse and Helicone capture traces automatically once you wrap or proxy your model calls, then let you filter by cost, latency, user, or error to find the traces worth investigating. From a trace you can usually jump straight into evaluation - attaching a score to a specific output - so tracing and evals share the same underlying records. See the guide on how tracing differs from ordinary logging for where the two overlap and where a trace gives you far more.