What is a Trace?
A trace records the full execution path of a request—from the user’s initial input through every LLM call, tool invocation, and retrieval step to the final response. Traces are trees of spans connected by parent–child relationships.All spans in a trace share the same
trace_id, which uniquely identifies the trace.Trace Structure
Let’s explore a simple trace with two units of work, represented as spans:Root Span (Query)
- It has a
trace_idfield indicating the trace - It has no
parent_id—this is how you identify a root span - It represents the top-level operation (a query to the LLM application)
Child Span (LLM Call)
- It shares the same
trace_idas the root span - It has a
parent_idthat matches thespan_idof the query span - This parent-child relationship creates the trace hierarchy
These blocks of JSON all share the same
trace_id, and the parent_id field represents a hierarchy. That makes it a trace!Trace Hierarchy
Traces form tree structures where:- The root span has no parent (
parent_idisnull) - Child spans reference their parent’s
span_idviaparent_id - Multiple spans can share the same parent (siblings)
- Spans can be nested to arbitrary depth
Context Propagation
Context propagation ensures that all operations in a distributed system are connected to the same trace. When a span creates child operations:- The current
trace_idis propagated to all child spans - The parent’s
span_idbecomes the child’sparent_id - Context attributes (session ID, user ID, metadata) are automatically inherited
Context propagation happens automatically when using OpenInference instrumentation libraries.
Span Context
Span context is an immutable object on every span that contains:| Field | Description |
|---|---|
trace_id | The trace ID representing the trace that the span is a part of |
span_id | The span’s unique identifier within the trace |
Traces as Structured Logs
One way to think of traces is that they’re a collection of structured logs with context, correlation, hierarchy, and more baked in. However, these “structured logs” can come from different parts of your application stack:- Vector store retrieval
- LangChain tools
- Multiple LLM calls
- Embedding generation
- Guardrail checks
Tracing Components
Tracer
A Tracer creates spans containing information about what is happening for a given operation, such as a request to an LLM or a tool invocation.Trace Exporters
Trace exporters send traces to a consumer. This consumer can be:- Standard output for debugging and development
- An OpenInference collector
- An observability backend (Phoenix, Arize, etc.)
Example: Multi-Step Trace
Here’s a typical trace for a RAG (Retrieval-Augmented Generation) application:Spans can overlap in time when operations happen in parallel, but the parent-child relationships always form a tree structure.
Context Attributes
Context attributes are automatically propagated to all spans in a trace:| Attribute | Description |
|---|---|
session.id | Unique identifier for the session |
user.id | Unique identifier for the user |
metadata | JSON string of key-value metadata |
tag.tags | List of string tags for categorization |
Next Steps
Spans
Learn about the building blocks of traces
Span Kinds
Explore different types of spans
Attributes
Understand attribute conventions