Langfuse zelf hosten op een eigen VPS: handleiding

Waarom zou u een AI-agent überhaupt traceren

U host Langfuse zelf om inzicht te krijgen in wat uw agent daadwerkelijk heeft uitgevoerd tijdens een run. Langfuse is een open-source tool voor observability van LLM's (large language models). Het registreert elke prompt, elk modelantwoord, elke tool-aanroep en elke token, en groepeert deze vervolgens onder één trace die u kunt openen en inzien. Door dit op uw eigen VPS te draaien, verlaten deze prompts nooit een server die u beheert.

De reden om dit te doen is duidelijk. U kunt een probleem met kosten of kwaliteit niet oplossen als u het niet kunt zien. Een factuur van een provider vertelt u dat dinsdag vier keer zoveel kostte als maandag. Een trace vertelt u welke agent-run de oorzaak was, welke prompt groeide naar 40.000 tokens en welke retry-loop negen keer draaide voordat deze opgaf. De factuur geeft u het getal. De trace geeft u de code die het getal heeft geproduceerd.

In deze handleiding worden drie termen gebruikt. Een trace is één end-to-end run van uw agent. Een observation is één stap binnen die run: een span voor reguliere code, een generation voor een aanroep naar een model. Een score is een getal dat aan een trace wordt gekoppeld, afkomstig van een menselijke beoordeling of een geautomatiseerde evaluator. Langfuse ondersteunt OpenTelemetry (OTel), de leverancieronafhankelijke standaard voor distributed tracing, waardoor instrumentatie die u al heeft hiernaar kan verwijzen.

Wat Langfuse bij self-hosting daadwerkelijk uitvoert

Langfuse v4 is niet één container. Het bestaat uit twee applicatiecontainers en vier opslagservices, en op een enkele VPS draaien alle zes deze onderdelen op uw server.

• langfuse-web bedient de webinterface en de ingestion API.
• langfuse-worker verwerkt de wachtrij op de achtergrond. Deze parseert ingestion-batches, berekent kosten en voert de dagelijkse retentie-taak uit.
• Postgres bevat transactionele gegevens zoals gebruikers, organisaties, projecten, API keys en prompts.
• ClickHouse bevat de trace-data zelf, oftewel observaties en scores. Dit is een column store die is ontworpen voor analytische queries, waardoor een dashboard met honderden miljoenen rijen nog steeds snel reageert.
• Redis fungeert als de wachtrij en de cache tussen de webinterface en de worker.
• MinIO biedt S3-compatibele objectopslag op de server. Hierin worden alle onbewerkte inkomende events en eventuele bijgevoegde media opgeslagen.

Langfuse publiceert de minimale systeemeisen voor de drie componenten die het werk verrichten.

[
  {
    "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
  }
]

Alleen al voor ClickHouse is 8 GiB aan geheugen vereist. De webcontainer en de worker vragen elk 4 GiB. Dit zijn de gepubliceerde ondergrenzen voor de 3 componenten die Langfuse schaalt, en Postgres, Redis en MinIO hebben daarnaast ook nog geheugen nodig. De Docker Compose-handleiding van het project zelf adviseert een machine met 4 cores, 16 GiB geheugen en ongeveer 100 GiB opslagruimte; dit komt overeen met die berekening zonder onnodige extra marge.

Probeer dit niet op een abonnement met 2 GiB geheugen. ClickHouse start wel op en accepteert enige tijd schrijfacties, maar crasht vervolgens tijdens een achtergrond-merge, omdat een merge grote delen van een tabel in het geheugen laadt. U zult zien dat docker compose ps de clickhouse-container rapporteert als restarting, dmesg een regel bevat zoals Out of memory: Killed process 1234 (clickhouse-serv), en elk Langfuse-dashboard een 500-foutmelding geeft. Bij een lagere belasting weigert ClickHouse de query en logt het DB::Exception: Memory limit (total) exceeded. Acht GiB is werkbaar voor één ontwikkelaar die enkele duizenden traces per dag verstuurt. Zestien GiB is het getal om voor te plannen.

Langfuse implementeren met Docker Compose

Kloon de repository. De stack, de koppelingen en de standaardomgeving bevinden zich in de docker-compose.yml.

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

Elke waarde die u moet wijzigen, is in dat bestand gemarkeerd als # CHANGEME. Genereer eerst de drie applicatiegeheimen.

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

ENCRYPTION_KEY moet 256 bits zijn, geschreven als 64 hexadecimale tekens; dit is precies wat openssl rand -hex 32 genereert. Het versleutelt gevoelige waarden in rust, inclusief alle LLM-provider-sleutels die u in de instantie opslaat. Wijzig dit niet nadat er gegevens bestaan, aangezien die rijen dan niet meer kunnen worden ontsleuteld; beschouw het dus vanaf de eerste opstart als permanent. SALT wordt gebruikt voor het hashen van uw Langfuse API-sleutels; het wijzigen hiervan maakt elke sleutel die uw agents al gebruiken ongeldig.

Stel vervolgens POSTGRES_PASSWORD, CLICKHOUSE_PASSWORD, REDIS_AUTH en MINIO_ROOT_PASSWORD in. Het MinIO-wachtwoord komt op vier plaatsen voor: eenmaal als MINIO_ROOT_PASSWORD, en daarna als LANGFUSE_S3_EVENT_UPLOAD_SECRET_ACCESS_KEY, LANGFUSE_S3_MEDIA_UPLOAD_SECRET_ACCESS_KEY en LANGFUSE_S3_BATCH_EXPORT_SECRET_ACCESS_KEY. Als u er één mist, weigert MinIO de client met SignatureDoesNotMatch, wat in het worker-logboek verschijnt terwijl de webinterface er nog steeds gezond uitziet. Het bewaren van deze waarden in een env-bestand in plaats van in het versiebeheerde compose-bestand is het patroon dat wordt behandeld in Docker Compose env-bestanden en secrets.

Zet de image-tags vast voordat u begint

Het meegeleverde bestand gebruikt langfuse/langfuse:4 en langfuse/langfuse-worker:4. Deze tags veranderen. Langfuse voert bij het opstarten automatisch Postgres- en ClickHouse-migraties uit, dus een routine-docker compose pull maanden later wordt een ongeplande schema-migratie op een database waarvan u die ochtend geen back-up hebt gemaakt. Zet beide vast op één release in een docker-compose.override.yml, die Compose bovenop het meegeleverde bestand samenvoegt, zodat een latere git pull nooit uw wijzigingen overschrijft.

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

Versie 4.3.1 was de huidige 4.3-release in augustus 2026 (4.4.0 is inmiddels uitgebracht). Controleer de GitHub-releasespagina van het project, zet vast wat op de dag van implementatie actueel is en wijzig dat nummer vervolgens bewust. De opslag-images in het meegeleverde bestand zijn al vastgezet op hoofdversies, postgres:17, clickhouse-server:25.12 en redis:7, en deze verdienen dezelfde behandeling.

Start de stack.

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

De eerste opstart voert de migraties uit, dus gun het een minuut of twee voordat er antwoord komt. docker compose ps hoort zes services in de status running weer te geven. Als de worker in een lus herstart, bevat het logboek de reden: CLICKHOUSE_MIGRATION_URL gebruikt het eigen protocol van ClickHouse op poort 9000, niet de HTTP-poort 8123. Het verwijzen naar 8123 mislukt daar, terwijl de webcontainer er nog steeds in orde uitziet.

Controleer de status vanaf de server zelf.

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

Een eenvoudige /api/public/health-aanroep bewijst alleen dat het API-proces actief is, omdat deze de database bewust overslaat zodat de service blijft draaien tijdens korte Postgres-storingen. De failIfDatabaseUnavailable=true-vorm is de variant die u moet monitoren; deze retourneert 503 wanneer de database onbereikbaar is. /api/public/ready retourneert 200 zodra de migraties zijn voltooid en de container verkeer accepteert. Beide zijn standaard HTTP-checks, dus een Uptime Kuma-statuspagina kan deze controleren en u waarschuwen dat de stack offline is voordat uw agents dat merken.

Plaats TLS aan de voorzijde en sluit de extra poorten

Het meegeleverde compose-bestand publiceert 3000:3000 voor de webcontainer en 9090:9000 voor MinIO. Beide binden op elke interface. Op een publiek IP-adres betekent dit dat iedereen die poort 3000 scant, uw aanmeldpagina bereikt, en iedereen die poort 9090 scant, communiceert met de bucket die uw onbewerkte prompts bevat.

Een firewallregel alleen sluit deze poorten niet. Docker schrijft zijn eigen DNAT-regels naar de nat-tabel, en deze worden geëvalueerd voordat de filterregels van ufw het pakket ooit zien. Hierdoor laat ufw deny 3000 de gepubliceerde poort open. Dit probleem komt zo vaak voor dat er een eigen handleiding voor is: waarom Docker gepubliceerde poorten ufw omzeilen. Bind in plaats daarvan op loopback in uw override-bestand.

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 moet het exacte publieke adres zijn, inclusief het schema, omdat het inlogproces de callback-URL opbouwt op basis van die waarde. Laat u dit als http://localhost:3000 achter een HTTPS-proxy, dan stuurt de inlog-roundtrip de browser naar een locatie die niet bereikbaar is.

Wijs nu een reverse proxy naar 127.0.0.1:3000 en laat deze het certificaat beheren. Traefik in hetzelfde Compose-project is de gebruikelijke keuze, en de routeringslabels zijn de labels die worden behandeld in meerdere applicaties draaien achter één Traefik reverse proxy. Caddy doet hetzelfde werk in twee regels als Langfuse de enige applicatie op de server is. Controleer dit met curl -sI https://langfuse.example.com/api/public/ready en bevestig vervolgens vanaf een tweede machine dat curl http://YOUR_IP:3000 nu een time-out geeft.

Eén kanttekening bij MinIO: Langfuse serveert bijgevoegde media aan uw browser via presigned URL's die naar dat S3-eindpunt wijzen. Als u dus multimodale traces gebruikt die afbeeldingen of audio bevatten, betekent een MinIO die alleen op loopback luistert dat deze bijlagen niet worden geladen. Lees de configuratiepagina voor blob-opslag voordat u deze proxied, omdat het eindpunt dat in de presigned URL wordt geschreven, moet overeenkomen met wat u publiceert. Tekstgebaseerde traces ondervinden hier geen hinder van.

Maak uw account aan bij het eerste bezoek en houd de instantie vervolgens voor uzelf. Stel LANGFUSE_ALLOWED_ORGANIZATION_CREATORS in op uw eigen e-mailadres, zodat een vreemde die de pagina bereikt geen organisatie op uw server kan aanmaken. Als u al Authentik als uw eigen identiteitsprovider gebruikt, accepteert Langfuse een standaard OIDC-verbinding. Accounts worden dan beheerd in lijn met uw overige applicaties in plaats van in een wachtwoordenlijst die alleen op deze server bekend is.

Verstuur uw eerste trace

Maak een project aan in de webinterface en kopieer de publieke en geheime sleutels uit de projectinstellingen. De Python SDK leest drie omgevingsvariabelen.

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

LANGFUSE_BASE_URL is de variabelenaam in SDK v4, die in maart 2026 is uitgebracht. Oudere code en oudere handleidingen gebruiken LANGFUSE_HOST. Als uw traces op Langfuse Cloud terechtkomen in plaats van op uw eigen server, dan is een niet-ingestelde base URL de oorzaak, omdat de standaardwaarde naar de gehoste instantie verwijst.

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

De @observe decorator opent een observatie rondom de functie, legt de argumenten en de retourwaarde vast, en nest deze onder de observatie die al actief is. AnthropicInstrumentor is de OpenTelemetry-instrumentatie voor de Anthropic client, en deze verandert elke messages.create aanroep in een generatie die de modelnaam, het tokengebruik en de latentie bevat, zonder wijzigingen op de aanroeplocatie.

Twee aanroepen voeren de controle voor u uit. langfuse.auth_check() retourneert False bij ongeldige sleutels of een onjuiste base URL; dit is sneller dan uzelf afvragen waarom het dashboard leeg is. langfuse.flush() blokkeert totdat de wachtrij met spans is verzonden. Processen met een korte levensduur hebben dit nodig, omdat de SDK op de achtergrond batches verwerkt en een script dat direct afsluit, de onverzonden batch meeneemt bij het beëindigen.

Waarom blijft ClickHouse groeien?

Traces zijn de snelst groeiende gegevens die de meeste mensen ooit zelf hosten. Elke agent-run schrijft één rij per stap, en inputs en outputs worden volledig opgeslagen. Een actieve agent met lange prompts produceert daarom veel meer bytes per dag dan de applicatie die hij monitort. Als u niets doet, raakt de schijf van ClickHouse vol, en een volle schijf stopt de gegevensopname in plaats van deze te vertragen.

Er groeien hier twee afzonderlijke zaken, en deze vereisen twee afzonderlijke oplossingen.

De eerste is uw eigen trace-data; de oplossing hiervoor is de retentie-instelling. Open de projectinstellingen in de webinterface en stel een retentieperiode voor gegevens in dagen in. Langfuse accepteert een minimum van 3 dagen. Een nachtelijke taak selecteert vervolgens traces, observaties, scores en media-assets die ouder zijn dan dat venster en verwijdert deze uit ClickHouse en uit de blob-opslag. De taak heeft DeleteObject-rechten nodig op de bucket, waarover de MinIO root-referenties in het standaard compose-bestand al beschikken. Verwijdering is permanent, dus configureer eerst een export naar blob-opslag als u een langetermijnhistorie nodig heeft. Schrijf geen handmatige TTL-clausules op de eigen tabellen van Langfuse: de retentietaak zorgt ervoor dat ClickHouse en de bucket synchroon blijven, terwijl een handmatige TTL slechts één kant verwijdert.

Kies het venster op basis van wat u daadwerkelijk gebruikt. Kosten- en kwaliteitsbeoordelingen vinden plaats op gegevens van enkele dagen oud, niet van maanden oud. Dertig dagen is een redelijk begin voor een klein team, en 14 dagen is voldoende als u alleen een trace opent wanneer er iets misgaat.

De tweede zijn de eigen systeemlogtabellen van ClickHouse, en dit verrast mensen omdat de schijf blijft groeien nadat de retentie is geconfigureerd. ClickHouse schrijft trace_log, text_log, opentelemetry_span_log, metric_log en asynchronous_metric_log voor zijn eigen diagnostiek; deze worden geleverd zonder TTL en Langfuse leest ze nooit. Zoek eerst uit waar de schijfruimte daadwerkelijk naartoe is gegaan.

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
)

Voer dit uit met docker compose exec clickhouse clickhouse-client --password "$CLICKHOUSE_PASSWORD". Als systeemtabellen bovenaan staan, schakel ze dan uit met een configuratie-overlay, omdat ClickHouse bij het opstarten elk bestand in /etc/clickhouse-server/config.d/ over zijn hoofdconfiguratie heen samenvoegt.

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

Mount dit en herstart ClickHouse.

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

Dit stopt nieuwe schrijfacties. Rijen die al op de schijf staan, blijven daar staan, dus claim de ruimte expliciet terug met DROP TABLE IF EXISTS system.trace_log en doe hetzelfde voor elke tabel die u heeft verwijderd. Als u de diagnostiek liever behoudt, is het alternatief een agressieve TTL op elke tabel in plaats van remove="1", wat in de Langfuse scaling-documentatie wordt uitgelegd.

Er is nog één tabel die het vermelden waard is. blob_storage_file_log houdt de event-bestanden bij die naar uw bucket zijn geüpload. Als u ook een lifecycle-beleid op de bucket instelt, geef de tabel dan een overeenkomstige TTL zodat de twee niet uit de pas gaan lopen.

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

Stel ook een eenvoudige df -h-waarschuwing in op de gegevensschijf. Traces groeien niet gelijkmatig. Ze groeien op de dag dat u een nieuwe agent uitrolt, en het eerste teken daarvan zou niet moeten zijn dat de gegevensopname faalt.

Back-up van Postgres en ClickHouse

Een Langfuse-back-up bestaat uit drie onderdelen. Postgres bevat uw gebruikers, organisaties, projecten en API-keys. ClickHouse bevat de traces. MinIO bevat de onbewerkte events. Als u alleen Postgres herstelt, krijgt u een werkende login zonder historie. Als u alleen ClickHouse herstelt, krijgt u historie die niemand kan inzien omdat inloggen niet mogelijk is.

Postgres is een standaard pg_dump, wat ook wordt aanbevolen in de back-updocumentatie van Langfuse.

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

ClickHouse vereist meer aandacht, omdat een live datadirectory die wordt gekopieerd terwijl er merges plaatsvinden, geen consistente back-up oplevert. De eenvoudige methode op één server is het stoppen van de container en het archiveren van het 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

Gebruik de volumenaam die docker volume ls weergeeft, niet de naam die in de YAML staat. Het bestand declareert langfuse_clickhouse_data, en Compose voegt daar het projectnaam-voorvoegsel aan toe, waardoor een kloon in een directory genaamd langfuse resulteert in langfuse_langfuse_clickhouse_data. Als u dit fout doet, maakt docker run een nieuw leeg volume aan zonder foutmelding, en bevat uw archief niets.

De web-container schrijft elk inkomend event naar de bucket voordat de worker het verwerkt, dus een korte stop van ClickHouse betekent meestal dat de worker het daarna opnieuw probeert. Voer dit uit tijdens een rustig moment en houd de duur kort. Voor een drukkere instantie schrijft het eigen BACKUP DATABASE default TO S3(...)-statement van ClickHouse een consistente back-up zonder de server te stoppen. MinIO is het derde onderdeel, en mc mirror of MinIO-replicatie naar een externe bucket dekt dit af. Wat u ook produceert, haal het van de server af; daarvoor zijn versleutelde restic-back-ups op een VPS bedoeld.

Redis heeft geen back-up nodig. Het bevat de wachtrij en de cache, dus verlies hiervan kost u alleen de events die op dat moment in behandeling zijn, en niets ouder.

Het voorbehoud wat betreft consistentie is reëel en moet duidelijk worden benoemd. Postgres en ClickHouse worden op verschillende momenten gedumpt, waardoor een herstel kan leiden tot een projectrij zonder traces, of traces die behoren bij een project dat niet meer bestaat. Langfuse tolereert dit, maar maak beide dumps kort na elkaar en tijdens een venster met weinig verkeer. De event-bucket is het echte vangnet, omdat Langfuse elk inkomend event daar opslaat voordat het wordt verwerkt.

Herstel ten minste één keer naar een testomgeving. Zo ontdekt u nu een verkeerde volumenaam, in plaats van tijdens een storing.

Waar u als eerste naar moet kijken

Vier zaken verdienen in de eerste week uw aandacht.

• Kosten per trace. Langfuse berekent de kosten op basis van de modelnaam en het tokenverbruik. Sorteer traces daarom op kosten en bekijk de duurste trace van begin tot eind. Het antwoord is meestal een prompt die te groot is geworden: een volledig document dat in de context is geplakt, of een gespreksgeschiedenis die niet wordt ingekort. Zodra u dit inzicht heeft, wordt het beheersen van de kosten van een AI-agent een technische taak in plaats van giswerk.
• Verdeling van tokenverbruik tussen input en output. Input-tokens zijn talrijk en goedkoop, output-tokens zijn schaars en duur, en gecachte input is nog goedkoper. Dezelfde berekening wordt uitgelegd in hoe het tokenverbruik van Claude Code wordt geteld, en dit is van toepassing op elke agent die u zelf schrijft.
• Latentie-percentielen. De mediaan verbergt het probleem. Bij p95 en p99 bevinden zich de timeouts. Binnen een agent-loop wordt een trage tool-aanroep bij p95 vermenigvuldigd met het aantal iteraties.
• Mislukte tool-aanroepen. Filter observaties op niveau ERROR. Een tool die in 5% van de gevallen faalt, is onzichtbaar in een geaggregeerd succespercentage, maar zeer zichtbaar in de traces. Hier ziet u hoe het model het opnieuw probeert en vervolgens tokens verbruikt om het probleem te omzeilen.

Stel de retentieperiode in en kies het dashboard dat u wekelijks op dezelfde dag als uw deployment controleert. Een observability-tool die niemand opent, is slechts een database die een schijf vult.

FAQ

Hoeveel geheugen heeft een zelfgehoste Langfuse nodig?

Houd rekening met 4 CPU-cores en 16 GiB geheugen; dit is wat de Docker Compose-handleiding van Langfuse aanbeveelt voor een enkele virtuele machine, plus ongeveer 100 GiB opslagruimte. De gepubliceerde minimumvereisten per component zijn 8 GiB voor ClickHouse en 4 GiB per stuk voor de web- en worker-containers. Postgres, Redis en MinIO vereisen daarnaast nog extra geheugen. Met 8 GiB kunt u één ontwikkelaarsinstantie draaien. Met 2 GiB lukt dit niet: de kernel beëindigt ClickHouse tijdens achtergrond-merges, en dmesg toont Out of memory: Killed process.

Waarom raakt mijn ClickHouse-schijf vol nadat ik dataretentie heb ingesteld?

De retentie-instelling heeft alleen betrekking op de eigen data van Langfuse. ClickHouse schrijft afzonderlijk diagnostische tabellen naar trace_log, text_log, opentelemetry_span_log, metric_log en asynchronous_metric_log, en deze worden zonder TTL geleverd. Voer query system.parts uit, gegroepeerd per tabel, om te zien welke het grootst is. Schakel vervolgens de ongebruikte tabellen uit met een remove="1"-vermelding in een bestand onder /etc/clickhouse-server/config.d/, herstart ClickHouse en verwijder de bestaande tabellen om de reeds gebruikte ruimte vrij te maken.

Wat is de minimale dataretentieperiode in Langfuse?

Drie dagen. Retentie wordt per project ingesteld in de projectinstellingen of via de projects API. Een nachtelijke taak verwijdert traces, observaties, scores en media-assets die ouder zijn dan dit venster, zowel uit ClickHouse als uit de blob-opslag. Verwijdering kan niet ongedaan worden gemaakt; configureer daarom eerst een export naar blob-opslag als u historie buiten dit venster nodig heeft.

Moet ik zowel Postgres als ClickHouse back-uppen?

Ja, omdat ze verschillende gegevens bevatten. Postgres bevat gebruikers, organisaties, projecten en API-keys, terwijl ClickHouse de trace-data zelf bevat. Een restore van alleen Postgres levert een instantie op waar u wel op kunt inloggen, maar die verder leeg is. Maak ook een back-up van de MinIO-bucket, aangezien deze de ruwe events bevat die Langfuse bij aankomst opslaat; dit is de meest betrouwbare bron van waarheid binnen de stack.

Kan ik een bestaande OpenTelemetry-setup koppelen aan een zelfgehoste Langfuse?

Ja. Langfuse v4 en de bijbehorende v4 SDK's zijn gebouwd op OpenTelemetry, en de Anthropic- en OpenAI OTel-instrumentaties exporteren hier rechtstreeks naartoe. Voer in Python pip install langfuse opentelemetry-instrumentation-anthropic uit, roep AnthropicInstrumentor().instrument() eenmalig aan bij het opstarten en stel LANGFUSE_PUBLIC_KEY, LANGFUSE_SECRET_KEY en LANGFUSE_BASE_URL in op uw eigen host. Bevestig dit met langfuse.auth_check() voordat u op zoek gaat naar een ontbrekend dashboard.