Langfuse v4, día 2 (1 de 8): el modelo de datos cambió debajo, y qué entra de verdad en una traza

Sat, 12 Sep 2026 07:00:00 +0200

Primer artículo de una serie de ocho sobre operar Langfuse v4 en producción. La arquitectura de la versión 3 y sus diez palancas de rendimiento ya se trataron en Langfuse por dentro; la costura con el gateway, en el par operativo. Esta serie trata el día 2. Verificado contra Langfuse 4.35.0, commit del 11 de septiembre de 2026.

TL;DR

La versión 4 es primero observaciones. No hay tabla de trazas. Una traza es un conjunto de observaciones que comparten identificador, y los atributos de traza viven desnormalizados en cada fila: nombre, usuario, sesión, etiquetas, versión, entrega y entorno (clickhouse/migrations/canonical/0039_create_events_full.up.sql). Toda la intuición de “primero creo la traza y luego le cuelgo cosas” deja de describir el almacenamiento.

Los tipos de observación son diez, no tres. A los clásicos SPAN, EVENT y GENERATION se suman AGENT, TOOL, CHAIN, RETRIEVER, EVALUATOR, EMBEDDING y GUARDRAIL (packages/shared/src/domain/observations.ts:5). Usar el tipo correcto cambia lo que la interfaz sabe agrupar.

Los límites reales están en el código y no coinciden con lo que se supone. El cuerpo de una petición a la ingesta clásica está topado en 4,5 MB (api/public/ingestion.ts:40). El cuerpo OTLP, en 512 MiB, comprimido y descomprimido, con 413 al superarlo. Un span OTLP por encima de 9,5 MB solo se registra en el log, no se rechaza. Los identificadores admiten 800 caracteres. El nombre de traza, 1.000.

El ingestor busca el usuario en cinco sitios y la sesión en seis. Con orden de precedencia estricto, empezando por los atributos propios de Langfuse y terminando en los metadatos de otros marcos. Entre los de sesión aparece gen_ai.conversation.id, que es el estándar de OpenTelemetry, así que una instrumentación conforme funciona sin traducción.

Los scores no viajan por OTLP. Cero ocurrencias de la palabra en las 3.864 líneas del procesador de ingesta OTLP. Entran por la ruta de ingesta clásica, por el endpoint de scores o por la interfaz. Cualquier diseño que dé por hecho que un evaluador puede escribir su puntuación por el mismo canal que la traza está equivocado.

La función de enmascarado clásica no cubre lo que casi todo el mundo cree. Solo actúa sobre datos que pasan por las llamadas del SDK. Los atributos que produce una instrumentación automática de terceros salen sin enmascarar. Hay una función nueva que sí actúa sobre los atributos del lote, pero deja fuera los eventos de span, que es donde las convenciones recientes meten los mensajes.

Filtrar por etiquetas o por mensaje de estado es un escaneo. En la tabla de listados, los campos indexados son el identificador de span, el de traza, el de usuario, el de sesión, las fechas, el modelo y los nombres de metadato. El nombre, las etiquetas, la versión y el mensaje de estado no tienen índice.

Estás aquí: OBSERVE, día 2

La serie anterior sobre este par cubrió la elección y el montaje. La arquitectura de seis servicios explicaba la versión 3; el tracing con OpenTelemetry explicaba el pipeline; el par con el gateway explicaba dónde se pierde la traza entre las dos piezas.

Lo que queda sin cubrir es el trabajo de los tres años siguientes: migrar, dimensionar ClickHouse, retener y borrar, hacer copias, alertar, sacar los datos fuera. Esta serie va de eso, y empieza por la pregunta que condiciona todo lo demás, que es qué se guarda.

La analogía: el archivo que cambió de sistema

Un archivo con carpetas por expediente y documentos dentro de cada carpeta es fácil de entender. Se abre la carpeta, se mira lo que hay. El problema aparece cuando hay que buscar todos los documentos de un tipo en los últimos dos años: hay que abrir todas las carpetas.

Los archivos grandes resuelven eso al revés. No hay carpeta: cada documento lleva copiada en su cabecera la referencia del expediente, el nombre del cliente y la fecha. Buscar por cliente es inmediato. Reconstruir un expediente es agrupar por referencia. A cambio, cada documento pesa un poco más, y lo que se escribe en esa cabecera importa mucho, porque de ahí sale todo lo que se puede buscar.

Langfuse v4 hizo exactamente ese cambio. Lo que antes era una carpeta con atributos propios ahora va repetido en la cabecera de cada documento. De ahí salen las dos consecuencias operativas del artículo: qué campos conviene rellenar y qué campos no conviene llenar de contenido.

El modelo de datos, como está en el código

Las tablas

Tres piezas nuevas en ClickHouse:

events_full (migración 0039): la tabla de verdad, con la entrada y la salida completas, comprimidas con ZSTD nivel 3 e indexadas con índices de texto completo sobre las versiones en minúscula. Motor ReplacingMergeTree ordenado por marca de tiempo del evento y bandera de borrado, particionado por mes de la hora de inicio.
events_core (migración 0040): la tabla de listados, más ligera.
events_core_mv (migración 0041): la vista materializada que rellena la anterior, y que trunca a doscientos caracteres la entrada, la salida y cada valor de metadato.

Ese truncado a doscientos caracteres es la primera cosa que hay que saber. Lo que se ve en un listado no es lo que hay guardado; es un recorte. Y al leer una traza completa se aplica además un segundo tope, LANGFUSE_SERVER_SIDE_IO_CHAR_LIMIT, con valor por defecto de mil (packages/shared/src/env.ts:513).

En la tabla events_full hay una línea de configuración que dice mucho: index_granularity_bytes = '64Mi', con el comentario de que evita gránulos muy pequeños debido a filas grandes. Es el propio esquema reconociendo que las filas de este sistema son voluminosas.

Los diez tipos de observación

SPAN, EVENT, GENERATION, AGENT, TOOL, CHAIN, RETRIEVER, EVALUATOR, EMBEDDING y GUARDRAIL (domain/observations.ts:5), con sus eventos de ingesta correspondientes (server/ingestion/types.ts:279).

Para una plataforma con agentes, la diferencia entre marcar una llamada a herramienta como SPAN genérico o como TOOL es la diferencia entre poder contar llamadas a herramienta por sesión y tener que reconstruirlo a mano. Vale la pena revisar la instrumentación con esta lista delante.

El nivel sigue siendo DEBUG, DEFAULT, WARNING y ERROR (domain/observations.ts:31), con un mensaje de estado libre.

Los límites, con su origen

Campo	Límite	Fichero
Identificadores de traza, span y observación	800 caracteres, sin retorno de carro	`ingestion/types.ts:10`
Nombre de traza	1.000 caracteres	`ingestion/types.ts:428`
Entorno	40 caracteres, patrón de minúsculas, dígitos, guion y guion bajo	`ingestion/types.ts:226`
Score de tipo texto	500 caracteres	`domain/scores.ts:44`
Nombre de configuración de score	35 caracteres	`domain/score-configs.ts:11`
Cuerpo de la ingesta clásica	4,5 MB por petición	`api/public/ingestion.ts:40`
Cuerpo OTLP	512 MiB, ajustable	`web/src/env.mjs:583`
Span OTLP considerado grande	9,5 MB, solo se registra	`packages/shared/src/env.ts:193`
Nombre, mensaje de estado, versión, entrega, etiquetas	sin límite declarado	`ingestion/types.ts:424`
Metadatos	sin límite declarado	`ingestion/types.ts:425`

Los dos últimos son los peligrosos, porque no tienen tope de esquema y el techo real acaba siendo el del cuerpo de la petición. Un metadato de tres megas pasa la validación y llega hasta ClickHouse.

Un apunte sobre el prefijo langfuse en el campo de entorno: está reservado para las trazas internas del propio producto y se elimina de forma idempotente en las entradas públicas (ingestion/types.ts:228), incluido el caso de quien intente colarlo duplicado. El valor por defecto es default.

Sobre los límites de tasa: en la nube hay cuotas por plan, pero en self-hosted no se aplican. El servicio devuelve directamente que no hay limitación (features/public-api/server/RateLimitService.ts). Es una buena noticia para exportaciones masivas y una mala para quien confíe en ese mecanismo como protección.

Las dos vías de instrumentación

Lo que se pierde por OTLP, y es una cosa concreta

La comprobación es sencilla y el resultado es tajante: no hay ninguna ocurrencia de la palabra score en el procesador de ingesta OTLP, un fichero de 3.864 líneas. Los scores solo entran por tres sitios: el evento score-create de la ruta de ingesta clásica, el endpoint POST /api/public/scores, o la interfaz.

Esto tiene una consecuencia de diseño que conviene tener clara antes de montar evaluadores: la traza puede viajar por el colector de OpenTelemetry con todo lo bueno que eso trae, cola en disco, reintentos y muestreo, pero la puntuación que le ponga un evaluador tiene que ir por un canal distinto y con las claves del proyecto.

Todo lo demás sí viaja por OTLP. Lo que no está en las listas de mapeo se conserva como metadato convertido a cadena, visible pero fuera de los campos indexados.

La cadena de precedencia, que es el mapa que hay que tener

Verificado en packages/shared/src/server/otel/OtelIngestionProcessor.ts:

Identificador de usuario (línea 2545), en este orden: langfuse.user.id, user.id, el metadato de observación, el metadato de traza, y por último el metadato del SDK de Vercel.

Identificador de sesión (línea 2565): langfuse.session.id, session.id, gen_ai.conversation.id, metadato de observación, metadato de traza, metadato de Vercel.

Entorno (línea 2383): langfuse.environment, deployment.environment.name, deployment.environment; en cada clave se miran primero los atributos del span y después los del recurso.

Modelo (línea 2753): langfuse.observation.model.name, gen_ai.response.model, ai.model.id, gen_ai.request.model, llm.response.model, llm.model_name, model.

Nivel (línea 1250): el atributo propio, con alias aceptados donde SUCCESS y OK pasan a DEFAULT, WARN a WARNING y FATAL o CRITICAL a ERROR; si no hay atributo y el estado del span es de error, sale ERROR.

Etiquetas (línea 3227): langfuse.trace.tags, langfuse.tags, metadatos de observación y de traza, metadato de Vercel, y tag.tags.

Entrada y salida (línea 1790): una cadena de unos veinte marcos en orden estricto, empezando por los atributos propios de Langfuse y pasando por Genkit, el SDK de Vercel, el evento estándar de detalles de operación de inferencia de las convenciones a partir de la 1.37, los eventos de mensaje por rol, los atributos de prompt y completion, Logfire, MLflow, TraceLoop, OpenInference y los atributos gen_ai.input.messages y gen_ai.output.messages.

Que esa cadena tenga veinte entradas dice algo sobre el estado real de las convenciones: ya se apuntó que las convenciones de IA generativa se extrajeron a su propio repositorio sin ninguna versión publicada. Mientras eso siga así, el backend tiene que adivinar, y adivina con una lista de precedencias.

La parte práctica: si se emiten los atributos propios de Langfuse, ganan siempre. Si se quiere instrumentación neutra respecto al backend, gen_ai.conversation.id y deployment.environment.name son los dos atributos estándar que Langfuse sí entiende.

Los metadatos, y cómo acaban en la tabla

Un metadato se aplana en dos arreglos paralelos, uno de nombres y otro de valores, con rutas separadas por puntos y todo convertido a cadena (otel/utils.ts:239, aplicado en worker/src/services/IngestionService/index.ts:363). Un objeto anidado con veinte claves son veinte entradas en cada arreglo.

Hay un tope de 10.001 posiciones al reconstruir arreglos desde atributos OTel (OtelIngestionProcessor.ts:271), que es alto pero existe.

Sesiones, usuarios y cardinalidad

Una sesión es una columna de texto con un índice de filtro Bloom al 1 %. Lo mismo el usuario. La tabla de Postgres que acompaña a las sesiones guarda solo si está marcada, si es pública y su entorno; no hay contador ni tope. No existe límite de trazas por sesión en el código, y la documentación recomienda identificadores de sesión por debajo de 200 caracteres ASCII.

La diferencia de cardinalidad importa y no es intuitiva: usuario y sesión son texto normal, así que una cardinalidad alta no rompe el esquema, solo infla los filtros Bloom. El entorno, en cambio, es de cardinalidad baja declarada. Generar un valor de entorno dinámico por inquilino degrada ClickHouse de forma medible.

El coste agregado sale de un mapa de detalles de coste con columnas materializadas de entrada, salida y total. El endpoint de sesiones clásico está obsoleto; el sustituto es el de observaciones de la versión 2 con filtro.

Scores: cinco tipos y tres fuentes

Los tipos son NUMERIC, CATEGORICAL, BOOLEAN, CORRECTION y TEXT (domain/scores.ts:45). El booleano exige valor cero o uno. La corrección no admite configuración asociada. El texto está topado a 500 caracteres.

Las fuentes son API, EVAL y ANNOTATION. La fuente EVAL está reservada para los evaluadores internos: la API pública solo acepta las otras dos. Los scores de anotación exigen una configuración asociada salvo el de corrección.

Sobre lo que cuesta dinero, una precisión que corrige una creencia extendida: en 4.35.0 el permiso de número de evaluadores basados en modelo está en ilimitado en todos los planes, incluida la edición abierta (features/entitlements/constants/entitlements.ts:60). Lo que sí está limitado por plan es el número de colas de anotación y los días de acceso a datos. Y hay un matiz de versión: los evaluadores a nivel de traza quedan descontinuados en la versión 4.

Enmascarado, y lo que no cubre

Esta es la parte que hay que leer dos veces si el despliegue tiene que cumplir algo.

La función clásica del SDK de Python tiene la firma masking_function(*, data, **kwargs) y cubre solo los datos que pasan por las llamadas del SDK: creación de observación, actualización, y fijación de entrada y salida de la traza. No cubre los atributos OTel crudos que produce una instrumentación automática de terceros.

El sustituto es una función que actúa sobre los atributos y los atributos de recurso en el lote de exportación. Esa sí alcanza a la instrumentación automática, con una limitación declarada en la documentación: no puede cambiar el nombre del span, los identificadores, la relación con el padre, los atributos de recurso, los eventos ni los enlaces.

Y ahí está el hueco que importa: las convenciones de IA generativa a partir de la 1.37 meten los mensajes y las respuestas en eventos de span. Es decir, la ruta por la que llegan los prompts en una instrumentación moderna es precisamente la que el enmascarado nuevo no toca.

Para un despliegue con datos personales, la conclusión es que el enmascarado de cliente no basta y hay que poner un procesador de redacción en el colector. Es el mismo razonamiento que llevó en el artículo anterior a recomendar el colector en medio, y se suma al problema ya documentado de los argumentos de herramienta MCP que se escriben en claro saltándose el interruptor de redacción de mensajes.

Del lado del servidor no hay red de seguridad: Langfuse no tiene enmascarado de datos personales en servidor. La clave de cifrado que se configura protege secretos, es decir credenciales de proveedores de modelos, cabeceras de integraciones y configuraciones de SSO. Las entradas y salidas de las trazas no se cifran a nivel de aplicación.

Control de volumen

Tres palancas, en orden de a qué altura actúan:

En el SDK: sample_rate, o la variable LANGFUSE_SAMPLE_RATE, con muestreo de cabecera a nivel de traza. Si la traza no se muestrea, tampoco viajan sus observaciones ni sus scores. LANGFUSE_TRACING_ENABLED en falso lo apaga entero.

En el colector: muestreo probabilístico y muestreo de cola. Es la única capa donde se puede decidir en función del resultado, es decir quedarse con todos los errores y con una fracción del resto.

En el servidor: un muestreo determinista por proyecto, con hash SHA-256 del identificador de traza (server/ingestion/sampling.ts). Determinista por traza, así que no parte trazas por la mitad.

Qué no meter en una traza

Con el esquema delante, la lista es concreta.

No filtrar por etiquetas ni por mensaje de estado. En la tabla de listados los campos con índice son el identificador de span, el de traza, el de usuario, el de sesión, las fechas de creación y actualización, el nombre de modelo, el identificador de experimento y los nombres de metadato. El nombre, las etiquetas, la versión, la entrega y el mensaje de estado no. Filtrar por ellos escanea.

No usar los metadatos como almacén. Se aplanan a arreglos de cadenas, se truncan a doscientos caracteres en la tabla de listados pero se guardan enteros en la tabla completa, y encima se indexan con un índice de texto completo con segmentación por caracteres no alfabéticos. Un metadato voluminoso multiplica el índice invertido, no solo el dato.

No guardar prompts completos sin pensarlo. La entrada y la salida llevan compresión ZSTD nivel 3 y dos índices de texto completo sobre sus versiones en minúscula. Guardar el contexto entero de una llamada agéntica de 142.000 tokens en cada turno infla el índice invertido de forma desproporcionada. El truncado del cliente es la palanca barata.

No usar el entorno para separar inquilinos. Es de cardinalidad baja, tiene 40 caracteres de tope y no aísla nada: mismo proyecto, mismas claves, mismos límites, misma retención. Sirve para segmentar paneles. El aislamiento de verdad son proyectos separados, como ya se planteó en el artículo de las costuras.

La versión 3 y la fecha del calendario

La constante está en el código: V3_SUNSET_DATE = "2026-11-16" (features/public-api/server/deprecations.ts:11).

Conviene precisar qué significa, porque la documentación pública y el código no dicen exactamente lo mismo. El comentario del código es literal: la ruta de ingesta clásica no se apaga nunca y sigue aceptando eventos de score; los eventos de traza y observación fallan solo en el modo de escritura exclusivo de la versión 4, no en los modos mixto ni clásico. Y cuando fallan, fallan por evento, no por lote.

La cabecera x-langfuse-ingestion-version: 4 activa la escritura directa a la tabla de eventos, que es la ruta en tiempo real. Sin ella se toma el camino diferido. Los SDK recientes la mandan solos. Cualquier valor por encima de cuatro se rechaza.

En cuanto a nombres, los atributos de entrada y salida a nivel de traza quedan obsoletos en favor de los de observación sobre el span raíz. Los endpoints de lectura clásicos llevan una marca de obsolescencia en el cuerpo de la respuesta, y sus sustitutos son la versión 2 de observaciones, la 3 de scores y la 2 de métricas. Y las ejecuciones de conjunto de datos pasan a llamarse experimentos.

Hay una pieza curiosa que merece mención porque aparece en los paneles de Redis y despista: una cola llamada de uso de API clásica de la versión 4, que no ingiere nada. Es una tarea periódica cada quince minutos que escanea el registro de consultas de ClickHouse para detectar qué proyectos siguen usando la API antigua, y materializa el resultado en Redis para el aviso de migración de la interfaz.

Cómo queda esto en código

Dos piezas, la del cliente y la del colector.

Del lado de la aplicación, lo que cambia respecto a la instrumentación de siempre es el tipo de observación y el sitio del que sale la identidad:

from langfuse import get_client, propagate_attributes

lf = get_client()

# la identidad se propaga por contexto, no observación a observación
with propagate_attributes(
 session_id=id_conversacion, # el mismo en todos los turnos
 user_id=sujeto_del_token, # del claim, no del cuerpo
 environment="produccion",
 tags=["soporte", "n2"],
):
 # el tipo importa: la interfaz agrupa por él
 with lf.start_as_current_observation(
 as_type="agent", name="resolver-incidencia"
 ) as raiz:

 with lf.start_as_current_observation(
 as_type="tool", name="buscar_en_inventario"
 ) as herramienta:
 resultado = mcp.call("buscar", args)
 # truncar aquí, no en el servidor
 herramienta.update(output=str(resultado)[:4000])

 # el score va por su propio canal, nunca por OTLP
 lf.score_current_trace(name="resuelta", value=1, data_type="BOOLEAN")

El parámetro as_type admite nueve literales: span, generation, embedding, agent, tool, chain, retriever, evaluator y guardrail. El décimo tipo del modelo, el evento, tiene su propio constructor porque no abre un ámbito.

Del lado del colector, el procesador de redacción que compensa lo que el enmascarado del SDK no alcanza:

processors:
 redaction:
 allow_all_keys: true
 blocked_values:
 - '\b\d{8}[A-HJ-NP-TV-Z]\b' # DNI
 - '\b[\w.+-]+@[\w-]+\.[\w.]+\b' # correo
 summary: silent
 tail_sampling:
 policies:
 - name: errores
 type: status_code
 status_code: {status_codes: [ERROR]}
 - name: resto
 type: probabilistic
 probabilistic: {sampling_percentage: 5}

exporters:
 otlphttp/langfuse:
 endpoint: http://langfuse-web.observabilidad.svc:3000/api/public/otel
 headers:
 Authorization: "Basic ${LANGFUSE_BASIC}"
 x-langfuse-ingestion-version: "4"
 sending_queue:
 enabled: true
 storage: file_storage
 retry_on_failure:
 enabled: true

El endpoint lleva la ruta base sin el sufijo de la señal: el exportador añade el suyo. Y la cola en disco es la razón principal de meter el colector en medio, porque el procesador de lotes del SDK descarta cuando se llena.

Checklist de instrumentación

Revisar el tipo de cada observación contra la lista de diez. Las llamadas a herramienta como TOOL, los agentes como AGENT, los guardrails como GUARDRAIL.
Decidir de dónde sale el identificador de usuario y fijarlo en un solo sitio, arriba en la cadena de precedencia.
Emitir gen_ai.conversation.id si se quiere instrumentación neutra, o el atributo propio de Langfuse si no importa acoplarse.
Fijar el entorno con deployment.environment.name, con pocos valores distintos y nunca uno por inquilino.
Sacar los scores por su canal propio, con las claves del proyecto, y no esperar que viajen con la traza.
Truncar entrada y salida en el cliente antes de enviarlas, especialmente con contextos agénticos largos.
Poner un procesador de redacción en el colector, porque el enmascarado del SDK deja fuera los eventos de span.
No filtrar por etiquetas en paneles que se consulten a menudo.
Mandar la cabecera de versión de ingesta, o usar SDK recientes que la manden solos.
Revisar el tamaño de los metadatos: no hay tope de esquema, el tope es el del cuerpo de la petición.

Trampas y cosas que no son lo que parecen

Lo que se ve en un listado está truncado a doscientos caracteres por la vista materializada, y la lectura completa tiene otro tope de mil. El dato está entero en la tabla de eventos completa.

Los metadatos no tienen límite de tamaño en el esquema. Un blob de megas pasa la validación.

Un span OTLP de más de 9,5 MB no se rechaza, solo se registra. No hay señal hacia el cliente.

El entorno tiene cardinalidad baja declarada. Un valor por inquilino degrada ClickHouse.

Los scores no viajan por OTLP. Es por ausencia en el código, no por configuración.

El enmascarado clásico no cubre la instrumentación automática, y el nuevo no cubre los eventos de span, que es donde las convenciones recientes ponen los mensajes.

Langfuse no cifra entradas ni salidas de traza. La clave de cifrado protege credenciales de integraciones.

En self-hosted no hay límites de tasa en la API. No sirve como protección.

La ruta de ingesta clásica no se apaga el 16 de noviembre, cambia de comportamiento según el modo de escritura, y falla por evento en lugar de por lote.

Los evaluadores basados en modelo no están limitados por plan en esta versión, contra lo que suele suponerse. Lo que sí lo está son las colas de anotación y los días de acceso a datos.

La serie: los ocho artículos

Este es el primero. El orden está pensado para que cada uno se pueda leer suelto y para que juntos cubran el día 2 completo.

Qué entra en una traza (este artículo): modelo de datos de la versión 4, límites, precedencias, scores, enmascarado e índices.
Migrar de la versión 3 a la 4 sin ventana: los tres pasos del modo de escritura, las migraciones de fondo reanudables y dónde está el punto de no retorno del retroceso.
Las colas del worker: el mapa de las treinta y nueve, qué pool dedicar a cada grupo, los interruptores por cola, el particionado y la concurrencia.
Capacidad y coste real de ClickHouse: cómo medir los bytes por observación con las tablas del sistema, la diferencia entre la tabla completa y la de listados, y el coste de fusión de los índices de texto completo.
Retención, borrado y protección de datos: por qué un borrado no libera disco, el limpiador de máscaras que viene desactivado, la cola de borrados pendientes y el ciclo de vida de S3 que hay que implementar a mano.
Copias de seguridad y recuperación cruzada: orden de restauración entre Postgres, ClickHouse y el almacenamiento de objetos, qué rompe cada desajuste, y hasta dónde llega la reproducción de eventos.
Runbook de saturación: qué alertar de las métricas de cola, las sondas de atasco, el drenado por el endpoint de preparación y la cola de mensajes fallidos.
Sacar los datos fuera: la integración de almacenamiento de objetos a Parquet, las exportaciones por lotes y la API de métricas, para montar el lago de datos.

Ver también

Langfuse por dentro: la arquitectura de seis servicios y las diez palancas de rendimiento de la versión 3.
LiteLLM y Langfuse: el par operativo: las cuatro colas donde se pierde la traza entre las dos piezas.
El gateway no vive solo: por qué el usuario de la traza no es el de Keycloak, y cuándo meter un colector en medio.
Tracing LLM con OpenTelemetry GenAI: el pipeline y las convenciones semánticas.
Prompt versioning con Langfuse y MLflow: la otra capa de la herramienta.
Evals: la capa después del tracing: dónde encajan los scores.

Fuentes

Código de Langfuse 4.35.0, commit 39e3cd7d del 11 de septiembre de 2026.
Anuncio de Langfuse v4, 17 de agosto de 2026.
Compatibilidad y migración, consultado el 12 de septiembre de 2026.
Sesiones, muestreo y enmascarado, consultados el 12 de septiembre de 2026.
Integración nativa con OpenTelemetry, consultado el 12 de septiembre de 2026.

Trazas on lo0 — Blog Técnico