Langfuse setup: self-hosted vs managed, prompt management, evaluation integration

Langfuse setup: self-hosted vs managed, prompt management, evaluation integration

Langfuse rappresenta il punto di ingresso piu pragmatico nell'osservabilita LLM open-source: 50K eventi al mese gratis sul cloud managed, oppure deploy self-hosted con Docker Compose accanto al tuo backend per costo marginale zero. Nell'episodio precedente abbiamo dimostrato perche logging e APM tradizionali non bastano per workflow agentici, RAG multi-step e generazione token-pesante. Questo articolo entra nel concreto: due decisioni di deploy (self-hosted vs managed), instrumentazione SDK Python, gestione del prompt versioning, integrazione delle evaluation, e un esempio Java Spring Boot per backend non Python.

Il contesto reale e quello del mio portfolio personale federicocalo.dev: backend Spring Boot, frontend Angular SSR, microservizio ML in FastAPI, e Ollama on-prem (llama3.1:8b) come provider LLM primario. Voglio osservare ogni chiamata al modello senza pagare un servizio esterno, senza far uscire i prompt utente dal mio VPS Hetzner, e senza riscrivere meta della codebase. Langfuse self-hosted v2 (solo Postgres) e la risposta che useremo come spina dorsale, con un cenno a v3 (ClickHouse) per chi prevede crescita oltre 100K eventi al mese.

Non aspettarti ne marketing ne benchmark ottimistici: aspettati comandi reali, file docker-compose minimo, snippet Python e Java testati, tabelle di confronto sincere e una FAQ che risponde alle domande che mi hanno fatto colleghi e clienti negli ultimi mesi.

Sezione 1 - Pricing tier: self-hosted vs managed e quando scegliere cosa

La prima decisione strategica non e quale framework usare ma dove farlo girare. Langfuse offre due deployment model con feature parity quasi totale ma profili di costo, latenza e responsabilita molto diversi. La scelta determina anche l'architettura applicativa downstream: in self-hosted il backend chiama un endpoint locale (latenza sub-millisecondo), in managed chiami cloud.langfuse.com (latenza 50-200 ms a seconda della region).

Vediamo il confronto operativo che uso nelle conversazioni con clienti che mi chiedono advisory osservabilita LLM. I numeri sono aggiornati a inizio 2026 e riflettono le tariffe pubbliche Langfuse Cloud.

La regola pratica: se hai gia un VPS in produzione e qualcuno in team che maneggia Docker (anche tu da solo), self-hosted vince in tutti i casi tranne quando il volume cresce esplosivo e non vuoi gestire il migration path Postgres-a-ClickHouse. Nel mio portfolio Langfuse self-hosted gira accanto a Spring Boot, Angular SSR, FastAPI e Ollama sullo stesso CCX13 da 14 EUR/mese: per 50K trace al mese il costo marginale e effettivamente zero, contando che il VPS e comunque sempre acceso per le altre app.

Avvertenza importante: dalla versione 3 (rilasciata 2025) Langfuse ha introdotto ClickHouse come storage analitico per scalare a milioni di trace. La v2 con solo Postgres rimane supportata e va benissimo fino a circa 100-200K eventi al mese. Sopra quella soglia Postgres comincia a soffrire sulle query aggregative della dashboard (group by, percentile latency, cost roll-up) e la migrazione a v3 diventa raccomandata. Vedremo l'aspetto migration nella sezione 7.

Sezione 2 - Docker Compose deployment: file minimo e comandi essenziali

Procediamo con il setup self-hosted Langfuse v2 (single-container Postgres). Il file docker-compose qui sotto e quello che gira nel mio ambiente staging: meno di 50 righe, due servizi, un volume persistente. Per produzione aggiungerai backup, reverse proxy con HTTPS e probabilmente monitoring container, ma il nucleo resta questo.

# docker-compose.langfuse.yml
# Setup minimo Langfuse v2 self-hosted con Postgres dedicato.
# Posizione consigliata: /opt/langfuse/docker-compose.yml sul VPS.
# Avvio: docker compose -f docker-compose.langfuse.yml up -d

version: "3.9"

services:
  langfuse-db:
    # Database Postgres dedicato per Langfuse, non condividere con altre app
    image: postgres:16-alpine
    container_name: langfuse-db
    restart: unless-stopped
    environment:
      # Credenziali generate con: openssl rand -base64 24
      POSTGRES_USER: langfuse
      POSTGRES_PASSWORD: ${LANGFUSE_DB_PASSWORD}
      POSTGRES_DB: langfuse
    volumes:
      # Volume persistente: backup notturno via pg_dump esterno
      - langfuse_db_data:/var/lib/postgresql/data
    networks:
      - langfuse-net
    healthcheck:
      # Healthcheck necessario per dependency con il servizio web
      test: ["CMD-SHELL", "pg_isready -U langfuse"]
      interval: 10s
      timeout: 5s
      retries: 5

  langfuse-web:
    # Container applicazione Langfuse: UI dashboard + API ingestion
    image: langfuse/langfuse:2  # Pin alla major v2 per evitare upgrade accidentali
    container_name: langfuse-web
    restart: unless-stopped
    depends_on:
      langfuse-db:
        condition: service_healthy
    environment:
      # Connessione DB interna alla rete Docker
      DATABASE_URL: postgresql://langfuse:${LANGFUSE_DB_PASSWORD}@langfuse-db:5432/langfuse
      # NEXTAUTH_URL deve matchare l'URL pubblico Nginx (vedi reverse proxy)
      NEXTAUTH_URL: https://langfuse.federicocalo.dev
      NEXTAUTH_SECRET: ${LANGFUSE_NEXTAUTH_SECRET}
      # SALT cifratura API key, generato con openssl rand -base64 32
      SALT: ${LANGFUSE_SALT}
      # Telemetry off per privacy: nessun ping a Langfuse cloud
      TELEMETRY_ENABLED: "false"
      # Signup chiuso dopo creazione del primo utente admin
      AUTH_DISABLE_SIGNUP: "true"
    ports:
      # Bind solo su loopback: Nginx fa reverse proxy con SSL
      - "127.0.0.1:3000:3000"
    networks:
      - langfuse-net

networks:
  langfuse-net:
    driver: bridge

volumes:
  langfuse_db_data:
    driver: local

Per avviare il setup serve un file .env con le tre variabili sensibili (password DB, NextAuth secret, salt) generate con openssl rand -base64 32. Mai committarle nel repo, lascia solo .env.example con placeholder. Poi docker compose up -d, attendi che il container web esegua le migration al primo boot (logga "Migrations applied"), e naviga su http://localhost:3000 per creare il primo utente admin. Disabilita immediatamente signup setting AUTH_DISABLE_SIGNUP=true e fai restart.

Per il reverse proxy Nginx esponi solo l'host langfuse.federicocalo.dev con SSL Let's Encrypt, proxy_pass a 127.0.0.1:3000. Il path /api/public/ingestion e quello che ricevera tutti i POST trace dagli SDK: il rate limiting va calibrato larghissimo (almeno 100 req/sec) perche con batched flush attivo arrivano burst regolari.

Risorse consumate nel mio caso reale dopo 4 mesi di esercizio con circa 30K trace al mese: container web 280 MB RAM, Postgres 520 MB RAM, disco totale 180 MB (di cui 120 MB sono indici Postgres). Su un CCX13 con 8 GB RAM il footprint e completamente trascurabile.

Per la produzione vera serve aggiungere tre layer non opzionali: backup notturno automatico del volume Postgres, monitoring del container web e del database, runbook di rollback in caso di upgrade fallito. Lo script qui sotto e quello che gira via cron sul mio VPS ogni notte alle 03:00 UTC, dopo il backup del backend Spring Boot e prima della rotazione log Nginx. Implementa pg_dump con compressione, retention 14 giorni, verifica integrita e notifica via Telegram bot in caso di errore.

#!/bin/bash
# /opt/langfuse/scripts/backup_langfuse.sh
# Backup notturno Langfuse Postgres con retention 14gg.
# Schedulato via cron: 0 3 * * * /opt/langfuse/scripts/backup_langfuse.sh

set -euo pipefail  # Exit immediato su errori, variabili non definite, pipe failure

# === Configurazione ===
BACKUP_DIR="/var/backups/langfuse"
RETENTION_DAYS=14
DB_CONTAINER="langfuse-db"
DB_USER="langfuse"
DB_NAME="langfuse"
TIMESTAMP=$(date -u +"%Y%m%d_%H%M%S")
BACKUP_FILE="${BACKUP_DIR}/langfuse_${TIMESTAMP}.sql.gz"
LOG_FILE="/var/log/langfuse_backup.log"

# Webhook Telegram per notifica errori (URL letto da .env esterno)
source /opt/langfuse/.env

# === Funzione di notifica errore ===
notifica_errore() {
    local messaggio="$1"
    echo "[ERRORE] ${messaggio}" | tee -a "${LOG_FILE}"
    # Telegram bot per alert real-time (opzionale, rimuovi se non configurato)
    curl -s -X POST "https://api.telegram.org/bot${TELEGRAM_BOT_TOKEN}/sendMessage" \
        -d "chat_id=${TELEGRAM_CHAT_ID}" \
        -d "text=Langfuse backup failed: ${messaggio}" || true
    exit 1
}

# === Verifica prerequisiti ===
mkdir -p "${BACKUP_DIR}"

# Container Postgres deve essere running
if ! docker ps --format '{{.Names}}' | grep -q "^${DB_CONTAINER}$"; then
    notifica_errore "Container ${DB_CONTAINER} non in esecuzione"
fi

# === Esecuzione backup ===
echo "[$(date -u)] Avvio backup Langfuse" | tee -a "${LOG_FILE}"

# pg_dump dentro il container, output gzip-compressed sul host
if ! docker exec "${DB_CONTAINER}" pg_dump \
        -U "${DB_USER}" \
        -d "${DB_NAME}" \
        --format=plain \
        --no-owner \
        --no-acl 2>>"${LOG_FILE}" | gzip -9 > "${BACKUP_FILE}"; then
    notifica_errore "pg_dump fallito, vedi ${LOG_FILE}"
fi

# === Verifica integrita backup ===
# Test gunzip + grep per assicurarsi che il dump non sia corrotto
if ! gunzip -t "${BACKUP_FILE}" 2>>"${LOG_FILE}"; then
    notifica_errore "Backup corrotto: ${BACKUP_FILE}"
fi

# Backup deve essere almeno 10KB (sanity check, dump vuoto = problema)
DIMENSIONE=$(stat -c%s "${BACKUP_FILE}")
if [ "${DIMENSIONE}" -lt 10240 ]; then
    notifica_errore "Backup troppo piccolo (${DIMENSIONE}B), probabile dump fallito"
fi

# === Rotazione: rimuovi backup piu vecchi di RETENTION_DAYS ===
find "${BACKUP_DIR}" -name "langfuse_*.sql.gz" -mtime +${RETENTION_DAYS} -delete

# === Upload offsite opzionale ===
# Decommentare se hai Hetzner Storage Box o S3-compatible
# rclone copy "${BACKUP_FILE}" remote:langfuse-backups/ 2>>"${LOG_FILE}"

echo "[$(date -u)] Backup completato: ${BACKUP_FILE} ($(du -h "${BACKUP_FILE}" | cut -f1))" \
    | tee -a "${LOG_FILE}"

Lo script e idempotente, robusto agli errori transienti, notifica solo quando serve davvero (no spam). Il restore in caso di disastro e altrettanto semplice: gunzip < backup.sql.gz | docker exec -i langfuse-db psql -U langfuse -d langfuse. Tempo di recovery testato sul mio setup con 200 MB compressi: meno di 90 secondi end-to-end. Per setup managed cloud questo lavoro non lo fai mai (e il valore principale del managed), ma per self-hosted fa parte del costo nascosto da preventivare.

Sezione 3 - Python SDK: instrumentation in 2 righe per funzione

Adesso instrumentiamo l'applicazione. L'SDK Python di Langfuse e progettato per overhead minimo grazie a un decorator @observe che cattura input, output, timing e errori senza richiedere boilerplate. Sotto il cofano l'SDK accumula gli eventi in memoria e li flusha a batch ogni N eventi o ogni N secondi (configurabile), in modo asincrono via background thread.

# langfuse_setup.py
# Esempio agent RAG instrumentato con Langfuse SDK Python.
# Mostra il pattern decorator + manual span per il caso Ollama on-prem.

import os
from langfuse.decorators import observe, langfuse_context
from langfuse import Langfuse
import httpx

# Singleton SDK: inizializzazione lazy, riusato in tutto il processo.
# Le credenziali arrivano da .env e sono generate dalla UI Langfuse
# (Project Settings -> API Keys -> Create new keys).
langfuse = Langfuse(
    public_key=os.environ["LANGFUSE_PUBLIC_KEY"],
    secret_key=os.environ["LANGFUSE_SECRET_KEY"],
    host="https://langfuse.federicocalo.dev",  # Self-hosted endpoint
    flush_at=15,           # Flush ogni 15 eventi accumulati
    flush_interval=1.0,    # Oppure ogni secondo, qualunque arrivi prima
    max_retries=3,         # Retry su errori transienti rete
    timeout=10,            # Timeout HTTP per chiamata ingestion
)


@observe(name="rag_pipeline", as_type="generation")
def rag_query(domanda_utente: str, user_id: str) -> str:
    """
    Pipeline RAG completa instrumentata: retrieval + generation.
    Il decorator crea automaticamente il root span con input/output.
    """
    # Aggancia metadata utili per debugging multi-tenant
    langfuse_context.update_current_observation(
        user_id=user_id,
        metadata={"app_version": "1.4.2", "env": "production"},
        tags=["rag", "ollama"],
    )

    # Step 1: retrieval (sub-span automatico via decorator nested)
    documenti = retrieve_documents(domanda_utente)

    # Step 2: generation con Ollama on-prem
    risposta = generate_answer(domanda_utente, documenti)

    # Output finale registrato sul root span
    return risposta


@observe(name="retrieve_documents", as_type="span")
def retrieve_documents(query: str) -> list[str]:
    """Recupera top-K documenti dal vector store RediSearch."""
    # Logica retrieval omessa per brevita, mock per esempio
    documenti = ["doc1: Ollama gira su llama3.1:8b", "doc2: VPS Hetzner CCX13"]

    # Aggiungi attributi semantici utili in dashboard
    langfuse_context.update_current_observation(
        metadata={"top_k": len(documenti), "vector_store": "redisearch"}
    )
    return documenti


@observe(name="ollama_generation", as_type="generation")
def generate_answer(domanda: str, contesto: list[str]) -> str:
    """Chiamata LLM a Ollama on-prem con tracking token e modello."""
    prompt = f"Contesto:\n{chr(10).join(contesto)}\n\nDomanda: {domanda}\n\nRisposta:"

    # Chiamata sincrona Ollama HTTP API
    response = httpx.post(
        "http://localhost:11434/api/generate",
        json={"model": "llama3.1:8b", "prompt": prompt, "stream": False},
        timeout=60,
    )
    payload = response.json()
    output_text = payload["response"]

    # Registra modello, prompt e usage manualmente (Ollama non e auto-tracked)
    langfuse_context.update_current_observation(
        model="llama3.1:8b",
        input=prompt,
        output=output_text,
        usage={
            "input": payload.get("prompt_eval_count", 0),
            "output": payload.get("eval_count", 0),
            "unit": "TOKENS",
        },
        # Cost zero per modello on-prem, oppure setta ammortamento hardware
        model_parameters={"temperature": 0.7, "context_window": 8192},
    )
    return output_text


# Punto di ingresso applicazione
if __name__ == "__main__":
    risultato = rag_query("Come deployo Langfuse su VPS?", user_id="user-42")
    print(risultato)
    # Flush esplicito prima di terminare il processo (importante per script)
    langfuse.flush()

Tre dettagli importanti del codice sopra. Primo: @observe nested funziona out-of-the-box, le funzioni chiamate dentro un'altra decorata diventano child span del padre, ricostruendo gerarchia trace senza setup manuale. Secondo: per Ollama on-prem devi popolare manualmente i campi model, usage e input/output con update_current_observation perche l'SDK non auto-instrumenta provider non commerciali. Terzo: langfuse.flush() finale serve solo per script CLI, in applicazioni long-running (FastAPI, Flask) il background thread flusha periodicamente da solo.

Esiste un quarto pattern che vale la pena conoscere subito: langfuse.trace() manuale per i casi in cui il decorator non si adatta. Tipico esempio: callback handler in un framework di terze parti, generator function con yield multipli, codice asincrono che cambia event loop. In quei casi crei esplicitamente il trace, lo passi come parametro alle funzioni downstream, e chiami trace.update() alla fine. Verboso ma flessibile. Per l'80% dei casi pero il decorator basta e avanza, e mantenere coerenza stilistica nel codebase aiuta la leggibilita per chi arriva dopo.

Un consiglio pratico per ambienti misti dev-staging-prod: usa nomi di environment espliciti negli attributi span. Aggiungi environment="production" a livello di SDK init oppure come metadata su ogni trace. Senza questo, fai fatica a filtrare in dashboard quali trace sono di test e quali di traffico reale, e i tuoi grafici di latency e cost diventano inaffidabili perche mescolano popolazioni diverse. Langfuse offre anche project separati (un progetto per environment) come alternativa piu rigida ma piu chiara.

Sezione 4 - Prompt management: versioning, tag production, cache locale

Una delle feature distintive di Langfuse e il prompt management built-in. Invece di hardcodare i prompt nel codice o gestirli in un file YAML versionato in git, li metti su Langfuse e li fetchi a runtime. Vantaggi: rollback istantaneo, A/B test fra versioni, modifica prompt senza deploy applicativo, audit history completa di chi ha cambiato cosa e quando.

L'API e semplice: crei un prompt via UI o SDK, ogni modifica genera una nuova versione automaticamente, applichi tag (default latest e production) per identificare quale versione e attiva. Lato applicazione fai fetch del prompt via SDK con caching client-side aggressivo per evitare round-trip a ogni richiesta.

# prompt_management.py
# Workflow completo: creazione prompt versionato, fetch con cache, update.

from langfuse import Langfuse

langfuse = Langfuse()  # Usa env var per credenziali

# === STEP 1: Creazione prompt versione iniziale ===
# Eseguito una volta sola dal team product-owner via script o UI.

prompt_v1 = langfuse.create_prompt(
    name="rag/answer/main",  # Naming gerarchico per organizzazione
    type="text",  # "text" oppure "chat" per messaggi multi-turn
    prompt=(
        "Sei un assistente esperto di portfolio web.\n\n"
        "Contesto:\n{{context}}\n\n"
        "Domanda utente: {{question}}\n\n"
        "Rispondi in italiano, max 200 parole, cita le fonti dal contesto."
    ),
    config={
        # Config tecnica versionata insieme al prompt
        "model": "llama3.1:8b",
        "temperature": 0.7,
        "max_tokens": 400,
    },
    labels=["latest"],  # Tag iniziale: solo latest, non ancora production
    tags=["rag", "italian", "draft"],  # Tag organizzativi liberi
)
print(f"Prompt creato versione {prompt_v1.version}")


# === STEP 2: Fetch prompt da applicazione runtime ===
# Eseguito a ogni richiesta utente. Cache client mantiene latenza zero.

def get_active_prompt():
    """Fetch del prompt production-ready con cache 60s."""
    return langfuse.get_prompt(
        name="rag/answer/main",
        label="production",  # Sblocca solo la versione approvata per prod
        cache_ttl_seconds=60,  # Cache locale: 1 fetch al minuto al massimo
        # Fallback se Langfuse irraggiungibile: usa versione cached scaduta
        fallback="Sei un assistente. Contesto: {{context}}. Domanda: {{question}}",
    )


# Uso pratico nel codice agent
prompt_obj = get_active_prompt()
prompt_compilato = prompt_obj.compile(
    context="Langfuse e una piattaforma open-source di osservabilita LLM.",
    question="Quanto costa self-hosted?",
)
print(prompt_compilato)


# === STEP 3: Promozione versione a production ===
# Eseguita dopo che QA ha approvato la nuova versione.

# Aggiorna i label: rimuove production dalla v1, lo sposta sulla v2
langfuse.update_prompt(
    name="rag/answer/main",
    version=2,
    new_labels=["latest", "production", "qa-passed-2026-05"],
)

# Per rollback: bastano 2 secondi
# langfuse.update_prompt(name="rag/answer/main", version=1, new_labels=["production"])

Tre pattern di gestione che funzionano. Tag latest e sempre l'ultima versione creata, comodissimo in development per non dover aggiornare codice quando smanetti sui prompt. Tag production e la versione che il codice di produzione fetcha esplicitamente, separando deploy applicativo da deploy prompt. Tag custom (es. ab-test-cohort-a, experimental-tools) abilitano A/B test routing client-side: 50% degli utenti fetchano cohort-a, 50% cohort-b, confronti gli score nella dashboard.

Il caching client-side e la chiave per latenza accettabile. Con cache_ttl_seconds=60 ogni replica applicativa fetcha il prompt al massimo una volta al minuto, dopodiche serve la versione cached. Cambio prompt + tag production diventano visibili in produzione entro 60 secondi senza deploy. In emergenza (rollback) puoi forzare invalidation chiamando langfuse.flush() o riavviando le repliche.

La compilazione del prompt con compile() usa formato moustache ({{variabile}}) per il sostituto delle variabili. Funziona bene per casi semplici ma diventa limitante quando hai logica condizionale o loop nei prompt (es. mostra solo gli ultimi 3 messaggi se la conversazione ha piu di 3 turni). In quei casi recupera il template raw da Langfuse, esegui rendering con Jinja2 o template engine equivalente lato applicazione, e mantieni Langfuse come storage versionato del template grezzo senza usare compile(). Trade-off accettabile: perdi validazione automatica delle variabili obbligatorie, guadagni espressivita.

Audit history e una feature sottovalutata. Ogni modifica al prompt registra automaticamente chi ha cambiato cosa e quando, con diff visibile nella UI. Per organizzazioni regolamentate (banche, sanita, GDPR sensitive) questo e oro: sai quale versione di prompt era attiva il giorno X quando l'utente Y ha ricevuto la risposta Z. Senza prompt management sotto controllo dovresti taggare in git ogni cambio, sperare che nessuno modifichi al volo, gestire deploy correlati. Con Langfuse Prompt Management hai il problema risolto da subito.

Sezione 5 - Evaluation integration: score per trace e dashboard trend

Le evaluation in Langfuse sono il meccanismo per attaccare metriche di qualita ai singoli trace. Lo schema e generico: ogni trace puo avere N score, ognuno con name, value (numerico o categorico), comment. Tu scegli quale metrica calcolare, Langfuse offre infrastruttura per storarla, aggregarla, filtrarla. Pattern tipici: faithfulness (la risposta e supportata dal contesto?), relevance (e attinente alla domanda?), latency_sla (sotto la soglia?), cost_per_query (sotto il budget?).

Si combina molto bene con framework specializzati come Ragas o DeepEval che forniscono le metriche pre-implementate, mentre Langfuse fornisce lo storage e la visualizzazione. Vediamo un esempio concreto con custom evaluator decorator.

# evaluation_integration.py
# Custom evaluator: faithfulness via LLM-as-judge + latency SLA + cost budget.
# Score inviati a Langfuse e visibili nella dashboard sotto Evaluations.

from langfuse import Langfuse
from langfuse.decorators import observe, langfuse_context
import time

langfuse = Langfuse()


def evaluate_trace_async(trace_id: str, domanda: str, contesto: str, risposta: str):
    """
    Funzione di evaluation eseguita asincrona dopo la generazione.
    Calcola 3 score e li invia a Langfuse via API score.
    """
    # === SCORE 1: Faithfulness via LLM-as-judge ===
    # Usa un LLM separato per giudicare se la risposta cita il contesto
    judge_prompt = (
        f"Contesto:\n{contesto}\n\n"
        f"Domanda: {domanda}\n\n"
        f"Risposta data: {risposta}\n\n"
        f"La risposta e completamente supportata dal contesto? "
        f"Rispondi SOLO un numero da 0.0 (no) a 1.0 (si)."
    )
    # Chiamata judge LLM omessa per brevita (puo essere stesso Ollama o modello diverso)
    faithfulness_score = call_judge_ollama(judge_prompt)  # ritorna float 0-1

    langfuse.score(
        trace_id=trace_id,
        name="faithfulness",
        value=faithfulness_score,
        data_type="NUMERIC",  # Per aggregazione in dashboard
        comment="LLM-as-judge llama3.1:8b temperature 0",
    )

    # === SCORE 2: Latency SLA check (<2 secondi p95) ===
    # Recupera latenza totale del trace via API read
    trace_data = langfuse.fetch_trace(trace_id)
    durata_ms = trace_data.data.latency  # ms

    sla_pass = "PASS" if durata_ms < 2000 else "FAIL"
    langfuse.score(
        trace_id=trace_id,
        name="latency_sla",
        value=sla_pass,
        data_type="CATEGORICAL",  # Per filtering pass/fail in dashboard
        comment=f"Soglia 2000ms, misurato {durata_ms}ms",
    )

    # === SCORE 3: Cost budget check (<5 cent EUR per query) ===
    # Per Ollama on-prem cost zero, uso ammortamento hardware come proxy
    cost_eur = trace_data.data.total_cost or 0.0
    budget_ok = 1.0 if cost_eur < 0.05 else 0.0

    langfuse.score(
        trace_id=trace_id,
        name="cost_budget",
        value=budget_ok,
        data_type="NUMERIC",
        comment=f"Budget 0.05 EUR, costo {cost_eur:.4f} EUR",
    )


@observe(name="rag_with_eval")
def rag_pipeline_with_eval(domanda: str, user_id: str) -> str:
    """Pipeline RAG che triggera evaluation async dopo la risposta."""
    # ... codice retrieval e generation come prima ...
    contesto = "Contesto recuperato dal vector store"
    risposta = "Risposta generata da Ollama"

    # Recupera trace_id corrente per linkare gli score
    trace_id = langfuse_context.get_current_trace_id()

    # Evaluation in background (non bloccare la risposta utente)
    # In produzione usa task queue (Celery, RQ) invece di thread inline
    import threading
    threading.Thread(
        target=evaluate_trace_async,
        args=(trace_id, domanda, contesto, risposta),
        daemon=True,
    ).start()

    return risposta


def call_judge_ollama(prompt: str) -> float:
    """Mock: chiamata LLM-as-judge che ritorna float 0-1."""
    # Implementazione reale: httpx.post a Ollama, parse output, clamp 0-1
    return 0.85  # Placeholder

Pattern critico: evaluation sempre asincrone. Mai bloccare la risposta utente per calcolare uno score, anche se l'evaluator e veloce. Usa thread, task queue (Celery, RQ, Sidekiq), o batch processor schedulato che processa N trace ogni M minuti. Latenza utente percepita resta quella della sola generazione, gli score arrivano in dashboard entro pochi secondi.

In dashboard Langfuse troverai una vista Evaluations che ti permette di filtrare trace per score (es. "tutti i trace con faithfulness < 0.5"), vedere il trend nel tempo (es. faithfulness medio per giorno), comparare versioni di prompt (es. v1 vs v2 su stessi 100 trace di golden set). Questa e la base per il continuous improvement che vedremo nell'episodio 09 della serie.

Costruire un golden set di evaluation e l'investimento di tempo che paga di piu nel medio termine. Parti con 30-50 query rappresentative del traffico reale, fai annotare manualmente la risposta ideale da un esperto del dominio, poi configura un job batch che ogni notte rigira il golden set sulla versione production corrente e calcola gli score. Trend negativo settimana su settimana = degradazione qualita silenziosa che senza golden set non avresti mai notato. Trend positivo = il tuo lavoro di tuning prompt sta funzionando, ottima validazione oggettiva da mostrare a stakeholder.

Tre tranelli da evitare. Primo: non usare lo stesso modello sia come generator sia come judge, introduce bias enorme (il modello tende a giudicare meglio le proprie risposte). Usa modello diverso o almeno temperature diversa con prompt judge molto specifico. Secondo: gli score binari (pass/fail) sono piu robusti degli score continui (0.0-1.0) perche piu facili da calibrare e meno rumorosi. Terzo: salva sempre il prompt judge come prompt versionato in Langfuse stesso, cosi che il giudizio sia auditabile e riproducibile in futuro.

Sezione 6 - Async batched flush: ottimizzazione overhead sotto carico

L'SDK Langfuse di default e gia ottimizzato per overhead basso, ma sotto carico sostenuto (centinaia di request al secondo) i parametri di flush vanno calibrati. Il trade-off e fra latenza ingestion (quanto rapidamente i trace appaiono in dashboard) e overhead applicativo (quante chiamate HTTP background). Vediamo come tunare i parametri e misurare l'impatto reale.

# async_flush_optimization.py
# Configurazione SDK ottimizzata per high-throughput production.
# Misurazione overhead reale con benchmark inline.

import time
import statistics
from langfuse import Langfuse
from langfuse.decorators import observe

# === Configurazione ottimizzata ===
langfuse = Langfuse(
    # Batch piu grande riduce numero chiamate HTTP a Langfuse server
    flush_at=100,  # Flush ogni 100 eventi (default 15)

    # Interval piu lungo permette accumulo piu eventi per batch
    flush_interval=5.0,  # Flush ogni 5 secondi (default 1.0)

    # Coda max grande per evitare drop sotto burst (default 1000)
    max_event_queue_size=10000,

    # Numero worker thread per parallel flush (default 1)
    max_concurrent_uploads=4,  # 4 paralleli per saturate banda

    # Retry aggressivo su errori transienti
    max_retries=5,
    timeout=30,
)


@observe(name="benchmark_call")
def chiamata_simulata(payload_size: int) -> str:
    """Simula chiamata LLM con payload grande per benchmark."""
    # Simula latenza LLM 50ms
    time.sleep(0.05)
    return "x" * payload_size  # Risposta di N caratteri


def benchmark_overhead(num_calls: int = 1000, payload_size: int = 2000):
    """
    Misura overhead Langfuse confrontando con/senza tracing.
    Esegue N chiamate sequenziali e logga p50/p95/p99 latency.
    """
    # === Run 1: SENZA tracing (baseline) ===
    latencies_baseline = []
    for _ in range(num_calls):
        start = time.perf_counter()
        time.sleep(0.05)  # Simula LLM call senza decorator
        _ = "x" * payload_size
        latencies_baseline.append((time.perf_counter() - start) * 1000)

    # === Run 2: CON tracing Langfuse ===
    latencies_traced = []
    for _ in range(num_calls):
        start = time.perf_counter()
        chiamata_simulata(payload_size)
        latencies_traced.append((time.perf_counter() - start) * 1000)

    # Forza flush finale per drenare la coda prima di misurare
    langfuse.flush()

    # === Reporting ===
    def stats(latencies: list[float]) -> dict:
        sorted_lat = sorted(latencies)
        return {
            "p50_ms": statistics.median(sorted_lat),
            "p95_ms": sorted_lat[int(len(sorted_lat) * 0.95)],
            "p99_ms": sorted_lat[int(len(sorted_lat) * 0.99)],
            "mean_ms": statistics.mean(sorted_lat),
        }

    base = stats(latencies_baseline)
    traced = stats(latencies_traced)
    overhead_p50 = ((traced["p50_ms"] - base["p50_ms"]) / base["p50_ms"]) * 100
    overhead_p99 = ((traced["p99_ms"] - base["p99_ms"]) / base["p99_ms"]) * 100

    print(f"Baseline   p50={base['p50_ms']:.2f}ms p99={base['p99_ms']:.2f}ms")
    print(f"Con trace  p50={traced['p50_ms']:.2f}ms p99={traced['p99_ms']:.2f}ms")
    print(f"Overhead   p50={overhead_p50:.2f}% p99={overhead_p99:.2f}%")


if __name__ == "__main__":
    benchmark_overhead(num_calls=1000, payload_size=2000)
    # Output tipico misurato sul mio VPS:
    # Baseline   p50=50.12ms p99=51.34ms
    # Con trace  p50=50.45ms p99=52.18ms
    # Overhead   p50=0.66%  p99=1.64%

Numeri reali misurati sul mio setup: overhead p50 sotto 1%, p99 sotto 2%, anche con payload da 2 KB e batch flush via rete locale. Su payload piu grandi (10 KB+) l'overhead serializzazione sale a 3-5%, ma resta accettabilissimo per qualsiasi caso d'uso reale. La cosa che fa scalare e max_concurrent_uploads: alzandolo da 1 a 4 il throughput ingestion sostenibile passa da circa 200 a 800 eventi/sec sullo stesso CPU.

Errore frequente da evitare: in script CLI o job batch breve durata non dimenticare langfuse.flush() prima del termine processo. Senza flush, gli eventi nella coda vengono droppati al SIGTERM e perdi tutta la trace history del job. In applicazioni long-running (FastAPI, Flask, Spring Boot dietro proxy) il problema non si pone perche il background thread flusha continuamente.

Su carico burst (es. spike utenti dopo lancio newsletter, traffico organico improvviso) la coda interna SDK puo riempirsi e iniziare a droppare eventi nuovi. Il SDK logga warning ma non solleva eccezioni per non rompere il flow applicativo. Per monitorare questa situazione esponi una metrica Prometheus contatore langfuse_dropped_events_total via callback custom dell'SDK, e configura un alert se il rate sale sopra qualche evento al minuto. Soluzione operativa quando succede: alza max_event_queue_size e max_concurrent_uploads, oppure considera di sample il trace al posto di dropparlo random.

Sampling intelligente e l'alternativa serissima a buttare via eventi random. Pattern provato: 100% degli errori sempre tracciati (sono il motivo principale per cui hai observability), 100% delle generation con costo sopra soglia (es. >5 cent), 1-10% del traffico nominale. Implementi questo decidendo nel decorator wrapper se chiamare @observe oppure no in base alla logica di sampling. Risparmio storage e bandwidth ingestion proporzionale al sample rate, con copertura totale dei casi anomali. Indispensabile sopra il milione di trace al mese.

Sezione 7 - ClickHouse migration: quando e come passare a v3

Postgres su Langfuse v2 regge benissimo fino a 100-200K eventi al mese. Sopra quella soglia inizi a vedere query dashboard lente (group by su milioni di righe), backup pesanti, indici degradati. La v3 introduce ClickHouse come storage analitico mantenendo Postgres per metadata configurazione. La migrazione non e banale ma e supportata ufficialmente con script Langfuse.

-- migration_v2_to_v3_check.sql
-- Query diagnostiche per decidere quando migrare da Postgres-only a ClickHouse.
-- Esegui sul DB Langfuse v2 prima di pianificare upgrade.

-- 1. Dimensione tabelle principali (alert se traces > 10 GB)
SELECT
    schemaname AS schema,
    tablename AS tabella,
    pg_size_pretty(pg_total_relation_size(schemaname || '.' || tablename)) AS dimensione,
    pg_total_relation_size(schemaname || '.' || tablename) AS bytes
FROM pg_tables
WHERE schemaname = 'public'
  AND tablename IN ('traces', 'observations', 'scores', 'prompts')
ORDER BY bytes DESC;

-- 2. Crescita mensile (proietta soglia critica)
SELECT
    DATE_TRUNC('month', "createdAt") AS mese,
    COUNT(*) AS num_traces,
    pg_size_pretty(SUM(pg_column_size(t))) AS dimensione_stimata
FROM traces t
WHERE "createdAt" > NOW() - INTERVAL '6 months'
GROUP BY mese
ORDER BY mese DESC;

-- 3. Performance query dashboard tipica (cost rollup ultimo mese)
-- Se questa query supera 10s, sei al limite Postgres
EXPLAIN ANALYZE
SELECT
    "modelId" AS modello,
    COUNT(*) AS num_chiamate,
    SUM("totalCost") AS costo_totale_eur,
    AVG("latencyMs") AS latenza_media_ms,
    PERCENTILE_CONT(0.95) WITHIN GROUP (ORDER BY "latencyMs") AS latenza_p95
FROM observations
WHERE "createdAt" > NOW() - INTERVAL '30 days'
  AND type = 'GENERATION'
GROUP BY "modelId"
ORDER BY costo_totale_eur DESC
LIMIT 20;

-- 4. Conta osservazioni per giorno (sanity check trend)
SELECT
    DATE_TRUNC('day', "createdAt") AS giorno,
    type,
    COUNT(*) AS num_observations
FROM observations
WHERE "createdAt" > NOW() - INTERVAL '30 days'
GROUP BY giorno, type
ORDER BY giorno DESC, type;

Soglie operative basate su esperienza reale: se la tabella traces supera 10 GB, se la query cost rollup mensile supera 10 secondi, se i backup pg_dump notturni superano 30 minuti, e tempo di pianificare la migrazione a v3. Il processo ufficiale e documentato su langfuse.com/docs/deployment/v3 e prevede: spin up nuovo stack v3 (Postgres + ClickHouse + Redis + MinIO) in parallelo, esecuzione script di migrazione che copia dati da v2 a v3 in background, switch DNS quando il delta e sotto pochi minuti. Downtime tipico 5-10 minuti se preparato bene.

Risorse aggiuntive richieste da v3 rispetto a v2: ClickHouse minimo 2 GB RAM dedicati, Redis 256 MB, MinIO (oppure bucket S3 esterno) per blob storage trace pesanti. Significa salire dal mio CCX13 a un CCX23 (28 EUR/mese) o equivalente. Il valore e che dashboard restano fluide a milioni di trace e puoi conservare history multi-anno senza degradazione.

Considerazione architetturale spesso sottovalutata: ClickHouse e un columnar store ottimizzato per analytics, non per OLTP. Significa che le query di tipo "dammi il trace specifico con questo ID" sono leggermente piu lente che su Postgres, mentre le query "aggregami latency p95 per modello negli ultimi 30 giorni" diventano centinaia di volte piu veloci. Per la dashboard Langfuse, dominata da query analitiche, e il trade-off giusto. Per workflow custom che leggono trace via API (es. CI/CD che fetcha trace di test recenti) noterai latenze leggermente superiori, ma normalmente sotto 100 ms.

Strategia di rollback se la migrazione a v3 va male: tieni lo stack v2 vivo in parallelo per almeno 2 settimane, anche solo come read-only. Punta gli SDK al nuovo endpoint v3, ma lascia v2 con tutti i dati storici come backup logico. Se scopri problemi gravi (es. evaluation che non tornano, prompt che non si caricano) fai switch DNS reverse e torni a v2 in pochi minuti. Costo extra 14 EUR per 2 settimane di doppia infrastruttura, vale assolutamente la peace of mind.

Sezione 8 - Tracing da Spring Boot Java verso Langfuse

Il SDK ufficiale Langfuse e Python e TypeScript. Per backend Java come il mio Spring Boot non c'e libreria ufficiale, ma l'API REST /api/public/ingestion e ben documentata e basta un wrapper in 80 righe per inviare trace direttamente. Ecco l'implementazione che uso in produzione.

// LangfuseTracingService.java
// Wrapper Spring Boot per inviare trace a Langfuse senza SDK ufficiale.
// Posizione: backend/.../infrastructure/observability/LangfuseTracingService.java

package dev.federicocalo.observability;

import com.fasterxml.jackson.databind.ObjectMapper;
import org.springframework.beans.factory.annotation.Value;
import org.springframework.scheduling.annotation.Async;
import org.springframework.stereotype.Service;
import org.springframework.web.reactive.function.client.WebClient;

import java.time.Instant;
import java.util.HashMap;
import java.util.Map;
import java.util.UUID;

@Service
public class LangfuseTracingService {

    private final WebClient webClient;
    private final ObjectMapper mapper = new ObjectMapper();

    public LangfuseTracingService(
            @Value("${langfuse.host}") String host,
            @Value("${langfuse.public-key}") String publicKey,
            @Value("${langfuse.secret-key}") String secretKey) {

        // Auth Basic con public-key:secret-key (formato richiesto da Langfuse API)
        String credentials = publicKey + ":" + secretKey;
        String basicAuth = "Basic " + java.util.Base64.getEncoder()
                .encodeToString(credentials.getBytes());

        this.webClient = WebClient.builder()
                .baseUrl(host)
                .defaultHeader("Authorization", basicAuth)
                .defaultHeader("Content-Type", "application/json")
                .build();
    }

    /**
     * Invia un trace asincrono a Langfuse. Non blocca il chiamante.
     * Ritorna il traceId generato lato Spring per eventuale correlazione.
     */
    @Async("langfuseExecutor")  // Thread pool dedicato in config
    public String inviaTrace(String operationName, String userId,
                              Map input, Map output,
                              long latencyMs, double costEur) {
        String traceId = UUID.randomUUID().toString();

        // Costruisci payload conforme alle spec Langfuse Ingestion API v1
        Map traceEvent = new HashMap<>();
        traceEvent.put("id", UUID.randomUUID().toString());
        traceEvent.put("type", "trace-create");
        traceEvent.put("timestamp", Instant.now().toString());

        Map body = new HashMap<>();
        body.put("id", traceId);
        body.put("name", operationName);
        body.put("userId", userId);
        body.put("input", input);
        body.put("output", output);
        body.put("metadata", Map.of(
                "service", "spring-boot-backend",
                "latencyMs", latencyMs,
                "costEur", costEur
        ));
        body.put("tags", new String[]{"java", "spring-boot"});
        traceEvent.put("body", body);

        Map ingestionPayload = Map.of(
                "batch", new Object[]{traceEvent}
        );

        // Invio asincrono via WebClient: subscribe non blocca, gestisce errori internamente
        webClient.post()
                .uri("/api/public/ingestion")
                .bodyValue(ingestionPayload)
                .retrieve()
                .bodyToMono(String.class)
                .doOnError(err -> {
                    // Log ma non rilancia: tracing non deve mai rompere il main flow
                    System.err.println("Langfuse ingestion failed: " + err.getMessage());
                })
                .subscribe();

        return traceId;
    }
}

// Esempio di utilizzo da un controller o use case Spring
// @RestController
// public class ChatController {
//     private final LangfuseTracingService tracing;
//     private final OllamaClient ollama;
//
//     @PostMapping("/api/v1/chat")
//     public ResponseEntity chat(@RequestBody ChatRequest req) {
//         long start = System.currentTimeMillis();
//         String response = ollama.complete(req.getPrompt());
//         long latency = System.currentTimeMillis() - start;
//
//         tracing.inviaTrace(
//             "chat_completion",
//             req.getUserId(),
//             Map.of("prompt", req.getPrompt()),
//             Map.of("response", response),
//             latency,
//             0.0  // Cost zero per Ollama on-prem
//         );
//         return ResponseEntity.ok(response);
//     }
// }

Tre dettagli implementativi importanti. Primo: @Async richiede una bean Executor chiamata langfuseExecutor definita in config con thread pool dedicato (es. core 2, max 8, queue 1000) per isolare il tracing dal thread pool principale. Secondo: WebClient.subscribe() e veramente asincrono e non bloccante, errori vengono catturati nel doOnError senza propagarsi al chiamante: il tracing puo fallire ma il business flow continua. Terzo: per workflow piu complessi con span gerarchici devi inviare anche observation-create events oltre al trace-create, riferendoli al trace via traceId: l'API e descritta nella documentazione Langfuse Ingestion.

Performance reale misurata nel mio backend Spring Boot: overhead per chiamata inviaTrace() sotto 0.5 ms (la subscribe() ritorna immediatamente, l'invio HTTP avviene in background). Su 1000 req/min il pool dedicato consuma circa 20 MB RAM e 1-2% CPU. Trascurabile rispetto al beneficio di avere tracing unificato fra Java e Python in un'unica dashboard Langfuse.

Per setup piu evoluti vale la pena considerare OpenTelemetry come layer di astrazione. Spring Boot ha integrazione first-class con OpenTelemetry Java Agent (auto-instrumentation di HTTP client, database, cache), e Langfuse offre un OTel exporter che riceve span standard e li converte nel formato proprio. Il vantaggio e che migri tracing fra backend di osservabilita (Jaeger, Tempo, Datadog, Langfuse) cambiando solo configurazione, senza toccare il codice applicativo. Lo svantaggio e che perdi alcune feature LLM-specifiche (cost tracking automatico, prompt linkage) che richiedono attributi proprietari Langfuse. Il giusto compromesso per molti team e usare OTel per i span generici (HTTP, DB) e wrapper custom per gli span LLM.

Pattern di correlazione cross-service che funziona: il backend Spring Boot riceve la request HTTP, genera un trace_id UUID, lo passa al ml-service Python via header HTTP custom (es. X-Langfuse-Trace-Id). Il ml-service legge l'header, crea span Python che riferiscono lo stesso trace_id come parent. Risultato: in dashboard Langfuse vedi un singolo trace gerarchico che attraversa Java + Python + Ollama, con timing end-to-end e breakdown per servizio. Setup richiede 30 minuti, payoff in debugging e enorme.

Sezione 9 - Confronto Langfuse vs LangSmith vs Helicone

Per chiudere il ragionamento decisionale, ecco la matrice di confronto fra Langfuse e i due competitor principali. Il mercato 2026 si e consolidato attorno a queste tre opzioni con posizionamenti chiari, ma la scelta dipende dal mix di feature che ti servono.

Sintesi pratica: Langfuse vince per chi vuole self-hosting e lavora cross-language (Python + Java + TypeScript come nel mio caso). LangSmith vince per team che hanno standardizzato su LangChain e vogliono dataset-driven evaluation come prima feature. Helicone vince per chi non vuole instrumentare codice ma solo monitorare costi via proxy trasparente. Le tre opzioni non sono mutualmente esclusive: ho visto setup ibridi con Helicone come proxy cost tracking + Langfuse per workflow custom evaluation.

FAQ

Langfuse self-hosted o managed: quale scegliere per un progetto solo developer?

Per un progetto singolo developer con volume sotto 50K eventi al mese, il managed free tier copre tutto senza costi. Self-hosted ha senso se hai requisiti privacy (dati non escono dal tuo VPS) o se prevedi di crescere oltre 100K eventi. Nel mio portfolio Langfuse gira self-hosted accanto a Spring Boot sullo stesso VPS Hetzner: cost zero, retention illimitata, totale controllo.

Cosa cambia con Langfuse v3 e ClickHouse?

Dalla versione 3 (rilasciata 2025) Langfuse ha aggiunto ClickHouse come storage analitico per scalare a milioni di trace. Postgres resta per metadata configurazione (utenti, prompt, dataset), ClickHouse per trace, observation, score. Il deploy self-hosted v3 richiede ora 4 servizi (Postgres, ClickHouse, Redis, MinIO o S3), non piu solo Postgres. Per volumi sotto 100K eventi mese, v2 con solo Postgres rimane sufficiente.

Posso usare Langfuse con Ollama on-prem invece di OpenAI?

Si, completamente. Langfuse e agnostico al provider: traccia qualsiasi chiamata LLM purche tu instrumenti il codice. Per Ollama imposti manualmente il modello (es. llama3.1:8b) negli attributi del span e setti i token via usage. Il cost tracking automatico funziona solo per modelli commerciali con price list, ma puoi configurare price custom per i tuoi modelli on-prem (es. cost zero o ammortamento hardware per token).

Come gestisco il prompt versioning quando ho 50 prompt in produzione?

Langfuse Prompt Management offre 3 strategie: tag latest (sempre l'ultima versione, comodo in dev), tag production (sblocchi la versione approvata, default in prod), version specifica (rollback a versione precedente). Per 50 prompt struttura una naming convention gerarchica (es. rag/answer/main, rag/rerank/v1) e usa tag custom (qa-passed, ab-test-cohort-a). Cache locale lato SDK riduce latenza fetch a zero per il 99% dei casi.

Le evaluation Langfuse sostituiscono i framework dedicati come Ragas o DeepEval?

No, sono complementari. Langfuse offre infrastruttura (storage score per trace, dashboard aggregate, esecuzione async di evaluator). I framework specializzati (Ragas, DeepEval, TruLens) offrono metriche pre-implementate (faithfulness, context precision, answer relevancy). Pattern tipico: implementi metric Ragas come funzione Python, la decori con il decoratore Langfuse @observe e invii lo score via langfuse.score(). Hai entrambi i mondi.

Quanto costa Langfuse self-hosted su VPS Hetzner con 50K trace al mese?

Costo marginale zero se gira gia un VPS per altre app. Nel mio setup Langfuse v2 (Postgres only) consuma circa 800 MB RAM e 200 MB disco al mese per 50K trace su un CCX13 da 14 EUR mese che ospita anche Spring Boot, Angular SSR, FastAPI e Ollama. Migrazione a v3 con ClickHouse aggiunge 1.5 GB RAM e richiede CCX23 da 28 EUR mese. Confronto: managed cloud per 50K eventi e 0 EUR (free tier), per 1M e circa 500 EUR mese.

Posso instrumentare un backend Java Spring Boot con Langfuse, o serve Python?

Si, Langfuse offre SDK Python e TypeScript ufficiali, ma il backend riceve trace via REST API standard (POST /api/public/ingestion). Da Spring Boot puoi usare il WebClient per inviare batch di trace in modo asincrono, oppure sfruttare OpenTelemetry con OTel-to-Langfuse exporter. Nel mio backend portfolio uso un piccolo wrapper Spring che decora le chiamate al ml-service e invia il trace direttamente all'endpoint Langfuse: meno di 80 righe di codice Java.

Conclusione

Langfuse e la spina dorsale piu pragmatica per osservabilita LLM nel 2026: open-source con licenza MIT, self-hostable con un docker-compose minimo, gestito da una community attiva e con feature parity sostanziale fra deployment self-hosted e cloud managed. La scelta fra le due modalita dipende da tre variabili (volume, privacy, tempo DevOps), e nella maggior parte dei casi self-hosted accanto a un VPS gia esistente vince per costo marginale zero e controllo totale dei dati prompt utente.

Le feature distintive che giustificano l'investimento di 4-8 ore di setup sono: prompt management con versioning e tag production per blue-green deployment, evaluation integration con score per trace e dashboard trend, cost tracking automatico per modelli commerciali e configurabile per modelli on-prem come Ollama. Il caso d'uso reale del mio portfolio (Spring Boot + Angular SSR + FastAPI + Ollama llama3.1:8b) dimostra che e possibile avere observability cross-language end-to-end con un wrapper Java di 80 righe e SDK Python out-of-the-box, mantenendo overhead applicativo sotto il 2% anche su carico sostenuto.

Resta lo spazio per esplorare alternative complementari: Phoenix di Arize per esperimenti rapidi in notebook, Helicone per cost tracking via proxy trasparente, framework di evaluation specializzati come Ragas e DeepEval per metriche pre-implementate. Vedremo Phoenix nel dettaglio nel prossimo episodio, focalizzato su tracing notebook-first e RAG debugging con visualizzazione embeddings.

Un'ultima riflessione operativa che vale per qualsiasi tool di observability: l'investimento in instrumentation paga in proporzione a quanto velocemente il team puo agire sui dati raccolti. Dashboard piene di metriche ma processi di review settimanali una volta al mese hanno valore nullo. Pattern minimo che funziona: review giornaliera di 15 minuti dei trace falliti delle ultime 24h, weekly review degli score evaluation con golden set, mensile retrospettiva su cost trend e capacity planning. Combinato con prompt versioning Langfuse, hai un loop chiuso dove osservi, diagnostichi, modifichi prompt, deployi senza release applicativa, e misuri l'effetto in 24 ore. Questo e il valore reale dell'observability LLM moderna, e Langfuse e oggi lo strumento piu pragmatico per ottenerlo a costo marginale zero.

Prossimo episodio: Phoenix (Arize): notebook-first observability, experimentation focus, in-memory evaluation e visualizzazione embedding per RAG debugging. Quando scegliere Phoenix invece di Langfuse, e come usarli insieme nello stesso workflow dev-to-prod.