Distributed tracing connects the operations involved in one application request. For an LLM workflow, a trace can link retrieval, model generation, tool calls, validation, and the final user-visible outcome.
Traces and spans
A trace groups related operations. A span records one operation with timing, status, and context. Parent-child relationships and links help explain which work depends on other work. Use the identifiers and conventions supported by your instrumentation version.
Example: slow support answer
A request searches policy documents, calls a model, looks up an order, and then generates a final answer. Inspect durations at each stage before changing the model. Sequential tool operations or retries may explain most of the delay.
Record useful context safely
Record model and prompt versions, document references, tool outcomes, and sanitized errors. Avoid retaining unnecessary raw personal information. Propagate request context across service boundaries and record whether some events were sampled or lost.
Validate the instrumentation
Run a known request with a failing tool and inspect whether all expected operations appear with the right relationships. Test cancellation and asynchronous work on the actual runtime. A span existing in a dashboard does not establish that every operation was captured.
Integrate using supported methods
Consult the current DriftRail documentation and API reference for supported integration methods. OpenTelemetry semantic conventions are a useful reference, but support depends on the installed instrumentation.
References and further reading
Maintained by DriftRail. AI assisted the October 2026 content and template revision. Examples are illustrative; they are not measured product benchmarks. Suggest a correction.