Openfuse — ingeniería de LLM sobre una base de datos de observabilidad real

Ingeniería de LLM sobre una base de datos de observabilidad real.

Un fork de Langfuse que cambia el almacén analítico de ClickHouse por una base de datos de observabilidad temporal. El producto de Langfuse, sus APIs públicas y sus SDKs quedan igual; el almacén de eventos pasa a ser la fuente de verdad de traces, observaciones, scores y del análisis detrás de los dashboards.

ARRANQUE EN 5 MINUTOS

OPENFUSE_STANDALONE_IMAGE=tma1ai/openfuse-standalone:1.0.0-beta.1 docker compose -f docker-compose.standalone.yml up -d --pull always

Cloná el repo, cp .env.quickstart.example .env y ejecutá esto. Abrí localhost:3000: el entorno de quickstart crea un proyecto demo automáticamente, así que podés entrar con demo@example.com / langfuse-dev, o apuntar un SDK de Langfuse a las claves incluidas. Son valores de desarrollo inseguros — para algo real partí de .env.prod.example y definí GREPTIME_PASSWORD para activar la autenticación del almacén analítico.

Fijar una imagen publicada, o separar web y worker

standalone — web + worker en un contenedor

# fijá un tag en lugar de construir desde el checkout
OPENFUSE_STANDALONE_IMAGE=tma1ai/openfuse-standalone:1.0.0-beta.1 \
  docker compose -f docker-compose.standalone.yml up -d --pull always

split — escalar web y worker por separado

OPENFUSE_WEB_IMAGE=tma1ai/openfuse-web:1.0.0-beta.1 \
OPENFUSE_WORKER_IMAGE=tma1ai/openfuse-worker:1.0.0-beta.1 \
  docker compose up -d --pull always

Tus SDKs de Langfuse no cambian

Apuntá cualquier SDK de Langfuse existente — o cualquier tracer de OpenTelemetry — a Openfuse. Traces, observaciones y scores llegan sin tocar una línea de código.

Empezá chico y escalá

Arrancá con un solo openfuse-standalone. El almacén persiste en disco local o en almacenamiento de objetos, y el mismo motor escala a un clúster. Volver a bajar de escala no pierde datos.

Retención larga y barata

El almacenamiento por niveles nativo de objetos más un TTL en SQL plano (LANGFUSE_GREPTIME_TTL) hacen viable retener años de datos. En Langfuse sobre ClickHouse, la retención configurable es una función Enterprise.

La UI completa de Langfuse, sin recortes

No es un subconjunto. Tracing, dashboards, datasets, evals y exportaciones funcionan, y el camino de lectura cubierto se verifica byte a byte contra Langfuse upstream.

[01]

Traces y observaciones

Explorá traces y sus árboles anidados de observaciones con la misma búsqueda y los mismos filtros de siempre. Ediciones, borrados y exportaciones se comportan como esperás, incluida la eliminación completa de un proyecto.

localhost:3000/traces

[02]

Un trace, span por span

Abrí cualquier trace y recorré el árbol completo de observaciones: entradas, salidas, modelo, tokens, costo y latencia en cada nivel de anidamiento.

localhost:3000/traces/…

Detalle de trace de Openfuse con árbol de observaciones

[03]

Dashboards y métricas

Costo, uso de tokens, percentiles de latencia y análisis de scores, desglosados por metadata, tags y herramientas. Las divergencias intencionales con upstream — todas casos donde el fork es igual o más correcto — están en el parity ledger.

localhost:3000

Dashboard principal de Openfuse: traces, costo por modelo, scores, latencia

[04]

Sesiones, usuarios y evals

Seguí una conversación de varios turnos de punta a punta, o pasá a todo lo que hizo un usuario. Datasets, experimentos y el flujo de evaluación funcionan de principio a fin.

localhost:3000/sessions/…

Los traces de LLM son datos de observabilidad

Eventos anchos con marca de tiempo y contexto de alta cardinalidad. Es justo para lo que está hecha una base de datos de observabilidad unificada.

Dónde vive cada dato

Métricas, logs y traces viven en un solo motor: consultable con SQL y PromQL/TQL, nativo en OTLP y con separación de cómputo y almacenamiento sobre almacenamiento de objetos. Postgres sigue guardando los datos de aplicación y configuración — usuarios, proyectos, prompts, definiciones de datasets, API keys — igual que en Langfuse upstream. El almacén de eventos analíticos es una tabla raw_events de solo anexado como fuente de verdad, más tablas de proyección fusionadas y tablas EAV indexadas que soportan el filtrado por metadata, tags y herramientas. Redis sigue corriendo las colas de BullMQ.

Sin bucket obligatorio

Subidas de medios, el carrier de OTel, el blob store de evals y las exportaciones por lote usan rutas del sistema de archivos local por defecto. Un despliegue estándar no necesita S3 ni MinIO: activá el almacenamiento de objetos cuando quieras niveles, no para arrancar.

Dirección, no entrega

Como los eventos ya viven en una base de datos de observabilidad real, quedan al alcance las métricas nativas en PromQL, la correlación logs ↔ traces, la ingesta nativa OTLP y la agregación continua con Flow. Están anotadas como ideas en el issue #8, no son funciones disponibles hoy.

Beta

Probalo, corré cargas reales contra él y abrí issues. Ese feedback es lo que lo lleva a una versión estable.

Qué está hecho

La migración ClickHouse → GreptimeDB está hecha, el camino de lectura se verifica byte a byte contra upstream, y toda la superficie de producto, API y SDK de Langfuse funciona.

Limitaciones conocidas

Known limitations es una lista corta de restricciones reales, más las pocas diferencias intencionales con upstream. Revisala antes de depender de esto.

Un fork comunitario

Openfuse no está afiliado a Langfuse ni cuenta con su respaldo. Conserva el copyright y la atribución de upstream.

MIT

Cada función viene desbloqueada. Sin edición enterprise, sin clave de licencia comercial, sin capacidades detrás de un contrato.

Preguntas frecuentes

¿Tengo que cambiar código?

No. Openfuse 1.0.0-beta.1 se basa en Langfuse upstream v3.184.1, y los SDKs existentes junto con las APIs públicas de ingesta y REST funcionan sin cambios. Cualquier tracer de OpenTelemetry también sirve.

¿Cómo funcionan las migraciones de esquema?

Las migraciones de Postgres son las de Langfuse upstream y se aplican tal cual. El esquema de GreptimeDB es propio del fork y migra automáticamente al iniciar el contenedor: idempotente, serializado con advisory lock y fail-closed.

¿Qué difiere exactamente de Langfuse upstream?

La salida de dashboards y métricas se verifica byte a byte contra upstream en la superficie de consultas cubierta. Las pocas divergencias intencionales, todas casos donde el fork es igual o más correcto, están en el parity ledger. La declaración de compatibilidad completa está en migration-from-langfuse.

¿Qué imágenes se publican?

Tres, construidas para linux/amd64 y linux/arm64 y publicadas en cada tag v*: openfuse-web, openfuse-worker y openfuse-standalone — web y worker en un contenedor, para autoalojamiento en un solo nodo.