Traces: visibility into LLM behavior
Learn what traces and spans are, what data they capture, how sampling works, and how to promote real failures into evaluation test cases.
A trace is a structured record of one complete run of your AI system — everything that happened from the moment a request arrived to the moment a response was returned. Traces give you the ground truth you need to understand what your AI is actually doing in production, not what you expect it to do in tests.
Traces and spans
A trace represents the whole workflow. A span represents one individual step inside that workflow — a single LLM call, a tool invocation, a retrieval operation, or any other discrete unit of work.
A simple chatbot request might produce one trace with one span. A RAG pipeline might produce one trace with four spans: embed the query, retrieve documents, re-rank results, and generate the response. The trace holds the end-to-end picture; spans let you isolate latency, cost, and correctness at each step.
What gets captured
Every trace and span records:
Instrumenting your application
Use the SDK to create traces and attach spans wherever your application calls an LLM or performs a step you want to observe.
Multi-step workflows
For pipelines with multiple LLM calls or tool steps, attach one span per step to the same trace. This lets you see the full timeline and pinpoint exactly where latency or quality problems occur.
Asymmetric sampling
For high-volume applications, analyzing every successful request can be expensive and unnecessary. EvalGate uses asymmetric sampling for server-side failure analysis by default:
- 10% of successful traces are queued for analysis
- 100% of error traces and thumbs-down feedback traces are queued for analysis
This controls analysis work after traces are ingested. SDK collector helpers send traces by default unless you configure client-side sampling.
Always send full traces during development and staging. Reserve client-side sampling for production once you have a baseline sense of your traffic patterns and failure rate.
Traces become much more useful when they carry business context alongside the model inputs and outputs. Attach metadata at trace creation time to enable filtering, grouping, and alerting in the dashboard.
Never log sensitive PII inside trace metadata without proper anonymization. EvalGate scrubs PII before sending traces to external judge providers, but raw metadata is stored as-is. Apply anonymization at the application layer before calling createTrace or startWorkflow.
Viewing traces in the dashboard
Once your application is instrumented, open the Traces page in your EvalGate dashboard to:
- Search and filter traces by metadata, tags, model, or time range
- View detailed timelines showing nested spans and their durations
- Analyze token usage and cost breakdowns per step
- Inspect full input and output text for any span
- Debug failures with complete error stack traces
- Identify performance bottlenecks across the workflow
From traces to evaluations
The most important thing you can do with a traced failure is convert it into a permanent test case. EvalGate’s label command walks you through every captured trace and lets you mark each one pass or fail, assign a failure mode, and add it to your golden dataset.
Once labeled and promoted into an eval suite, those traces can become evaluation cases that run on every code change. Real production failures become regression coverage after review or promotion.
See Evaluations for how to build test suites from your labeled traces, and The trace → eval → gate workflow for how the full loop fits together.