Aloja Langfuse para rastrear agentes de IA

Por qué rastrear un agente de IA

Puede alojar Langfuse para ver qué hizo realmente su agente durante una ejecución. Langfuse es una herramienta de observabilidad de LLM (modelo de lenguaje grande) de código abierto. Registra cada prompt, cada respuesta del modelo, cada llamada a una herramienta y cada token. Después, agrupa todos esos datos en un único trace que puede abrir y revisar. Si lo ejecuta en su propio VPS, esos prompts nunca salen de un servidor bajo su control.

El motivo es sencillo. No puede corregir un problema de costes o de calidad que no puede ver. La factura del proveedor indica que el martes gastó cuatro veces más que el lunes. Un trace indica qué ejecución del agente lo causó, qué prompt creció hasta 40,000 tokens y qué bucle de reintento se ejecutó nueve veces antes de abandonar. La factura proporciona la cifra. El trace muestra el código que la produjo.

Esta guía utiliza tres términos. Un trace es una ejecución completa del agente, de principio a fin. Una observation es un paso dentro de esa ejecución: un span para el código normal y una generation para una llamada a un modelo. Un score es un número asociado a un trace, procedente de una revisión humana o de un evaluador automatizado. Langfuse es compatible con OpenTelemetry (OTel), el estándar independiente del proveedor para el rastreo distribuido. Por tanto, la instrumentación que ya tenga puede enviar datos a Langfuse.

Qué ejecuta realmente Langfuse en un entorno autogestionado

Langfuse v4 no es un solo contenedor. Consta de dos contenedores de aplicaciones y cuatro servicios de almacenamiento. En un VPS único, los seis se ejecutan en el mismo servidor.

• langfuse-web proporciona la interfaz web y la API de ingesta.
• langfuse-worker vacía la cola en segundo plano. Analiza los lotes de ingesta, calcula los costes y ejecuta el trabajo nocturno de retención.
• Postgres almacena datos transaccionales, como usuarios, organizaciones, proyectos, API keys y prompts.
• ClickHouse almacena los datos de trazas, es decir, observaciones y puntuaciones. Es un almacén columnar diseñado para consultas analíticas. Por eso un dashboard sobre más de cien millones de filas sigue respondiendo con rapidez.
• Redis es la cola y la caché situadas entre web y worker.
• MinIO proporciona almacenamiento de objetos compatible con S3 en el propio servidor. Almacena todos los eventos sin procesar recibidos y cualquier contenido multimedia que adjunte.

Langfuse publica los recursos mínimos para los tres componentes que realizan el procesamiento.

[
  {
    "label": "ClickHouse",
    "cpu_cores": 2,
    "memory_gib": 8
  },
  {
    "label": "Langfuse web",
    "cpu_cores": 2,
    "memory_gib": 4
  },
  {
    "label": "Langfuse worker",
    "cpu_cores": 2,
    "memory_gib": 4
  }
]

ClickHouse requiere por sí solo 8 GiB de memoria. El contenedor web y el worker requieren 4 GiB cada uno. Esas son las cantidades mínimas publicadas para los 3 componentes dimensionados por Langfuse. Postgres, Redis y MinIO también necesitan memoria adicional. La propia guía de Docker Compose del proyecto recomienda una máquina con 4 núcleos, 16 GiB de memoria y unos 100 GiB de almacenamiento. Esa recomendación coincide con el cálculo anterior, sin añadir un margen artificial.

No intente ejecutarlo en un plan de 2 GiB. ClickHouse se inicia y acepta escrituras durante un tiempo, pero después termina durante una combinación en segundo plano, porque una combinación carga partes grandes de una tabla en memoria. Verá que docker compose ps informa de que el contenedor clickhouse está restarting, que dmesg muestra una línea como Out of memory: Killed process 1234 (clickhouse-serv) y que todos los dashboards de Langfuse devuelven 500. Con una carga menor, ClickHouse rechaza la consulta y registra DB::Exception: Memory limit (total) exceeded. Ocho GiB son suficientes para un desarrollador que envíe unos pocos miles de trazas al día. Planifique 16 GiB. Si el mismo VPS también debe ejecutar otros servicios, reserve recursos adicionales para ellos. Incluso una pila relativamente ligera, como un espacio de trabajo AFFiNE autogestionado, necesita sus propios gigabytes y ClickHouse no liberará memoria para ellos.

Implementar Langfuse con Docker Compose

Clone el repositorio. La pila, la configuración y el entorno predeterminado están en su archivo docker-compose.yml.

git clone https://github.com/langfuse/langfuse.git
cd langfuse

Todos los valores que debe cambiar están marcados con # CHANGEME en ese archivo. Genere primero los tres secretos de la aplicación.

openssl rand -base64 32   # NEXTAUTH_SECRET
openssl rand -base64 32   # SALT
openssl rand -hex 32      # ENCRYPTION_KEY

ENCRYPTION_KEY debe tener 256 bits escritos como 64 caracteres hexadecimales. Eso es exactamente lo que muestra openssl rand -hex 32. Este valor cifra los datos confidenciales en reposo, incluidas las claves de proveedores de LLM que almacene en la instancia. Si lo cambia después de que existan datos, esas filas ya no se podrán descifrar. Trátelo como permanente desde el primer arranque. SALT se usa para aplicar un hash a las claves de API de Langfuse. Si lo cambia, invalidará todas las claves que ya usan sus agentes.

A continuación, establezca POSTGRES_PASSWORD, CLICKHOUSE_PASSWORD, REDIS_AUTH y MINIO_ROOT_PASSWORD. La contraseña de MinIO aparece en cuatro lugares: una vez como MINIO_ROOT_PASSWORD y después como LANGFUSE_S3_EVENT_UPLOAD_SECRET_ACCESS_KEY, LANGFUSE_S3_MEDIA_UPLOAD_SECRET_ACCESS_KEY y LANGFUSE_S3_BATCH_EXPORT_SECRET_ACCESS_KEY. Si omite una aparición, MinIO rechaza ese cliente con SignatureDoesNotMatch. El mensaje aparece en el registro del worker, aunque la interfaz web siga funcionando con normalidad. Mantener estos valores en un archivo de entorno en lugar de incluirlos en el archivo compose versionado es el patrón descrito en archivos de entorno y secretos de Docker Compose.

Fije las etiquetas de imagen antes de empezar

El archivo incluido usa langfuse/langfuse:4 y langfuse/langfuse-worker:4. Esas etiquetas cambian. Langfuse ejecuta automáticamente las migraciones de Postgres y ClickHouse al arrancar. Por tanto, un docker compose pull rutinario meses después se convierte en una migración de esquema no planificada sobre una base de datos de la que no hizo una copia de seguridad esa mañana. Fije ambas imágenes a una misma versión en un docker-compose.override.yml. Compose lo combina con el archivo incluido y aplica sus valores por encima, de modo que un git pull posterior no sobrescriba sus cambios.

services:
  langfuse-web:
    image: docker.io/langfuse/langfuse:4.3.1
  langfuse-worker:
    image: docker.io/langfuse/langfuse-worker:4.3.1

La versión 4.3.1 era la versión actual de la serie 4.3 en agosto de 2026 (desde entonces se ha publicado la 4.4.0). Consulte la página de versiones del proyecto en GitHub, fije la versión que esté vigente el día del despliegue y cambie ese número de forma deliberada. Las imágenes de almacenamiento del archivo incluido ya están fijadas a versiones principales: postgres:17, clickhouse-server:25.12 y redis:7. Deben recibir el mismo tratamiento. Esta regla no es exclusiva de Langfuse: un gestor de entrenamientos self-hosted basado en openGym usa una fracción de esta pila y aun así necesita una etiqueta de git explícita, porque cualquier aplicación que migre su propia base de datos al arrancar puede convertir un pull rutinario en un cambio de esquema.

Inicie la pila.

docker compose up -d
docker compose ps
docker compose logs -f langfuse-worker

El primer arranque ejecuta las migraciones. Espere uno o dos minutos antes de comprobar el servicio. docker compose ps debe mostrar seis servicios en estado running. Si el worker se reinicia continuamente, su registro contiene la causa: CLICKHOUSE_MIGRATION_URL usa el protocolo nativo de ClickHouse en el puerto 9000, no el puerto HTTP 8123. Si se configura con el puerto 8123, falla, aunque el contenedor web siga pareciendo correcto.

Compruebe el estado desde el propio servidor.

curl -s "http://localhost:3000/api/public/health?failIfDatabaseUnavailable=true"
curl -s -o /dev/null -w '%{http_code}\n' http://localhost:3000/api/public/ready

Una llamada simple a /api/public/health sólo demuestra que el proceso de API está activo, porque omite deliberadamente la base de datos. Así, el servicio puede seguir respondiendo mientras Postgres presenta interrupciones breves. La forma failIfDatabaseUnavailable=true es la adecuada para configurar en un monitor y devuelve 503 cuando la base de datos no está disponible. /api/public/ready devuelve 200 cuando terminan las migraciones y el contenedor puede aceptar tráfico. Ambas comprobaciones son solicitudes HTTP normales, por lo que una página de estado de Uptime Kuma puede supervisarlas y avisarle de que la pila está caída antes que sus agentes.

Coloque TLS delante y cierre los puertos adicionales

El archivo compose incluido publica 3000:3000 para el contenedor web y 9090:9000 para MinIO. Ambos escuchan en todas las interfaces. En una IP pública, cualquiera que escanee el puerto 3000 llegará a la página de registro y cualquiera que escanee 9090 estará accediendo al bucket que contiene sus prompts sin procesar.

Una regla del firewall por sí sola no los cierra. Docker escribe sus propias reglas DNAT en la tabla nat, y estas se evalúan antes de que las reglas de filtrado de ufw vean el paquete, por lo que ufw deny 3000 deja abierto el puerto publicado. Este problema es tan frecuente que tiene su propia guía: por qué los puertos publicados por Docker omiten ufw. En su lugar, vincule los puertos a loopback en el archivo de override.

services:
  langfuse-web:
    ports:
      - "127.0.0.1:3000:3000"
    environment:
      NEXTAUTH_URL: https://langfuse.example.com
  minio:
    ports:
      - "127.0.0.1:9090:9000"
      - "127.0.0.1:9091:9001"

NEXTAUTH_URL debe ser la dirección pública exacta, incluido el esquema, porque el flujo de inicio de sesión construye la URL de callback a partir de ese valor. Si lo deja como http://localhost:3000 detrás de un proxy HTTPS, el recorrido de inicio de sesión devolverá el navegador a una dirección que no puede alcanzar.

Ahora apunte un reverse proxy a 127.0.0.1:3000 y deje que gestione el certificado. Traefik en el mismo proyecto de Compose es la opción habitual, y las etiquetas de enrutamiento son las que se describen en ejecutar varias aplicaciones detrás de un reverse proxy Traefik. Caddy hace el mismo trabajo en dos líneas si Langfuse es el único servicio del servidor. Verifique con curl -sI https://langfuse.example.com/api/public/ready y confirme desde otra máquina que curl http://YOUR_IP:3000 ahora agota el tiempo de espera.

Hay una salvedad con MinIO. Langfuse sirve los archivos multimedia adjuntos al navegador mediante URLs presignadas que apuntan a ese endpoint de S3. Por tanto, si utiliza trazas multimodales con imágenes o audio, un MinIO accesible sólo desde loopback impedirá que se carguen esos adjuntos. Consulte la página de configuración del almacenamiento de blobs antes de ponerlo detrás de un proxy, porque el endpoint escrito en la URL presignada debe coincidir con el que publica. Las trazas de texto sin formato no se ven afectadas.

Cree su cuenta en la primera visita y mantenga la instancia bajo su control. Establezca LANGFUSE_ALLOWED_ORGANIZATION_CREATORS en su propia dirección de correo electrónico, para que un extraño que llegue a la página no pueda crear una organización en su servidor. Si ya está ejecutando Authentik como su propio proveedor de identidad, Langfuse admite una conexión OIDC estándar. Así, las cuentas se crean y eliminan junto con las demás aplicaciones, en lugar de mantenerse en una lista de contraseñas que sólo conoce este servidor.

Envía tu primera traza

Crea un proyecto en la interfaz web y copia sus claves pública y secreta desde la configuración del proyecto. El SDK de Python lee tres variables de entorno.

export LANGFUSE_PUBLIC_KEY="pk-lf-..."
export LANGFUSE_SECRET_KEY="sk-lf-..."
export LANGFUSE_BASE_URL="https://langfuse.example.com"

LANGFUSE_BASE_URL es el nombre de la variable en SDK v4, publicado en marzo de 2026. El código y las guías antiguos usan LANGFUSE_HOST. Si las trazas llegan a Langfuse Cloud en lugar de a tu servidor, la causa es que la URL base no está definida, porque el valor predeterminado apunta a la instancia alojada.

pip install langfuse opentelemetry-instrumentation-anthropic anthropic

import os
from anthropic import Anthropic
from langfuse import get_client, observe
from opentelemetry.instrumentation.anthropic import AnthropicInstrumentor

AnthropicInstrumentor().instrument()
langfuse = get_client()
client = Anthropic(api_key=os.environ["ANTHROPIC_API_KEY"])

@observe(as_type="tool")
def lookup_order(order_id: str) -> str:
    return f"order {order_id}: shipped"

@observe()
def handle_request(question: str) -> str:
    context = lookup_order("A-1042")
    message = client.messages.create(
        model="claude-haiku-4-5",
        max_tokens=512,
        messages=[{"role": "user", "content": f"{context}\n\n{question}"}],
    )
    return message.content[0].text

if __name__ == "__main__":
    assert langfuse.auth_check()
    print(handle_request("Where is my order?"))
    langfuse.flush()

El decorador @observe abre una observación alrededor de la función, captura sus argumentos y su valor de retorno, y la anida bajo cualquier observación que ya esté activa. AnthropicInstrumentor es la instrumentación de OpenTelemetry para el cliente de Anthropic y convierte cada llamada messages.create en una generación que incluye el nombre del modelo, el uso de tokens y la latencia, sin cambiar el punto de llamada.

Dos llamadas hacen la comprobación por usted. langfuse.auth_check() devuelve False si las claves no son válidas o la URL base es incorrecta. Así se detecta antes el motivo por el que el panel aparece vacío. langfuse.flush() bloquea la ejecución hasta que se envían los spans en cola. Es necesario en procesos de corta duración porque el SDK agrupa los datos en segundo plano y un script que termina de inmediato se lleva consigo el lote que aún no se ha enviado. Si todo un equipo envía trazas en lugar de un único script, defina esas tres variables una sola vez en la puerta de enlace por la que ya pasan los agentes de todos, en lugar de hacerlo en el shell de cada persona. Así funciona un entorno de OneCLI autohospedado que mantiene instrumentadas las ejecuciones de todos los compañeros y conserva las claves en un único lugar.

¿Por qué sigue creciendo ClickHouse?

Las trazas son los datos que más rápido crecen entre los que la mayoría de usuarios aloja por su cuenta. Cada ejecución del agente escribe una fila por paso, y las entradas y salidas se almacenan completas. Por eso, un agente que genera muchos mensajes y usa prompts largos produce muchos más bytes al día que la aplicación que supervisa. Si se deja sin controlar, ClickHouse llena el disco. Un disco lleno detiene la ingesta en lugar de ralentizarla.

Aquí crecen dos elementos distintos y cada uno requiere una corrección diferente.

El primero son los datos de trazas propios. La solución es configurar la retención. Abra la configuración del proyecto en la interfaz web y establezca un periodo de retención en días. Langfuse acepta un mínimo de 3 días. Después, una tarea nocturna selecciona las trazas, observaciones, puntuaciones y recursos multimedia anteriores a ese periodo y los elimina de ClickHouse y del almacenamiento de blobs. La tarea necesita permiso DeleteObject en el bucket. Las credenciales de root de MinIO del archivo compose predeterminado ya tienen ese permiso. La eliminación es permanente. Configure primero una exportación al almacenamiento de blobs si necesita conservar el historial a largo plazo. No escriba manualmente cláusulas TTL para las tablas propias de Langfuse. La tarea de retención mantiene sincronizados ClickHouse y el bucket, mientras que un TTL manual sólo elimina los datos de uno de los dos lados.

Elija el periodo según el uso real. La revisión de costes y calidad se hace con datos de días anteriores, no de meses anteriores. Treinta días es un punto de partida razonable para un equipo pequeño. 14 días son suficientes si sólo abre una traza cuando algo falla.

El segundo elemento son las tablas de registro del sistema de ClickHouse. Este caso sorprende porque el disco sigue creciendo después de configurar la retención. ClickHouse escribe trace_log, text_log, opentelemetry_span_log, metric_log y asynchronous_metric_log para sus propios diagnósticos. Estas tablas se distribuyen sin TTL y Langfuse nunca las lee. Primero averigüe dónde se ha usado realmente el disco.

SELECT table, formatReadableSize(size) AS size, rows FROM (
    SELECT table, database, sum(bytes) AS size, sum(rows) AS rows
    FROM system.parts
    WHERE active
    GROUP BY table, database
    ORDER BY size DESC
)

Ejecútelo con docker compose exec clickhouse clickhouse-client --password "$CLICKHOUSE_PASSWORD". Si las tablas del sistema aparecen cerca de los primeros puestos, desactívelas mediante una sobrecarga de configuración. ClickHouse combina todos los archivos de /etc/clickhouse-server/config.d/ con su configuración principal al iniciar.

<clickhouse>
    <trace_log remove="1"/>
    <text_log remove="1"/>
    <opentelemetry_span_log remove="1"/>
    <asynchronous_metric_log remove="1"/>
    <metric_log remove="1"/>
</clickhouse>

Móntela y reinicie ClickHouse.

services:
  clickhouse:
    volumes:
      - ./clickhouse-config.d/system-logs.xml:/etc/clickhouse-server/config.d/system-logs.xml:ro

Esto detiene las nuevas escrituras. Las filas que ya están en el disco permanecen allí. Recupere el espacio explícitamente con DROP TABLE IF EXISTS system.trace_log y haga lo mismo con cada tabla que haya eliminado. Si prefiere conservar los diagnósticos, la alternativa es aplicar un TTL agresivo a cada tabla en lugar de remove="1", como se explica en la documentación de escalado de Langfuse.

Conviene conocer otra tabla. blob_storage_file_log registra los archivos de eventos subidos al bucket. Si también configura una política de ciclo de vida en el bucket, asigne a la tabla un TTL equivalente para evitar que ambos elementos se desincronicen.

ALTER TABLE blob_storage_file_log MODIFY TTL created_at + INTERVAL 30 DAY DELETE;

Configure también una alerta sencilla df -h para el disco de datos. Las trazas no crecen de forma uniforme. Crecen el día que publica un agente nuevo, y la primera señal de ello no debería ser un fallo de la ingesta.

Copia de seguridad de Postgres y ClickHouse

Una copia de seguridad de Langfuse tiene tres partes. Postgres almacena los usuarios, las organizaciones, los proyectos y las claves de API. ClickHouse almacena las trazas. MinIO almacena los eventos sin procesar. Si restaura sólo Postgres, tendrá un inicio de sesión operativo, pero sin historial. Si restaura sólo ClickHouse, tendrá un historial que nadie podrá consultar porque no podrá iniciar sesión. Esta separación no es exclusiva de Langfuse. Una mesa de soporte de Chatwoot autohospedada tiene la misma estructura: un volcado de Postgres creado sin el directorio de cargas restaura las conversaciones, pero todos sus adjuntos desaparecen.

Postgres es un pg_dump simple, que es lo que recomienda la documentación de copias de seguridad de Langfuse.

docker compose exec -T postgres pg_dump -U postgres postgres \
  | gzip > langfuse-pg-$(date +%F).sql.gz

ClickHouse requiere más cuidado, porque copiar un directorio de datos activo mientras se ejecutan fusiones no produce una copia de seguridad coherente. En un único servidor, el método sencillo consiste en detener el contenedor y archivar el volumen.

docker compose stop clickhouse
docker volume ls | grep clickhouse
docker run --rm -v langfuse_langfuse_clickhouse_data:/data -v "$PWD":/backup alpine \
  tar czf /backup/langfuse-ch-$(date +%F).tar.gz -C /data .
docker compose start clickhouse

Use el nombre del volumen que muestra docker volume ls, no el que aparece escrito en YAML. El archivo declara langfuse_clickhouse_data, y Compose le añade el nombre del proyecto como prefijo. Por eso, un clon en un directorio llamado langfuse produce langfuse_langfuse_clickhouse_data. Si se equivoca, docker run crea un volumen nuevo y vacío sin mostrar ningún error, y el archivo contiene una copia sin datos.

El contenedor web escribe cada evento entrante en el bucket antes de que el worker lo procese, por lo que una detención breve de ClickHouse normalmente sólo hace que el worker vuelva a intentarlo después. Hágalo durante una hora de poca actividad y mantenga la detención breve. En una instancia con más carga, la propia instrucción BACKUP DATABASE default TO S3(...) de ClickHouse crea una copia coherente sin detener el servidor. MinIO es la tercera pieza, y mc mirror o la replicación de MinIO a un bucket externo cubren esta parte. Sea cual sea el método, saque la copia del servidor. Para eso sirven las copias de seguridad cifradas de restic en un VPS.

Redis no necesita copia de seguridad. Almacena la cola y la caché, por lo que perderlo sólo provoca la pérdida de los eventos que están en curso y de ningún dato anterior.

La advertencia sobre la coherencia es real y conviene expresarla claramente. Postgres y ClickHouse se vuelcan en momentos distintos, por lo que una restauración puede dejar una fila de proyecto sin trazas, o trazas asociadas a un proyecto que ya no existe. Langfuse tolera esta situación, pero cree ambos volcados con poca diferencia de tiempo y durante un periodo de poca actividad. El bucket de eventos es la verdadera red de seguridad, porque Langfuse persiste allí cada evento entrante antes de procesarlo.

Restaure las copias en un stack de prueba al menos una vez. Así descubrirá ahora que el nombre del volumen es incorrecto, en lugar de descubrirlo durante una interrupción del servicio.

Qué revisar primero

Cuatro aspectos justifican su lugar durante la primera semana.

• Coste por traza. Langfuse calcula el coste a partir del nombre del modelo y del uso de tokens, así que ordene las trazas por coste y lea de principio a fin la más cara. Normalmente se debe a un prompt que ha crecido: un documento completo pegado en el contexto o un historial de conversación que nadie recorta. Cuando pueda verlo, controlar cuánto le cuesta un agente de IA se convierte en una tarea de ingeniería en lugar de una estimación.
• Uso de tokens separado entre entrada y salida. Los tokens de entrada son numerosos y baratos; los de salida son escasos y caros, y la entrada almacenada en caché es aún más barata. Esta misma contabilidad se explica en cómo se contabiliza el uso de tokens de Claude Code y se aplica a cualquier agente que escriba usted mismo.
• Percentiles de latencia. La mediana oculta el problema. Los valores p95 y p99 muestran dónde se producen los tiempos de espera agotados y, dentro del bucle de un agente, una llamada lenta a una herramienta en p95 se multiplica por el número de iteraciones.
• Llamadas fallidas a herramientas. Filtre las observaciones por nivel ERROR. Una herramienta que falla el 5% de las veces puede pasar desapercibida en la tasa de éxito agregada y resultar muy evidente en las trazas, donde puede ver que el modelo reintenta y después consume tokens para evitar el problema.

Establezca el periodo de retención y elija el panel que revisará semanalmente el mismo día en que haga el despliegue. Una herramienta de observabilidad que nadie abre es una base de datos que termina llenando un disco.

FAQ

¿Cuánta memoria necesita un Langfuse autohospedado?

Planifique 4 núcleos de CPU y 16 GiB de memoria, que es lo que recomienda la guía de Langfuse Docker Compose para una sola máquina virtual, además de unos 100 GiB de almacenamiento. Los mínimos publicados para los componentes son 8 GiB para ClickHouse y 4 GiB para cada contenedor web y worker. Postgres, Redis y MinIO también necesitan memoria adicional. Ocho GiB bastan para la instancia de un desarrollador. Dos GiB no bastan: el kernel termina el proceso de ClickHouse durante las fusiones en segundo plano, y dmesg muestra Out of memory: Killed process.

¿Por qué el disco de ClickHouse sigue llenándose después de configurar la retención de datos?

La configuración de retención sólo cubre los datos propios de Langfuse. ClickHouse escribe por separado sus tablas de diagnóstico trace_log, text_log, opentelemetry_span_log, metric_log y asynchronous_metric_log, que no incluyen TTL. Consulte system.parts agrupado por tabla para ver cuál ocupa más espacio. Después, deshabilite las tablas que no use mediante una entrada remove="1" en un archivo situado bajo /etc/clickhouse-server/config.d/, reinicie ClickHouse y elimine las tablas existentes para recuperar el espacio que ya ocupan.

¿Cuál es el periodo mínimo de retención de datos en Langfuse?

Tres días. La retención se configura por proyecto en la configuración del proyecto o mediante la API de proyectos. Un trabajo nocturno elimina de ClickHouse y del almacenamiento de blobs las trazas, observaciones, puntuaciones y activos multimedia que sean más antiguos que ese periodo. La eliminación no se puede deshacer. Configure primero una exportación al almacenamiento de blobs si necesita conservar el historial más allá de ese periodo.

¿Tengo que hacer copias de seguridad de Postgres y ClickHouse?

Sí, porque contienen datos diferentes. Postgres almacena los usuarios, las organizaciones, los proyectos y las claves de API. ClickHouse almacena los datos de las trazas. Una restauración sólo de Postgres le proporciona una instancia en la que puede iniciar sesión, pero que no contiene datos de trazas. Haga también una copia de seguridad del bucket de MinIO, porque contiene los eventos sin procesar que Langfuse persiste al recibirlos. Es lo más parecido a una fuente de verdad en la pila.

¿Puedo dirigir una configuración existente de OpenTelemetry a un Langfuse autohospedado?

Sí. Langfuse v4 y sus SDK v4 se basan en OpenTelemetry, y las instrumentaciones OTel de Anthropic y OpenAI exportan directamente a él. En Python, ejecute pip install langfuse opentelemetry-instrumentation-anthropic, llame a AnthropicInstrumentor().instrument() una vez al iniciar la aplicación y establezca LANGFUSE_PUBLIC_KEY, LANGFUSE_SECRET_KEY y LANGFUSE_BASE_URL con el host correspondiente. Confirme el funcionamiento con langfuse.auth_check() antes de buscar un panel que no aparece.