Skip to main content
Langfuse zeichnet auf, was das LLM tatsächlich getan hat: den gesendeten Prompt, die zurückgelieferte Antwort, aufgerufene Tools sowie Token-Verbrauch, Latenz und Kosten je Aufruf. Das funktioniert mit jedem Modell — Cloud wie self-hosted —, denn das Tracing passiert auf Localmind-Seite. Sie binden Langfuse über wenige Variablen in backend/.env an; als Ziel dient Langfuse Cloud oder eine selbst betriebene Langfuse-Installation. Die Anbindung ist getrennt vom OpenTelemetry-Export für Infrastruktur-Monitoring (Grafana): Der sieht nur HTTP-, Datenbank- und Redis-Spans und nie Prompts oder Completions. Beide können parallel laufen. Die eingebauten Ansichten für Nutzung und Systemzustand sind unter Observability beschrieben; was Sie in den Langfuse-Traces sehen und wie Sie sie filtern, unter Langfuse-Traces auswerten.
Langfuse-Tracing ist ein lizenzpflichtiges Feature — dieselbe Freischaltung wie der OTLP-Trace-Export. Ohne Freischaltung bleibt das Tracing still ausgeschaltet, auch wenn alles korrekt konfiguriert ist. Die Freischaltung ist Teil Ihrer Lizenz — stimmen Sie sie mit Localmind ab.

​
Voraussetzungen

​
Einrichtung

1

Langfuse-Schlüssel erstellen

Legen Sie in Langfuse ein Projekt an (z. B. „Localmind Produktion”). Erstellen Sie in der Langfuse-Oberfläche unter Project Settings → API Keys ein Schlüsselpaar und notieren Sie beide Werte: Public Key (pk-lf-…) und Secret Key (sk-lf-…, wird nur einmal angezeigt).
2

Env-Variablen setzen

Alle Einstellungen liegen in backend/.env im Installationsverzeichnis Ihrer Instanz:Ein typischer Block:
backend/.env
3

Backend und Worker neu starten

Chat-Konversationen laufen im Worker-Prozess. Wenn Sie nur das Backend neu starten, erhalten Sie Traces für die Dokumenten-Analyse, aber keine Chat-Traces.
4

Verifizieren

Prüfen Sie nach dem Neustart das Backend-Log (docker compose logs backend) — genau eines dieser Events erscheint:Senden Sie danach eine Chat-Nachricht und öffnen Sie in Langfuse Tracing → Traces — neue Traces erscheinen innerhalb weniger Sekunden.Das Tracing ist fail-safe: Ist Langfuse nicht erreichbar oder falsch konfiguriert, funktioniert Localmind normal weiter — es fehlen nur die Traces.

​
Self-hosted Langfuse

Betreiben Sie Langfuse selbst, muss LANGFUSE_BASE_URL aus den Backend- und Worker-Containern per HTTP/S erreichbar sein — Langfuse unterstützt kein gRPC. Sitzt Ihre Installation hinter einer internen Zertifizierungsstelle (CA), muss das Zertifikat in beiden Containern als vertrauenswürdig hinterlegt sein. Richtwerte für die Server-Größe finden Sie unter Dimensionierung.

​
Datenschutz und Trace-Volumen

Mit LANGFUSE_MASK_IO=true ersetzt Localmind jeden Prompt und jede Completion durch <redacted:LANGFUSE_MASK_IO>. Struktur, Modell- und Tool-Namen, Token-Zahlen, Latenz und Kosten bleiben sichtbar — nur der Inhalt fehlt. Nutzen Sie diese Einstellung, wenn kein Prompt-Text die Instanz verlassen darf, Sie aber Performance- und Kosten-Transparenz behalten wollen. LANGFUSE_SAMPLE_RATE steuert das Volumen: 1.0 zeichnet jeden Run auf — sinnvoll für Qualitätssicherung und beim Eingrenzen eines gemeldeten Problems. Auf Produktivinstanzen mit hohem Aufkommen senken Sie den Wert, wenn Trace-Volumen oder Langfuse-Kosten zum Problem werden.
Haben Sie die frühere OTLP-Anbindung eingerichtet (OTEL_EXPORTER_OTLP_ENDPOINT auf …/api/public/otel), stellen Sie auf die native Integration um: Setzen Sie die LANGFUSE_*-Variablen wie oben beschrieben — die OTEL_-Zeilen für Langfuse entfallen.

​
Fehlerbehebung

​
Dimensionierung des Langfuse-Servers (Richtwerte)

Ein selbst betriebenes Langfuse besteht aus vier Komponenten: Im Standard-Docker-Setup laufen alle vier auf einer VM; der Blob-Speicher ist der größte Speichertreiber. Offizielle Anhaltspunkte:
  • Langfuse veröffentlicht bewusst keine festen Sizing-Zahlen (Stand Juli 2026).
  • Persistentes Volume ab 100 GB als Startwert.
  • Kubernetes-Produktivsetups: Ressourcen-Preset „large”, 3 Replicas.
  • Postgres und ClickHouse zwingend in Zeitzone UTC.
Die folgenden Werte sind eine Modellrechnung — nach etwa 4 Wochen Realbetrieb am tatsächlichen Verbrauch nachkalibrieren.
Beispiel: 1.000 aktive Nutzer × 10 KI-Anfragen je Arbeitstag ≈ 210.000 Traces/Monat. Bei Ø 100 KB je Trace (Prompt, Antwort, RAG-Kontext, Metadaten) ≈ 40 GB/Monat; bei 12 Monaten Aufbewahrung ≈ 500 GB — mit Reserve also eine 1-TB-Disk. Multimodale Inhalte (Bilder/Audio) erhöhen die Ø-Trace-Größe deutlich — wählen Sie dann die nächsthöhere Stufe.
Retention konfigurieren statt unbegrenzt sammeln — die Aufbewahrungsdauer ist der größte Hebel für den Speicherbedarf.