Self-host Langfuse: tracciare gli agenti AI

Perché monitorare un agente AI

L’hosting autonomo di Langfuse consente di vedere cosa ha effettivamente fatto il proprio 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 agli strumenti e ogni token, quindi li raggruppa in un’unica trace che è possibile aprire e consultare. Eseguendolo sul proprio VPS, i prompt restano sempre su un server sotto il proprio controllo.

Il motivo è semplice. Non è possibile correggere un problema di costi o di qualità che non si riesce a vedere. La fattura del provider indica che martedì il costo è stato quattro volte superiore a quello di lunedì. Una trace indica quale esecuzione dell’agente lo ha causato, quale prompt è arrivato 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.

Nel corso di questa guida vengono usati tre termini. Una trace è un’esecuzione completa dell’agente, dall’inizio alla fine. Un’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, assegnato durante una revisione umana o da un valutatore automatico. Langfuse usa 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 è 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 gestisce 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 conserva i dati transazionali, come utenti, organizzazioni, progetti, API key e prompt.
• ClickHouse conserva direttamente i dati delle trace, cioè observations e scores. È un database a colonne progettato per le query analitiche; per questo una dashboard su oltre cento milioni di righe risponde rapidamente.
• Redis è la coda e la cache tra web e worker.
• MinIO fornisce storage a oggetti compatibile con S3 direttamente sul server. Conserva ogni evento raw ricevuto e tutti i contenuti multimediali allegati.

Langfuse pubblica i requisiti minimi per i tre componenti che eseguono l'elaborazione.

[
  {
    "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 al calcolo precedente, senza margine aggiuntivo.

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

Distribuire Langfuse con Docker Compose

Clona il repository. Lo stack, i collegamenti tra i servizi e l’ambiente predefinito si trovano nel relativo docker-compose.yml.

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

Ogni valore da modificare è contrassegnato con # CHANGEME in quel file. Genera 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 essere composto da 256 bit rappresentati da 64 caratteri esadecimali. È esattamente il formato prodotto da openssl rand -hex 32. Cifra i valori sensibili a riposo, incluse le chiavi dei provider LLM eventualmente memorizzate nell’istanza. Se lo modifichi dopo che sono stati scritti dati, quelle righe non potranno più essere decifrate. Consideralo quindi permanente fin dal primo avvio. SALT viene usato per calcolare l’hash delle chiavi API Langfuse. Modificarlo invalida tutte le chiavi già utilizzate dagli agent.

Imposta quindi POSTGRES_PASSWORD, CLICKHOUSE_PASSWORD, REDIS_AUTH e MINIO_ROOT_PASSWORD. La password MinIO compare in quattro punti: prima come MINIO_ROOT_PASSWORD, poi come LANGFUSE_S3_EVENT_UPLOAD_SECRET_ACCESS_KEY, LANGFUSE_S3_MEDIA_UPLOAD_SECRET_ACCESS_KEY e LANGFUSE_S3_BATCH_EXPORT_SECRET_ACCESS_KEY. Se ne ometti una, MinIO rifiuta il client con SignatureDoesNotMatch. L’errore compare nei log del worker, mentre l’interfaccia web continua ad apparire funzionante. Mantenere questi valori in un file env invece che nel file Compose versionato è il metodo descritto in File env e secret di Docker Compose.

Blocca i tag delle immagini prima di iniziare

Il file fornito usa langfuse/langfuse:4 e langfuse/langfuse-worker:4. Questi tag cambiano nel tempo. Langfuse esegue automaticamente le migration di Postgres e ClickHouse all’avvio. Di conseguenza, un normale docker compose pull eseguito mesi dopo può diventare una migration dello schema non pianificata su un database di cui non hai eseguito il backup quella mattina. Blocca entrambi a una release in un docker-compose.override.yml. Compose lo applica sopra il file fornito, così un successivo git pull non sovrascrive le tue 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 (la 4.4.0 è stata rilasciata in seguito). Controlla la pagina delle release del progetto su GitHub, blocca la versione corrente il giorno della distribuzione e aggiorna poi quel numero in modo deliberato. Le immagini dei componenti di storage nel file fornito sono già bloccate alle versioni major, postgres:17, clickhouse-server:25.12 e redis:7. Anche queste meritano lo stesso trattamento.

Avvia lo stack.

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

Il primo avvio esegue le migration. Attendi 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 in loop, il motivo è nei relativi log: CLICKHOUSE_MIGRATION_URL usa il protocollo nativo di ClickHouse sulla porta 9000, non la porta HTTP 8123. Se lo punti a 8123, il worker non funziona, mentre il container web continua ad apparire operativo.

Verifica 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 chiamata /api/public/health semplice dimostra soltanto che il processo API è attivo. Per scelta progettuale, infatti, salta il controllo del database, così il servizio continua a rispondere durante brevi interruzioni di Postgres. La variante failIfDatabaseUnavailable=true è quella da assegnare a un monitor. Restituisce 503 quando il database non è raggiungibile. /api/public/ready restituisce 200 al termine delle migration e indica che il container accetta traffico. Sono controlli HTTP ordinari. Puoi quindi usare una pagina di stato di Uptime Kuma per monitorarli e rilevare l’indisponibilità dello stack prima dei tuoi agent.

Configura 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 associate a tutte le interfacce. Con un IP pubblico, chiunque esegua una scansione sulla porta 3000 raggiunge la pagina di registrazione, mentre chiunque scansioni la porta 9090 accede al bucket che contiene i prompt originali.

Una regola del firewall non basta a chiuderle. Docker scrive le proprie regole DNAT nella tabella nat, che 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 ignorano ufw. Nell’override del file Compose, 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 autenticazione costruisce l’URL di callback a partire da quel valore. Se lo lasci impostato su http://localhost:3000 dietro un proxy HTTPS, il ritorno del flusso di accesso reindirizza il browser verso un indirizzo non raggiungibile.

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

C’è una precisazione 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, un MinIO accessibile solo tramite loopback impedisce il caricamento degli allegati. Consulta la pagina sulla configurazione del blob storage prima di pubblicarlo tramite proxy, perché l’endpoint inserito nell’URL presigned deve corrispondere a quello pubblicato. I trace di solo testo non sono interessati.

Crea il tuo account alla prima visita, quindi mantieni l’istanza sotto il tuo controllo. Imposta LANGFUSE_ALLOWED_ORGANIZATION_CREATORS sul tuo indirizzo email, così una persona estranea che raggiunge la pagina non può creare un’organizzazione sul tuo server.

Inviare la prima traccia

Create un progetto nell'interfaccia web e copiate le chiavi pubblica e segreta dalle impostazioni del progetto. L'SDK Python legge tre 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 vengono inviate a Langfuse Cloud invece che al vostro server, la causa è l'assenza dell'URL di base, 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'observation attorno alla funzione, acquisisce gli argomenti e il valore restituito e la annida sotto l'observation già attiva, se presente. AnthropicInstrumentor è la strumentazione OpenTelemetry per il client Anthropic e trasforma ogni chiamata messages.create in una generation contenente il nome del modello, l'utilizzo dei token e la latenza, senza modifiche nel punto della chiamata.

Due chiamate eseguono i controlli necessari. langfuse.auth_check() restituisce False se le chiavi non sono valide o l'URL di base è errato; è più rapido che chiedersi perché la dashboard sia vuota. langfuse.flush() attende l'invio degli span accodati. È necessario nei processi di breve durata, perché l'SDK esegue il batching in background e uno script che termina immediatamente porta con sé il batch non ancora inviato.

Perché ClickHouse continua a crescere?

Le tracce sono i dati che crescono più rapidamente nella maggior parte delle installazioni self-hosted. Ogni esecuzione dell'agent scrive una riga per ogni passaggio e salva integralmente input e output. Di conseguenza, un agent verboso con prompt lunghi produce ogni giorno molti più byte dell'applicazione che monitora. Se non intervieni, ClickHouse riempie il disco. Quando il disco è pieno, l'acquisizione dei dati si interrompe invece di rallentare.

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 conservazione. Apri le impostazioni del progetto nell'interfaccia web e imposta il periodo di conservazione dei dati in giorni. Langfuse accetta un minimo di 3 giorni. Un job notturno seleziona quindi tracce, osservazioni, punteggi e risorse multimediali più vecchi di tale periodo e li elimina da ClickHouse e dal blob storage. Il job richiede il permesso DeleteObject sul bucket, già disponibile nelle credenziali root di MinIO presenti nel file compose predefinito. L'eliminazione è permanente, quindi configura prima un'esportazione verso il blob storage se ti serve conservare la cronologia a lungo termine. Non aggiungere manualmente clausole TTL alle tabelle gestite direttamente da Langfuse: è il job di conservazione a mantenere sincronizzati ClickHouse e il bucket, mentre un TTL manuale elimina i dati da un solo lato.

Scegli il periodo in base all'uso effettivo. La revisione dei costi e della qualità riguarda dati vecchi di alcuni giorni, non di alcuni mesi. Trenta giorni sono un punto di partenza ragionevole per un team piccolo. Quattordici giorni sono sufficienti se apri una traccia solo quando si verifica un problema.

Il secondo elemento è costituito dalle tabelle dei log di sistema di ClickHouse. Questo aspetto sorprende, perché il disco continua a riempirsi anche dopo aver configurato la conservazione. 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 individua dove è stato effettivamente utilizzato lo spazio.

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
)

Eseguilo con docker compose exec clickhouse clickhouse-client --password "$CLICKHOUSE_PASSWORD". Se le tabelle di sistema sono tra quelle che occupano più spazio, disabilitale tramite un overlay di configurazione. All'avvio, infatti, ClickHouse unisce ogni file presente in /etc/clickhouse-server/config.d/ alla 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 il file 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 sul disco restano disponibili, 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, l'alternativa consiste nell'impostare un TTL aggressivo su ogni tabella invece di usare remove="1", come descritto nella documentazione di Langfuse relativa allo scaling.

C'è un'altra tabella che conviene conoscere. blob_storage_file_log tiene traccia dei file degli eventi caricati nel bucket. Se imposti anche una policy del ciclo di vita sul bucket, assegna alla tabella un TTL corrispondente, così i due sistemi non perdono l'allineamento.

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. Aumentano il giorno in cui distribuisci un nuovo agent, e il primo segnale non dovrebbe essere il fallimento dell'acquisizione dei dati.

Backup di Postgres e ClickHouse

Un backup di Langfuse comprende tre componenti. Postgres contiene utenti, organizzazioni, progetti e chiavi API. ClickHouse contiene le trace. MinIO contiene gli eventi grezzi. Se ripristini soltanto Postgres, ottieni un accesso funzionante ma nessuno storico. Se ripristini soltanto ClickHouse, ottieni lo storico, ma nessuno può accedere per visualizzarlo.

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

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

Per ClickHouse serve maggiore attenzione, perché copiare una directory dati mentre sono in corso operazioni di merge non produce un backup coerente. Su un singolo host, 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 mostrato da docker volume ls, non quello scritto nel file YAML. Il file dichiara langfuse_clickhouse_data e Compose aggiunge il nome del progetto come prefisso, quindi 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 l'archivio non contiene nulla.

Il container web scrive ogni evento in arrivo nel bucket prima che il worker lo elabori, quindi un breve arresto di ClickHouse comporta soprattutto che il worker ritenti l'elaborazione in seguito. Esegui l'operazione in un'ora di bassa attività e mantienila breve. Per 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 backup fuori dal server: è questo lo scopo dei backup restic cifrati su un VPS.

Redis non richiede un backup. Contiene la coda e la cache, quindi la sua perdita comporta soltanto la perdita degli eventi attualmente in elaborazione, non di quelli precedenti.

Il problema di coerenza è reale e va dichiarato chiaramente. Postgres e ClickHouse vengono esportati in momenti diversi, quindi un ripristino può lasciare una riga di progetto senza trace oppure trace associate a un progetto che non esiste più. Langfuse tollera questa situazione, ma esegui entrambi gli export 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 arrivo prima di elaborarlo.

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

Cosa controllare per prima cosa

Quattro aspetti giustificano il loro posto nella prima settimana.

• Costo per trace. Langfuse calcola il costo dal nome del modello e dall'utilizzo dei token. Ordina quindi le trace per costo e leggi dall'inizio alla fine quella più costosa. Di solito la causa è un prompt diventato troppo grande: un intero documento inserito nel contesto oppure una cronologia della conversazione che nessuno riduce. Quando puoi vederlo, controllare quanto ti costa un agente AI diventa un'attività di ingegneria invece di una stima.
• Utilizzo dei token, suddiviso tra input e output. I token di input sono numerosi e poco costosi. I token di output sono pochi e costosi. Gli input nella cache costano ancora meno. Lo stesso modello di contabilizzazione è descritto in come viene conteggiato l'utilizzo dei token in Claude Code e si applica a qualsiasi agente sviluppato autonomamente.
• Percentili della latenza. La mediana nasconde il problema. I valori p95 e p99 sono quelli in cui si verificano i timeout. All'interno di un ciclo dell'agente, una chiamata lenta a uno strumento al percentile p95 viene moltiplicata per il numero di iterazioni.
• Chiamate agli strumenti non riuscite. Filtra le osservazioni per livello ERROR. Uno strumento che non riesce nel 5% dei casi può non emergere in un tasso aggregato di successo, ma è evidente nelle trace, dove puoi monitorare il modello mentre riprova e poi consuma token per aggirare il problema.

Imposta il periodo di conservazione e scegli il dashboard che controllerai ogni settimana, nello stesso giorno in cui esegui il deploy. Uno strumento di osservabilità che nessuno apre è un database che riempie il disco.

FAQ

Quanta memoria richiede un'istanza self-hosted di Langfuse?

Prevedere 4 core CPU e 16 GiB di memoria, come raccomandato dalla guida Docker Compose di Langfuse per una singola macchina virtuale, oltre a circa 100 GiB di spazio di archiviazione. I requisiti minimi pubblicati 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 sono sufficienti: il kernel termina ClickHouse durante le operazioni di merge in background 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 riguarda soltanto i 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. Eseguire la query system.parts raggruppata per tabella per individuare quella più grande, quindi disabilitare le tabelle inutilizzate con una voce remove="1" in un file nella directory /etc/clickhouse-server/config.d/, riavviare ClickHouse ed eliminare le tabelle esistenti per recuperare lo spazio già utilizzato.

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

Tre giorni. La conservazione viene impostata per ogni progetto nelle impostazioni del progetto oppure tramite l'API dei progetti; un job notturno 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, quindi configurare prima un'esportazione verso lo storage a oggetti se è necessario conservare la cronologia oltre tale periodo.

Devo eseguire il backup sia di Postgres sia di ClickHouse?

Sì, perché contengono dati diversi. Postgres contiene utenti, organizzazioni, progetti e chiavi API, mentre ClickHouse contiene i dati delle trace. Un ripristino del solo Postgres restituisce un'istanza alla quale è possibile accedere, ma che non contiene dati. Eseguire il backup anche del bucket MinIO, perché contiene gli eventi grezzi che Langfuse salva all'arrivo e rappresenta l'elemento più vicino a una fonte autorevole nello stack.

Posso indirizzare una configurazione OpenTelemetry esistente verso Langfuse self-hosted?

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