Self-host Langfuse per tracciare gli agenti AI

Perché tracciare un agente AI

Puoi eseguire Langfuse in self-hosting per vedere cosa ha effettivamente fatto il tuo agente durante un'esecuzione. Langfuse è uno strumento open source di osservabilità per LLM (large language model). Registra ogni prompt, ogni risposta del modello, ogni chiamata a uno strumento e ogni token, quindi li raggruppa in un'unica trace che puoi aprire e analizzare. Eseguirlo sul tuo VPS significa che questi prompt non lasciano mai un server sotto il tuo controllo.

Il motivo è semplice. Non puoi correggere un problema di costi o di qualità che non puoi vedere. La fattura del provider ti dice che martedì hai speso quattro volte più di lunedì. Una trace ti dice quale esecuzione dell'agente ha causato il costo, quale prompt è cresciuto fino a 40,000 token e quale ciclo di retry è stato eseguito nove volte prima di interrompersi. La fattura fornisce il numero. La trace mostra il codice che lo ha prodotto.

In questa guida vengono usati tre termini. Una trace è un'esecuzione completa dell'agente, dall'inizio alla fine. Una observation è un singolo passaggio all'interno di quell'esecuzione: uno span per il codice ordinario, una generation per una chiamata a un modello. Uno score è un numero associato a una trace, ottenuto da una revisione umana o da un valutatore automatico. Langfuse supporta OpenTelemetry (OTel), lo standard indipendente dai vendor per il distributed tracing, quindi la strumentazione già disponibile può inviare i dati a Langfuse.

Cosa esegue realmente il self-hosting di Langfuse

Langfuse v4 non è costituito da un solo container. È composto da due container applicativi e quattro servizi di storage; su un singolo VPS, tutti e sei vengono eseguiti sul server.

• langfuse-web fornisce l'interfaccia web e l'API di ingestion.
• langfuse-worker svuota la coda in background. Analizza i batch di ingestion, calcola i costi ed esegue il job notturno di conservazione.
• Postgres contiene i dati transazionali, ad esempio utenti, organizzazioni, progetti, chiavi API e prompt.
• ClickHouse contiene i dati delle trace, cioè observation e score. È un database a colonne progettato per le query analitiche; per questo una dashboard su oltre cento milioni di righe continua a rispondere rapidamente.
• Redis è la coda e la cache tra il servizio web e il worker.
• MinIO fornisce storage a oggetti compatibile con S3 direttamente sul server. Contiene ogni evento grezzo ricevuto e gli eventuali file multimediali allegati.

Langfuse pubblica i requisiti minimi per i tre componenti che eseguono il lavoro.

[
  {
    "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 richiede da solo 8 GiB di memoria. Il container web e il worker richiedono 4 GiB ciascuno. Questi sono i requisiti minimi pubblicati per i 3 componenti dimensionati da Langfuse; Postgres, Redis e MinIO richiedono comunque memoria aggiuntiva. La guida Docker Compose del progetto raccomanda una macchina con 4 core, 16 GiB di memoria e circa 100 GiB di storage. Questi valori corrispondono a tale calcolo e non includono un margine arbitrario.

Non provare a eseguire questa configurazione su un piano da 2 GiB. ClickHouse si avvia e accetta scritture per un certo periodo, poi termina durante un merge in background, perché un merge carica in memoria parti di grandi dimensioni di una tabella. Vedrai docker compose ps segnalare il container clickhouse come restarting, dmesg riportare una riga simile a Out of memory: Killed process 1234 (clickhouse-serv) e tutte le dashboard di Langfuse restituire 500. In condizioni di carico inferiori, ClickHouse rifiuta invece la query e registra DB::Exception: Memory limit (total) exceeded. Otto GiB sono sufficienti per uno sviluppatore che invia poche migliaia di trace al giorno. Per la pianificazione, considera 16 GiB.

Distribuire Langfuse con Docker Compose

Clonare il repository. Lo stack, la configurazione dei servizi e l’ambiente predefinito si trovano tutti nel relativo docker-compose.yml.

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

In quel file, ogni valore da modificare è contrassegnato con # CHANGEME. Generare prima i tre secret dell’applicazione.

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

ENCRYPTION_KEY deve contenere 256 bit rappresentati da 64 caratteri esadecimali. È esattamente il formato prodotto da openssl rand -hex 32. Questo valore cifra i dati sensibili a riposo, incluse le chiavi dei provider LLM salvate nell’istanza. Se lo si cambia dopo che sono già presenti dati, le righe interessate non possono più essere decifrate. Va quindi trattato come permanente fin dal primo avvio. SALT viene usato per calcolare l’hash delle chiavi API di Langfuse. Cambiarlo invalida tutte le chiavi già utilizzate dagli agenti.

Impostare quindi POSTGRES_PASSWORD, CLICKHOUSE_PASSWORD, REDIS_AUTH e MINIO_ROOT_PASSWORD. La password di MinIO compare in quattro punti: una volta come MINIO_ROOT_PASSWORD, quindi come LANGFUSE_S3_EVENT_UPLOAD_SECRET_ACCESS_KEY, LANGFUSE_S3_MEDIA_UPLOAD_SECRET_ACCESS_KEY e LANGFUSE_S3_BATCH_EXPORT_SECRET_ACCESS_KEY. Se se ne omette uno, MinIO rifiuta quel client con SignatureDoesNotMatch. L’errore compare nel log del worker, mentre l’interfaccia Web continua ad apparire funzionante. Mantenere questi valori in un file env, anziché nel file Compose tracciato, è il metodo descritto in File env e secret di Docker Compose.

Fissare i tag delle immagini prima di iniziare

Il file fornito usa langfuse/langfuse:4 e langfuse/langfuse-worker:4. Questi tag possono cambiare. Langfuse esegue automaticamente le migrazioni di Postgres e ClickHouse all’avvio. Di conseguenza, un normale docker compose pull mesi dopo può trasformarsi in una migrazione dello schema non pianificata su un database di cui non è stato eseguito il backup quella mattina. Fissare entrambe le immagini alla stessa release in un docker-compose.override.yml. Compose lo applica sopra il file fornito, quindi un successivo git pull non sovrascrive le modifiche.

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

La versione 4.3.1 era la release 4.3 corrente ad agosto 2026. Nel frattempo è stata pubblicata la 4.4.0. Controllare la pagina delle release del progetto su GitHub, fissare la versione corrente il giorno della distribuzione e aggiornarla in modo esplicito quando necessario. Nel file fornito, le immagini dello storage sono già fissate alle versioni major, postgres:17, clickhouse-server:25.12 e redis:7. Anche queste dovrebbero essere fissate in modo analogo.

Avviare lo stack.

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

Il primo avvio esegue le migrazioni. Attendere quindi uno o due minuti prima di verificare le risposte. docker compose ps dovrebbe elencare sei servizi nello stato running. Se il worker si riavvia continuamente, il motivo è riportato nel suo log: CLICKHOUSE_MIGRATION_URL usa il protocollo nativo di ClickHouse sulla porta 9000, non la porta HTTP 8123. Se viene configurato sulla porta 8123, il worker non funziona, mentre il container Web continua ad apparire operativo.

Verificare lo stato dal server stesso.

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 semplice richiesta /api/public/health dimostra soltanto che il processo API è attivo. Il controllo esclude intenzionalmente il database, così il servizio continua a rispondere durante brevi interruzioni di Postgres. La variante failIfDatabaseUnavailable=true è quella da configurare in un monitor. Restituisce 503 quando il database non è raggiungibile. /api/public/ready restituisce 200 al termine delle migrazioni e indica che il container è pronto ad accettare traffico. Sono entrambi normali controlli HTTP, quindi una pagina di stato di Uptime Kuma può monitorarli e segnalare che lo stack è inattivo prima che se ne accorgano gli agenti.

Metti TLS davanti al servizio e chiudi le porte aggiuntive

Il file Compose fornito pubblica 3000:3000 per il container web e 9090:9000 per MinIO. Entrambe le porte sono in ascolto su tutte le interfacce. Su un IP pubblico, chiunque esegua una scansione sulla porta 3000 raggiunge la pagina di registrazione e chiunque scansioni la porta 9090 comunica con il bucket che contiene i prompt originali.

Una regola del firewall da sola non le chiude. Docker scrive le proprie regole DNAT nella tabella nat. Queste regole vengono valutate prima che i pacchetti raggiungano le regole di filtro di ufw. Di conseguenza, ufw deny 3000 lascia aperta la porta pubblicata. Il problema è abbastanza comune da avere una guida dedicata: perché le porte pubblicate da Docker bypassano ufw. Nel file di override, associa invece le porte all'interfaccia loopback.

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 deve essere l'indirizzo pubblico esatto, incluso lo schema, perché il flusso di accesso costruisce l'URL di callback a partire da questo valore. Se, dietro un proxy HTTPS, lo lasci impostato su http://localhost:3000, il percorso di autenticazione reindirizza il browser verso un indirizzo non raggiungibile.

Ora configura un reverse proxy verso 127.0.0.1:3000 e lascia che gestisca il certificato. Traefik nello stesso progetto Compose è la scelta abituale. Le label di routing sono descritte in eseguire più applicazioni dietro un unico reverse proxy Traefik. Se Langfuse è l'unico servizio sul server, Caddy svolge lo stesso compito con due righe. Verifica con curl -sI https://langfuse.example.com/api/public/ready. Poi, da una seconda macchina, conferma che curl http://YOUR_IP:3000 ora vada in timeout.

C'è una limitazione per MinIO. Langfuse serve i file multimediali associati al browser tramite URL presigned che puntano a quell'endpoint S3. Se usi trace multimodali con immagini o audio, MinIO accessibile solo tramite loopback impedisce il caricamento degli allegati. Prima di pubblicarlo tramite proxy, consulta la pagina sulla configurazione dello storage a oggetti. L'endpoint inserito nell'URL presigned deve corrispondere all'indirizzo pubblicato. Le trace di solo testo non sono interessate.

Crea il tuo account al primo accesso, quindi mantieni l'istanza sotto il tuo controllo. Imposta LANGFUSE_ALLOWED_ORGANIZATION_CREATORS sul tuo indirizzo email, così un estraneo che raggiunge la pagina non può creare un'organizzazione sul server. Se esegui già Authentik come provider di identità personale, Langfuse supporta una connessione OIDC standard. Gli account vengono così gestiti insieme alle altre applicazioni, invece di essere memorizzati in un elenco di password noto soltanto a questo server.

Invia la prima traccia

Crea un progetto nell’interfaccia web e copia le chiavi pubblica e segreta dalle impostazioni del progetto. L’SDK Python legge 3 variabili d’ambiente.

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

LANGFUSE_BASE_URL è il nome della variabile nell’SDK v4, rilasciato a marzo 2026. Il codice e le guide meno recenti usano LANGFUSE_HOST. Se le tracce arrivano a Langfuse Cloud invece che al tuo server, la causa è un URL di base non impostato, perché il valore predefinito punta all’istanza ospitata.

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()

Il decoratore @observe apre un’osservazione intorno alla funzione, ne acquisisce gli argomenti e il valore restituito e la annida nell’osservazione già attiva, se presente. AnthropicInstrumentor è la strumentazione OpenTelemetry per il client Anthropic e trasforma ogni chiamata messages.create in una generazione che include il nome del modello, l’utilizzo dei token e la latenza, senza modificare il punto della chiamata.

Due chiamate eseguono i controlli necessari. langfuse.auth_check() restituisce False in caso di chiavi non valide o URL di base errato. È più rapido che chiedersi perché la dashboard sia vuota. langfuse.flush() attende l’invio degli span in coda. È necessario per i processi di breve durata, perché l’SDK esegue il batching in background e uno script che termina immediatamente interrompe anche l’invio del batch non ancora trasmesso.

Perché ClickHouse continua a crescere?

Le tracce sono i dati che crescono più rapidamente in quasi tutti gli ambienti self-hosted. Ogni esecuzione dell'agent scrive una riga per ogni passaggio e salva integralmente input e output. Di conseguenza, un agent loquace con prompt lunghi produce ogni giorno molti più byte dell'applicazione che monitora. Se non intervieni, ClickHouse riempie il disco. Un disco pieno interrompe l'ingestion, invece di rallentarla.

In questo caso crescono due elementi distinti, che richiedono due correzioni separate.

Il primo è costituito dai dati delle tue tracce. La correzione consiste nell'impostare la retention. Apri le impostazioni del progetto nell'interfaccia web e imposta un periodo di conservazione espresso in giorni. Langfuse accetta un minimo di 3 giorni. Ogni notte un job seleziona le tracce, le osservazioni, gli score e gli asset multimediali più vecchi di tale intervallo e li elimina da ClickHouse e dallo blob storage. Il job richiede il permesso DeleteObject sul bucket, che le credenziali root di MinIO nel file compose predefinito possiedono già. L'eliminazione è permanente. Configura prima un'esportazione verso lo blob storage se ti serve conservare lo storico a lungo termine. Non aggiungere manualmente clausole TTL alle tabelle gestite da Langfuse. È il job di retention a mantenere allineati ClickHouse e il bucket, mentre un TTL manuale elimina i dati da un solo lato.

Scegli l'intervallo in base all'uso effettivo. Le verifiche di costi e qualità vengono eseguite su dati vecchi di alcuni giorni, non di mesi. Trenta giorni sono un buon punto di partenza per un team piccolo. Quattordici giorni sono sufficienti se apri una traccia soltanto quando si verifica un problema.

Il secondo elemento è costituito dalle tabelle dei log di sistema di ClickHouse. Questo aspetto sorprende molti utenti, perché il disco continua a riempirsi anche dopo la configurazione della retention. ClickHouse scrive trace_log, text_log, opentelemetry_span_log, metric_log e asynchronous_metric_log per la propria diagnostica. Queste tabelle non hanno un TTL predefinito e Langfuse non le legge. Prima di tutto, individua dove è stato utilizzato effettivamente lo spazio su 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
)

Esegui il comando con docker compose exec clickhouse clickhouse-client --password "$CLICKHOUSE_PASSWORD". Se le tabelle di sistema sono tra quelle che occupano più spazio, disabilitale con un overlay di configurazione. ClickHouse applica infatti, all'avvio, ogni file presente in /etc/clickhouse-server/config.d/ sopra la configurazione principale.

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

Monta l'overlay e riavvia ClickHouse.

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

In questo modo interrompi le nuove scritture. Le righe già presenti su disco rimangono, quindi devi recuperare esplicitamente lo spazio con DROP TABLE IF EXISTS system.trace_log e ripetere la stessa operazione per ogni tabella rimossa. Se preferisci conservare la diagnostica, puoi invece applicare un TTL aggressivo a ogni tabella, anziché usare remove="1". La documentazione di scaling di Langfuse descrive questa configurazione.

È utile conoscere anche un'altra tabella. blob_storage_file_log tiene traccia dei file degli eventi caricati nel bucket. Se hai configurato anche una policy di lifecycle sul bucket, assegna alla tabella un TTL corrispondente, in modo che i due sistemi non si disallineino.

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

Configura inoltre un semplice alert df -h sul disco che contiene i dati. Le tracce non crescono in modo regolare. La crescita può verificarsi il giorno in cui rilasci un nuovo agent. Il primo segnale non dovrebbe essere l'interruzione dell'ingestion.

Backup di Postgres e ClickHouse

Un backup di Langfuse comprende tre parti. Postgres contiene utenti, organizzazioni, progetti e chiavi API. ClickHouse contiene le tracce. MinIO contiene gli eventi grezzi. Se ripristini soltanto Postgres, ottieni un accesso funzionante ma nessuna cronologia. Se ripristini soltanto ClickHouse, ottieni una cronologia che nessuno può consultare perché non può effettuare l’accesso.

Postgres è un semplice pg_dump, come raccomandato dalla documentazione di backup di Langfuse.

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

ClickHouse richiede maggiore attenzione, perché una directory dati copiata mentre sono in esecuzione le operazioni di merge non costituisce un backup coerente. Su un singolo server, l’approccio più semplice consiste nell’arrestare il container e archiviare il volume.

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

Usa il nome del volume restituito da docker volume ls, non quello indicato nel file YAML. Il file dichiara langfuse_clickhouse_data, e Compose aggiunge il nome del progetto come prefisso. Di conseguenza, una copia in una directory chiamata langfuse produce langfuse_langfuse_clickhouse_data. Se usi il nome sbagliato, docker run crea un nuovo volume vuoto senza segnalare errori e il tuo archivio non contiene nulla.

Il container web scrive ogni evento in ingresso nel bucket prima che il worker lo elabori. Pertanto, un breve arresto di ClickHouse comporta soprattutto che il worker riprovi in seguito. Esegui l’operazione in un’ora di bassa attività e mantienila breve. In un’istanza più trafficata, l’istruzione BACKUP DATABASE default TO S3(...) di ClickHouse crea un backup coerente senza arrestare il server. MinIO è il terzo componente: mc mirror o la replica di MinIO verso un bucket esterno lo coprono. Qualunque soluzione tu scelga, trasferisci il risultato fuori dal server. È questo lo scopo dei backup restic crittografati su un VPS.

Redis non richiede backup. Contiene la coda e la cache. Se lo perdi, perdi gli eventi attualmente in elaborazione, ma nulla di precedente.

Il problema di coerenza è reale e va dichiarato con chiarezza. Postgres e ClickHouse vengono scaricati in momenti diversi. Un ripristino può quindi lasciare una riga di progetto senza tracce, oppure tracce appartenenti a un progetto che non esiste più. Langfuse tollera questa situazione, ma esegui entrambi i dump a breve distanza e in una finestra di bassa attività. Il bucket degli eventi è la vera rete di sicurezza, perché Langfuse vi salva ogni evento in ingresso prima di elaborarlo.

Esegui almeno una volta un ripristino in uno stack di test. In questo modo puoi individuare subito un nome di volume errato, invece di scoprirlo durante un’interruzione del servizio.

Cosa controllare per prima cosa

Quattro elementi sono indispensabili nella prima settimana.

• Costo per trace. Langfuse calcola il costo dal nome del modello e dall'utilizzo dei token. Ordina quindi i trace per costo e leggi dall'inizio alla fine quello più costoso. Di solito la causa è un prompt diventato troppo grande: un intero documento incollato nel contesto oppure una cronologia della conversazione che nessuno riduce. Quando il problema è visibile, controllare quanto costa un agente AI diventa un'attività di progettazione invece di una stima.
• Utilizzo dei token separato tra input e output. I token di input sono numerosi e poco costosi, quelli di output sono pochi e costosi, mentre gli input memorizzati nella cache costano ancora meno. La stessa contabilità è descritta in come viene conteggiato l'utilizzo dei token in Claude Code e si applica a qualsiasi agente scritto autonomamente.
• Percentili di latenza. La mediana nasconde il problema. I timeout si verificano nei valori p95 e p99. All'interno di un ciclo dell'agente, inoltre, una chiamata lenta a uno strumento al valore p95 viene moltiplicata per il numero di iterazioni.
• Chiamate agli strumenti non riuscite. Filtra le osservazioni per livello ERROR. Uno strumento che fallisce nel 5% dei casi non emerge in un tasso aggregato di successo, ma è evidente nei trace, dove puoi osservare il modello riprovare e consumare token per aggirare il problema.

Imposta il periodo di conservazione e scegli la dashboard che controllerai ogni settimana, nello stesso giorno del deployment. Uno strumento di osservabilità che nessuno apre è un database che finisce per riempire un disco.

FAQ

Quanta memoria richiede un'istanza Langfuse self-hosted?

Prevedi 4 core CPU e 16 GiB di memoria, come raccomandato dalla guida Langfuse Docker Compose per una singola macchina virtuale, oltre a circa 100 GiB di spazio di archiviazione. I requisiti minimi pubblicati per i componenti sono 8 GiB per ClickHouse e 4 GiB ciascuno per i container web e worker. Anche Postgres, Redis e MinIO richiedono memoria aggiuntiva. Otto GiB sono sufficienti per l'istanza di un singolo sviluppatore. Due GiB non bastano: durante le operazioni di merge in background, il kernel termina ClickHouse e dmesg mostra Out of memory: Killed process.

Perché il disco di ClickHouse continua a riempirsi dopo aver configurato la conservazione dei dati?

L'impostazione della conservazione si applica solo ai dati gestiti direttamente da Langfuse. ClickHouse scrive separatamente le proprie tabelle diagnostiche trace_log, text_log, opentelemetry_span_log, metric_log e asynchronous_metric_log, che non hanno un TTL predefinito. Esegui una query su system.parts raggruppando i risultati per tabella per individuare quella più grande. Disabilita quindi le tabelle inutilizzate con una voce remove="1" in un file sotto /etc/clickhouse-server/config.d/, riavvia ClickHouse ed elimina le tabelle esistenti per recuperare lo spazio già utilizzato.

Qual è il periodo minimo di conservazione dei dati in Langfuse?

Tre giorni. La conservazione viene configurata per ogni progetto nelle impostazioni del progetto oppure tramite l'API dei progetti. Un job eseguito ogni notte elimina da ClickHouse e dallo storage a oggetti le trace, le osservazioni, gli score e gli asset multimediali più vecchi del periodo configurato. L'eliminazione non può essere annullata. Configura quindi prima un'esportazione verso lo storage a oggetti se devi conservare la cronologia oltre questo periodo.

Devo eseguire il backup sia di Postgres sia di ClickHouse?

Sì, perché contengono dati diversi. Postgres contiene utenti, organizzazioni, progetti e chiavi API. ClickHouse contiene i dati delle trace. Un ripristino del solo Postgres produce un'istanza a cui puoi accedere, ma che non contiene dati applicativi. Esegui il backup anche del bucket MinIO, perché contiene gli eventi grezzi che Langfuse salva all'arrivo. Nel relativo stack, questo è l'elemento più vicino a una fonte autorevole dei dati.

Posso indirizzare un'installazione OpenTelemetry esistente verso Langfuse self-hosted?

Sì. Langfuse v4 e i relativi SDK v4 sono basati su OpenTelemetry, mentre le strumentazioni OTel per Anthropic e OpenAI esportano direttamente verso Langfuse. In Python, esegui pip install langfuse opentelemetry-instrumentation-anthropic, chiama AnthropicInstrumentor().instrument() una volta all'avvio e imposta LANGFUSE_PUBLIC_KEY, LANGFUSE_SECRET_KEY e LANGFUSE_BASE_URL sull'host in uso. Verifica con langfuse.auth_check() prima di cercare la causa in una dashboard mancante.