> ## Documentation Index > Fetch the complete documentation index at: https://docs.usetuner.ai/llms.txt > Use this file to discover all available pages before exploring further. # OpenTelemetry Traces > Send OpenTelemetry spans from LiveKit Agents, Pipecat, or a custom stack to Tuner and read them as a span tree on the matching call. Available for LiveKit Agents, Pipecat, and any custom stack via the OTLP HTTP exporter. See [Turn on traces](#turn-on-traces). ## Where traces fit [Voice Metrics](/docs/observability/voice-metrics) tells you which turn was slow and which stage dominated it, on every call and with no setup. A trace tells you what ran inside that stage: the model request, the streaming adapter, each tool call. Use it when the stage number does not explain the delay. An LLM stage that was really a slow tool call, or a TTS stage that was slow in the stream adapter rather than at the provider, look identical in a stage breakdown and obvious in a span tree. ## Reading the span tree Tuner renders the trace against a time axis, with each bar positioned relative to the start of the session. Traces tab showing a span tree with agent_session as the root and nested agent_turn, llm_node, llm_request, tts_node, and user_turn spans, each with a duration and a bar on a shared time axis * **Follow the widest bar at each level.** Above, `agent_turn` is 4.84s and the `tts_node` under it is 4.62s, so synthesis dominated that turn, not the model. * **Siblings overlap.** `llm_node` and `tts_node` both start at 00:00, because synthesis streams on the first tokens. Children do not sum to their parent, the same way the pipeline stages do not sum to TTFB. * **Collapse large traces.** The call above has 171 spans. Collapse to the turn level, then expand the one turn you care about. Click a span to open its details. Span detail panel showing the Span, Timing, Status, Attributes, and Resource groups for a turn span lasting 11.52 seconds Span names come from your framework. See [LiveKit traces](/docs/integrations/livekit#opentelemetry-traces) or [Pipecat traces](/docs/integrations/pipecat#opentelemetry-traces). ## Turn on traces Setup lives with your integration. Send traces from LiveKit Agents. Send traces from Pipecat. Send traces from any OTLP-compatible stack via the Direct API. A **Traces** tab appears on the call once spans have arrived and matched. Calls with no trace show no tab. ## What Tuner stores | | | | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Stored** | The span tree: names, timings, parent relationships, status. Metrics and configuration attributes: model names, time to first byte, token counts, turn latency, endpointing settings, tool names and outcomes. | | **Not stored** | Conversation content. Transcripts, LLM inputs and outputs, TTS text, system prompts, and tool call arguments and results are discarded on arrival and never written to disk. | | The attribute filter is an allowlist, so a framework upgrade cannot start sending content that Tuner then retains. Expect around 30 KB per five-minute call. | | Traces are separate from the call record, which is still governed by [PII Redaction](/docs/observability/pii-redaction) and [Data Retention](/docs/observability/data-retention). ## Next steps The per-turn stage breakdown you start from before opening a trace. Working through a single failing call end to end.