Sesiones, trazas y spans en observabilidad LLM: uno de estos no es un nivel estructural

Sesiones, trazas y spans en observabilidad LLM: uno de estos no es un nivel estructural

La página de términos de Datadog, el primer resultado de Google para «sesiones, trazas y spans en observabilidad LLM», define dos de esas tres palabras. No tres. La que falta se corresponde con gen_ai.conversation.id, y la razón de su ausencia es que la spec de OpenTelemetry nunca la convirtió en un nivel estructural. Si necesitas argumentos a favor de la observabilidad en sí, empieza aquí. Este artículo retoma el tema donde ese lo deja: el modelo de datos.

Conclusiones clave

• Los spans se anidan dentro de las trazas; las trazas se agrupan en sesiones. El anidamiento va de dentro hacia fuera: span, luego traza, luego sesión.
• Un span es una operación medida en el tiempo. Una traza es una petición de extremo a extremo. Una sesión es una conversación de varios turnos.
• Las convenciones GenAI de OpenTelemetry definen los spans y el atributo gen_ai.conversation.id. No definen un nivel de sesión.
• Los IDs de traza y de span se propagan automáticamente a través del contexto. El ID de sesión, no. Lo asignas tú, en cada turno.

Sesiones vs. trazas vs. spans, de un vistazo

En la observabilidad LLM, un span es una operación medida en el tiempo (una llamada al modelo, un paso de recuperación), una traza es el árbol de spans que produce una petición, y una sesión agrupa muchas trazas de la misma conversación. El anidamiento va hacia dentro: spans dentro de trazas, trazas dentro de sesiones. La tercera agrupación es la que no es lo que parece.

Esas cifras de cantidad y duración son rangos típicos que puedes esperar en un chatbot RAG o un bucle de agente, no mediciones de una prueba controlada. Tus números serán distintos. Lo que no cambiará: la fila de Sesión es la que no es un nivel estructural en la spec, y la sección «Sesiones: el nivel que tu herramienta probablemente inventó» lo demuestra.

Qué es un span y qué es un tipo de span

Un span es una operación medida en el tiempo con un nombre, una marca de tiempo de inicio, una marca de tiempo de fin, un código de estado y un conjunto de atributos clave-valor. En el trazado LLM, los atributos son el lugar donde viven los datos útiles: gen_ai.usage.input_tokens, gen_ai.usage.output_tokens y gen_ai.request.model te dicen cuánto costó la operación y qué modelo la ejecutó.

Un span es una operación, no una llamada a función

Cada span lleva un puntero de ID de span padre (vacío en el span raíz) que construye el árbol. El conjunto de atributos es abierto: le adjuntas el contexto que necesites. Las convenciones de spans GenAI de OpenTelemetry (estado: Desarrollo) exigen gen_ai.operation.name y gen_ai.provider.name en cada span GenAI, y recomiendan los atributos de uso de tokens mencionados arriba.

Una regla práctica de la página de términos de Datadog: los spans de LLM, Workflow y Agent pueden servir como span raíz; los spans de Tool, Task, Embedding y Retrieval, no. Es una regla de Datadog, no una universal, pero es el único vendor que la formula, y te ahorra construir una traza que empieza en una llamada a herramienta sin padre.

Tipos de span: la misma idea, cinco vocabularios

Toda herramienta necesita una forma de decir «este span es una llamada al modelo» frente a «este span es una recuperación». Solo que no se ponen de acuerdo en la palabra:

La spec de OpenInference lista diez tipos. Datadog lista siete. OTel toma una tercera vía: su registro de atributos GenAI publica 15 valores conocidos para gen_ai.operation.name (chat, create_agent, create_memory, create_memory_store, delete_memory, delete_memory_store, embeddings, execute_tool, generate_content, invoke_agent, invoke_workflow, plan, retrieval, search_memory, text_completion) y establece que, si uno de ellos aplica, DEBE usarse ese valor; un valor personalizado SOLO puede usarse cuando ninguno encaja. Así que es un enum semiabierto, no la ausencia de uno. Tres listas, tres longitudes y ninguna alineación entre ellas. Si estás eligiendo herramienta, esta brecha de vocabulario importa más que la lista de funcionalidades, porque es lo que indexará tus dashboards y filtros de alertas.

Qué es una traza y por qué importa la forma de árbol

Una traza es el árbol de spans que produce una petición. Un span raíz se sitúa en la cima; todos los demás spans cuelgan de él mediante aristas de ID de span padre. La forma de árbol es la clave: un log plano te dice que algo fue lento, pero el árbol te dice qué paso fue lento y qué paso produjo la salida incorrecta.

chat_request (root)                         2,340ms
├── retrieval                                 410ms
│   └── rerank                                 85ms
├── chat gpt-4o                             1,720ms
└── tool_call: search_calendar                190ms

Lee ese árbol y el diagnóstico es inmediato: el 74% de la latencia estaba en la llamada al modelo, no en la recuperación. Un log plano de cinco marcas de tiempo te da el mismo total, pero nada de la atribución.

Un bucle de agente hace este árbol más profundo y más ancho que una petición RAG simple. Cada llamada a herramienta genera su propio subárbol; un turno de agente de cinco pasos puede producir fácilmente más de 30 spans bajo una sola raíz. Eso es normal, y es la razón de que exista la pregunta sobre granularidad de spans más abajo.

La distinción entre tracing y logging también importa aquí: el logging registra eventos, el trazado registra causalidad. Si aún estás decidiendo qué loguear frente a qué trazar, nuestro artículo sobre mejores prácticas de logging LLM define ese límite.

Sesiones: el nivel que tu herramienta probablemente inventó

No. Una sesión no es un nivel estructural en las convenciones GenAI de OpenTelemetry. La spec define los spans y el atributo gen_ai.conversation.id (condicionalmente requerido, «cuando esté disponible», estado: Desarrollo), descrito como el identificador único de una conversación o hilo usado para correlacionar mensajes. Los vendors construyen encima su propio objeto de sesión a partir de ese atributo. Nadie más en esta SERP declara el estado de la spec sin rodeos, así que aquí va.

La consecuencia es la frase que este artículo entero existe para entregar:

Una sesión es una clave de agrupación, no un span padre. No se propaga como lo hace un ID de traza; la asignas tú mismo en cada turno.

Falla un turno y ese turno se cae de la sesión. No hay propagación automática de contexto para ella.

¿Cuándo empieza y termina una sesión?

Lo define el vendor. Algunas herramientas abren una sesión con la primera traza que lleva un ID de conversación nuevo y la cierran por un timeout de inactividad (Langfuse usa por defecto una ventana configurable). Otras requieren una llamada de cierre explícita. La spec no dice nada sobre el ciclo de vida porque no modela la sesión como un objeto.

Qué se conserva entre turnos y qué no

La ventana de contexto del modelo no es la sesión. La sesión es una clave de agrupación sobre trazas independientes. Cada turno tiene su propia traza, su propio span raíz, su propio conteo de tokens. Lo que se conserva es el atributo de ID de conversación que marcaste en cada span raíz. Lo que no se conserva: latencia, uso de tokens, estructura de spans. Eso es por traza.

¿Qué mide una métrica a nivel de sesión?

Cosas que una sola traza no puede medir: tasa de resolución (¿resolvió la conversación el problema del usuario?), turnos hasta la respuesta (¿cuántas trazas pasaron antes de que el usuario obtuviera lo que necesitaba?) y conversaciones abandonadas (sesiones sin señal de cierre). Ejecutar evaluaciones sobre trazas en vivo a nivel de sesión es la forma de detectar fallos multiturno que parecen correctos turno a turno.

El código, neutral en vendor

Este fragmento usa solo primitivas estables de OTel. Sin SDK de vendor. Crea un span raíz para un turno, un span hijo para la recuperación, un hijo para la llamada al modelo, y asigna gen_ai.conversation.id para que tres turnos caigan en una sola sesión:

from opentelemetry import trace

tracer = trace.get_tracer("my-llm-app")

SESSION_ID = "conv-8f3a2c"  # same value on every turn

def handle_turn(user_message: str):
    with tracer.start_as_current_span("chat_request") as root:
        # You set this. It does not propagate automatically.
        root.set_attribute("gen_ai.conversation.id", SESSION_ID)

        with tracer.start_as_current_span("retrieval") as ret:
            ret.set_attribute("gen_ai.operation.name", "retrieval")
            docs = retrieve(user_message)

        with tracer.start_as_current_span("chat gpt-4o") as llm:
            llm.set_attribute("gen_ai.operation.name", "chat")
            llm.set_attribute("gen_ai.provider.name", "openai")
            llm.set_attribute("gen_ai.request.model", "gpt-4o")
            response = call_model(user_message, docs)
            llm.set_attribute("gen_ai.usage.input_tokens", 1_204)
            llm.set_attribute("gen_ai.usage.output_tokens", 312)

    return response

Llama a handle_turn tres veces con el mismo SESSION_ID y las tres trazas se agrupan bajo una sola sesión en cualquier backend que lea el atributo. Cambia el ID y habrás empezado una sesión nueva. Ese es todo el mecanismo.

Leímos la documentación de cinco vendors en paralelo. No se ponen de acuerdo.

El 30 de julio de 2026 leímos en paralelo la documentación actual del modelo de datos de Langfuse, LangSmith, OpenInference / Phoenix y Datadog, además de la spec de spans GenAI de OpenTelemetry. Cuatro de los cinco llaman al mismo objeto con un nombre distinto. Solo uno trata la sesión como un objeto de primera clase en lugar de un atributo. La página de términos de Datadog, el primer resultado de Google para esta consulta, no define la sesión en absoluto.

Una nota de fuentes sobre esa primera fila: el session.id de OpenInference no está en la spec de traces enlazada arriba, que cubre los diez tipos de span. Se define en el archivo hermano de convenciones semánticas de OpenInference como el identificador único de una sesión. Dos archivos, una spec.

No inventamos nosotros la comparación entre vendors; FutureAGI también publica una tabla de OTel frente a vendors. Nuestras dos adiciones son la fila de sesión (FutureAGI la omite) y la trampa de misma palabra con distinto significado: la «observation» de Langfuse y el «run» de LangSmith son el mismo objeto que un span, mientras que los tipos de span de Datadog y de OpenInference son vocabularios distintos para la misma idea.

Langfuse lo llama observation, LangSmith lo llama run, Datadog lo llama span. El mismo objeto, tres dashboards que se rompen cuando migras.

Esa es nuestra lectura del coste de migración, no una afirmación de ningún vendor. Pero es la razón por la que los filtros guardados, las configuraciones de evaluación y las reglas de alerta indexadas en «observation» o «run» dejan de funcionar el día que cambias de herramienta. No estás renombrando un campo. Estás renombrando un nivel. Si estás sopesando esas dos herramientas en concreto, nuestra comparativa Langfuse vs LangSmith entra en más detalle sobre la divergencia.

Puede que los lectores ya tengan en su stack Opik, PostHog, Sentry o Weights & Biases; Google asocia los cuatro con llm tracing, y cada uno mapea estos conceptos de forma ligeramente distinta. ¿Elegir el adecuado? Nuestro resumen de plataformas de observabilidad cubre todo el panorama.

Una nota de actualidad: las convenciones GenAI se han mudado a su propio repositorio, fuera del repo principal de semantic-conventions. La antigua ruta opentelemetry.io/docs/specs/semconv/gen-ai/ ahora solo contiene un puntero.

¿Qué ID va en cada sitio?

Un trace ID identifica una petición y se propaga automáticamente a través del contexto. Un span ID identifica una operación dentro de esa traza, también automático. Un correlation ID (o request ID) proviene de tu capa web antes de que empiece el trazado, y es el que la gente confunde más a menudo con el trace ID. El ID de sesión es el que desentona: te toca asignarlo a ti, manualmente, en cada turno.

La regla práctica: adjunta gen_ai.conversation.id como atributo de span en el span raíz de cada turno y marca junto a él el user ID. Sáltate un turno y tus métricas a nivel de sesión perderán ese turno en silencio.

Un aviso sobre cardinalidad: los user IDs y los session IDs son valores de alta cardinalidad. Eso importa para la factura de indexación de tu backend, que es el problema de la siguiente sección.

¿Cuán granular debe ser un span?

Dos modos de fallo, ambos comunes:

Exceso de spans. Un span por cada llamada a función te da una traza de 400 spans que nadie puede leer y una factura por span que nadie aprobó. Los backends alojados (Datadog, Langfuse Cloud) cobran por volumen de spans. Un bucle de agente parlanchín que instrumenta cada concatenación de strings se ventila el free tier en una tarde.

Defecto de spans. Un solo span para «toda la cadena» te dice que fue lenta, pero no dónde. Acabas volviendo a meter sentencias print, que es justo lo que el trazado debía reemplazar.

La regla general (y es una regla general, no una medición): pon spans en los límites donde ocurre una decisión o una llamada externa.

• Paso de recuperación: ponle span.
• Llamada de rerank: ponle span.
• Cada llamada al modelo: ponle span.
• Cada llamada a herramienta: ponle span.
• Cada comprobación de guardrail: ponle span.
• Transformaciones puras dentro del proceso (formateo de strings, parsing de JSON, ensamblado del prompt): atributos en el span padre, no spans propios.

Sobre cardinalidad, muestreo y retención:

• Los atributos de alta cardinalidad (user IDs, prompts completos) inflan los costes de almacenamiento. Muéstralos o trúncales.
• La mayoría de los backends permiten muestrear a nivel de traza. Conserva el 100% de las trazas con error; muestrea el camino feliz.
• Las ventanas de retención varían: 7 días en los free tiers, 30–90 días en los de pago. Decídelo antes de necesitar los datos.

Para el modelo de costes real detrás del volumen de spans y el precio por span, consulta nuestra guía de monitoreo de costes LLM. No lo reconstruiremos aquí.

Cómo lo aborda Techsy

Para el trabajo con agentes de clientes, nos estandarizamos en tres reglas:

1. Una traza por turno. Nunca fusiones dos turnos de usuario en una sola traza, aunque el agente haga bucles internamente.
2. Un ID de sesión marcado en cada span raíz, asignado en el código de la aplicación, sin asumir nunca que se propaga.
3. Tipos de span limitados a un conjunto pequeño y fijo (recuperación, inferencia, herramienta, guardrail) para que los dashboards sobrevivan a un cambio de vendor.

Esa tercera regla es la que los equipos se saltan, y la que salva una migración. Si tu vocabulario de spans está atado al enum de un vendor, cada alerta y cada vista guardada se rompe el día que cambias.

Si estás construyendo un sistema de agentes y quieres una segunda opinión sobre la arquitectura de trazado, pide una consulta gratuita.

Preguntas frecuentes

¿Qué es un span en el trazado distribuido?

Un span es una unidad de trabajo medida en el tiempo: tiene un nombre, una hora de inicio, una hora de fin, un estado y un conjunto de atributos. Los spans se enlazan entre sí mediante referencias de ID de span padre, formando un árbol. En aplicaciones LLM, un span normalmente envuelve una llamada al modelo, una recuperación o una invocación a herramienta.

¿Qué es un span en Datadog?

En LLM Observability de Datadog, un span es la misma operación medida en el tiempo, pero Datadog añade una taxonomía de span kind: LLM, Workflow, Agent, Tool, Task, Embedding y Retrieval. Solo los tipos LLM, Workflow y Agent pueden servir como span raíz. La taxonomía es específica de Datadog; no forma parte del estándar OpenTelemetry.

¿Cuáles son los cuatro pilares de la observabilidad?

Los cuatro pilares son logs, métricas, trazas y (según el marco de referencia) perfiles o eventos. Las trazas son el pilar en el que vive este artículo. El caso LLM añade un pliegue: el uso de tokens y la identidad del modelo son atributos en los spans de la traza, no flujos de métricas separados, lo que colapsa lo que serían dos pilares en una sola consulta.

¿Cuáles son las cuatro señales doradas de la observabilidad?

Latencia, tráfico, errores y saturación. Para sistemas LLM, latencia significa tiempo hasta el primer token y tiempo total de generación; tráfico significa peticiones por segundo por modelo; errores significa spans fallidos (código de estado ERROR); saturación significa agotamiento del presupuesto de tokens o profundidad de cola. Las señales son las mismas; las unidades difieren.

¿La sesión forma parte de la especificación de OpenTelemetry?

No como nivel estructural. Las convenciones de spans GenAI de OTel definen gen_ai.conversation.id como un atributo condicionalmente requerido («cuando esté disponible») para correlacionar mensajes en una conversación o hilo. Reside en los spans. Vendors como Langfuse y LangSmith construyen encima sus propios objetos de sesión o de hilo.

¿Qué diferencia hay entre un trace ID, un span ID y un correlation ID?

Un trace ID identifica una petición y se propaga automáticamente por todos los servicios posteriores. Un span ID identifica una operación dentro de esa traza. Un correlation ID (o request ID) lo genera tu capa web antes de que empiece el trazado, y es el valor que la gente confunde más a menudo con el trace ID. Se solapan en alcance, pero tienen orígenes distintos.

¿Cuántos spans debe tener una traza?

No hay una respuesta fija, pero los rangos típicos son 3–30 para una petición RAG y 10–50 o más para un bucle de agente con múltiples llamadas a herramientas. La regla general: pon spans en las llamadas externas y los puntos de decisión, no en las transformaciones dentro del proceso. Si tu traza supera los 100 spans, probablemente estás sobre-instrumentando.

¿Las «observations» de Langfuse son lo mismo que los spans?

Sí. Una observation de Langfuse es el mismo objeto que un span de OTel: una operación medida en el tiempo con atributos. Langfuse divide las observations en tres tipos (generation, span, event) donde OTel usa gen_ai.operation.name. Si estás evaluando herramientas que leen tus trazas, nuestro resumen de herramientas de evaluación LLM cubre cuáles aceptan ambos vocabularios.

¿Cómo agrupas una conversación de chatbot de varios turnos en una sola sesión?

Asigna el mismo identificador de conversación en el span raíz de cada turno. En términos de OTel, eso es gen_ai.conversation.id. En Langfuse, pasas un session_id al crear las trazas. En LangSmith, configuras los metadatos session_id o thread_id. Falla un turno y ese turno se cae de la agrupación.

¿Necesito sesiones si solo manejo peticiones de un único turno?

Probablemente no. Las sesiones existen para correlacionar múltiples trazas en una conversación. Si cada petición es independiente (una API de clasificación, un resumidor de un solo disparo), las métricas a nivel de traza son suficientes. Añade sesiones cuando necesites métricas entre turnos: tasa de resolución, turnos hasta la respuesta o coste a nivel de conversación. Nuestra guía de evaluación LLM cubre cuándo las evaluaciones a nivel de sesión valen lo que cuestan.

La versión corta

Los spans se anidan dentro de trazas; las trazas se agrupan en sesiones. El anidamiento es real, pero la spec solo estructura dos de los tres niveles. gen_ai.conversation.id es un atributo que asignas tú mismo, no un span padre que se propaga. Y el vendor que eliges hoy nombra estos objetos de forma distinta al vendor al que te cambiarás en 18 meses, así que mantén tu vocabulario de spans pequeño y portable.

Si estás eligiendo plataforma, empieza con nuestra comparativa de plataformas de observabilidad. Si estás construyendo evaluaciones sobre tus trazas, la guía de evaluación LLM retoma el tema desde aquí.