Alojar Langfuse para rastrear agentes de IA

Por qué realizar el seguimiento de 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, los agrupa en una sola traza que puede abrir y revisar. Si lo ejecuta en su propio VPS, esos prompts nunca salen de un servidor bajo su control.

La razón es sencilla. No puede corregir un problema de costes o de calidad que no puede ver. Una factura del proveedor le indica que el martes costó cuatro veces más que el lunes. Una traza le 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 detenerse. La factura proporciona la cifra. La traza muestra el código que la produjo.

En esta guía se utilizan tres términos. Una traza es una ejecución completa del agente, de principio a fin. Una observación es un paso dentro de esa ejecución: un span para el código normal y una generación para una llamada a un modelo. Una puntuación es un número asociado a una traza, procedente de una revisión humana o de un evaluador automatizado. Langfuse utiliza OpenTelemetry (OTel), el estándar independiente del proveedor para el tracing distribuido. Por tanto, la instrumentación que ya tenga puede enviar datos a Langfuse.

Qué ejecuta realmente Langfuse en una instalación autogestionada

Langfuse v4 no consta de un solo contenedor. Consta de dos contenedores de aplicación y cuatro servicios de almacenamiento. En un VPS único, los seis se ejecutan en el propio servidor.

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

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

[
  {
    "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 que Langfuse dimensiona. 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 alrededor de 100 GiB de almacenamiento. Esa recomendación coincide con el cálculo, sin añadir un margen artificial.

No intente ejecutar esto 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 del contenedor clickhouse como restarting, que dmesg muestra una línea similar a 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ía unos pocos miles de trazas al día. Planifique 16 GiB.

Implementar Langfuse con Docker Compose

Clone el repositorio. La pila, la configuración de los servicios y el entorno predeterminado se encuentran en su 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, que es exactamente lo que muestra openssl rand -hex 32. Cifra los valores 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 podrán descifrarse. Trátelo como un valor permanente desde el primer arranque. SALT se usa para aplicar un hash a las claves de API de Langfuse, por lo que cambiarlo invalida todas las claves que ya usan sus agentes.

Después, configure 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 uno, MinIO rechaza ese cliente con SignatureDoesNotMatch. El error aparece en el registro del worker mientras la interfaz web sigue funcionando con normalidad. Mantener estos valores en un archivo env en lugar de incluirlos en el archivo compose versionado es el patrón descrito en Archivos env y secretos de Docker Compose.

Fijar 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 en una base de datos de la que no hizo una copia de seguridad esa mañana. Fije ambas imágenes en una única versión mediante un docker-compose.override.yml. Compose lo combina con el archivo incluido y aplica sus valores 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 rama 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é disponible el día del despliegue y cambie ese número de forma deliberada después. Las imágenes de almacenamiento del archivo incluido ya están fijadas a versiones principales: postgres:17, clickhouse-server:25.12 y redis:7. Debe aplicarles el mismo criterio.

Inicie la pila.

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

El primer arranque ejecuta las migraciones, así que espere uno o dos minutos antes de comprobar si responde. docker compose ps debe mostrar seis servicios en estado running. Si el worker se reinicia continuamente, el motivo aparece en su registro: CLICKHOUSE_MIGRATION_URL usa el protocolo nativo de ClickHouse en el puerto 9000, no el puerto HTTP 8123. Si lo dirige al puerto 8123, falla, aunque el contenedor web siga funcionando con normalidad.

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 /api/public/health simple sólo demuestra que el proceso de la API está activo, porque omite deliberadamente la base de datos para que el servicio siga atendiendo peticiones mientras Postgres presenta interrupciones. La forma failIfDatabaseUnavailable=true es la adecuada para configurar un monitor y devuelve 503 cuando no se puede acceder a la base de datos. /api/public/ready devuelve 200 cuando terminan las migraciones y el contenedor puede aceptar tráfico. Ambas son comprobaciones HTTP normales, por lo que una página de estado de Uptime Kuma puede supervisarlas e indicar que la pila está caída antes de que lo detecten 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 se enlazan a todas las interfaces. En una IP pública, cualquiera que analice el puerto 3000 llega a la página de registro, y cualquiera que analice el puerto 9090 se comunica con el bucket que contiene sus prompts sin procesar.

Una regla del firewall no basta para cerrarlos. 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 eso, ufw deny 3000 deja abierto el puerto publicado. Este problema es lo bastante frecuente como para tener su propia guía: por qué los puertos publicados por Docker omiten ufw. En su lugar, enlace el puerto 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 redirige el navegador a una dirección que no puede alcanzar.

Ahora configure un proxy inverso que apunte a 127.0.0.1:3000 y haga que gestione el certificado. Traefik en el mismo proyecto Compose suele ser la opción habitual, y las etiquetas de enrutamiento son las descritas en ejecutar varias aplicaciones detrás de un proxy inverso 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, después, 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 URL prefirmadas que apuntan a ese endpoint S3. Por tanto, si usa trazas multimodales con imágenes o audio, un MinIO accesible sólo mediante loopback hará que esos archivos no se carguen. 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 prefirmada debe coincidir con el que publique. Las trazas de texto sin formato no se ven afectadas.

Cree su cuenta durante la primera visita y mantenga la instancia bajo su control. Configure LANGFUSE_ALLOWED_ORGANIZATION_CREATORS con 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.

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 tus 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 dentro de la 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 realizan las comprobaciones por ti. langfuse.auth_check() devuelve False si las claves no son válidas o la URL base es incorrecta. Esto es más rápido que intentar averiguar por qué el panel está vacío. langfuse.flush() bloquea la ejecución hasta que se envían los spans en cola. Los procesos de corta duración lo necesitan porque el SDK agrupa los datos en segundo plano y un script que termina inmediatamente se lleva consigo el lote que aún no se ha enviado.

¿Por qué ClickHouse sigue creciendo?

Las trazas son los datos que más rápido crecen en la mayoría de instalaciones propias. Cada ejecución del agente escribe una fila por paso, y las entradas y salidas se almacenan completas. Por eso, un agente conversacional con 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 y un disco lleno detiene la ingesta en lugar de ralentizarla.

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

El primero son sus propios datos de trazas, y 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 de datos en días. Langfuse acepta un mínimo de 3 días. Después, un trabajo nocturno selecciona las trazas, observaciones, puntuaciones y recursos multimedia más antiguos que ese periodo y los elimina de ClickHouse y del almacenamiento de blobs. El trabajo necesita permiso DeleteObject en el bucket, que las credenciales root de MinIO del archivo compose predeterminado ya tienen. La eliminación es permanente, así que configure primero una exportación al almacenamiento de blobs si necesita conservar el historial a largo plazo. No escriba manualmente cláusulas TTL en las tablas propias de Langfuse: el trabajo de retención mantiene sincronizados ClickHouse y el bucket, mientras que un TTL manual elimina los datos de un solo lado.

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 buen punto de partida para un equipo pequeño, y 14 días son suficientes si sólo abre una traza cuando algo falla.

El segundo elemento son las propias tablas de registro del sistema de ClickHouse. Esto sorprende a muchas personas 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 incluyen sin TTL y Langfuse nunca las lee. Primero, averigüe dónde se ha consumido realmente el espacio del 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 con una superposición de configuración, porque 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í, así que 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", tal como se explica en la documentación de escalado de Langfuse.

Conviene conocer una tabla adicional. blob_storage_file_log registra los archivos de eventos cargados en su 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 se desincronicen.

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

Configure también una alerta sencilla df -h en 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 ese aumento 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 funcional, pero sin historial. Si restaura sólo ClickHouse, tendrá historial, pero nadie podrá iniciar sesión para verlo.

Postgres es un pg_dump sencillo, que es lo que recomiendan los documentos de copia 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 solo 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 el YAML. El archivo declara langfuse_clickhouse_data, y Compose le antepone el nombre del proyecto, por lo que 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 datos.

El contenedor web escribe cada evento entrante en el bucket antes de que el worker lo procese, por lo que una breve detención de ClickHouse normalmente sólo hace que el worker vuelva a intentarlo después. Hágalo en una hora de poca actividad y mantenga la interrupción lo más breve posible. En una instancia con más carga, la instrucción BACKUP DATABASE default TO S3(...) propia de ClickHouse escribe una copia de seguridad coherente sin detener el servidor. MinIO es la tercera pieza, y mc mirror o la replicación de MinIO a un bucket externo la cubren. 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 hace que pierda los eventos que están en proceso, no los anteriores.

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

Restaure la copia en una pila de prueba al menos una vez. Así descubrirá ahora un nombre de volumen 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, no en una estimación.
• Uso de tokens separado entre entrada y salida. Los tokens de entrada son numerosos y baratos, los tokens de salida son pocos y caros, y los tokens de entrada almacenados en caché son aún más baratos. En cómo se contabiliza el uso de tokens de Claude Code se explica el mismo sistema de cálculo, que también 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. 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 el nivel ERROR. Una herramienta que falla el 5% del tiempo no se aprecia en una tasa de éxito agregada, pero resulta evidente en las trazas, donde puede observar cómo el modelo reintenta y después consume tokens para sortear el fallo.

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?

Asigne 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 los ajustes del proyecto o mediante la API de proyectos. Un trabajo nocturno elimina de ClickHouse y del almacenamiento de blobs las trazas, observaciones, puntuaciones y recursos multimedia que sean anteriores a 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 almacenan datos diferentes. Postgres almacena usuarios, organizaciones, proyectos y 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 sin datos. Haga también una copia de seguridad del bucket de MinIO, ya que contiene los eventos sin procesar que Langfuse conserva al recibirlos. Es lo más parecido a una fuente de verdad en la pila.

¿Puedo apuntar 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 los datos directamente a Langfuse. En Python, ejecute pip install langfuse opentelemetry-instrumentation-anthropic, llame a AnthropicInstrumentor().instrument() una vez durante el arranque y establezca LANGFUSE_PUBLIC_KEY, LANGFUSE_SECRET_KEY y LANGFUSE_BASE_URL con el host que corresponda. Confirme el resultado con langfuse.auth_check() antes de buscar un panel que falte.