Skip to main content
Localmind exportiert Trace-Daten (Aufrufketten) über den offenen Standard OpenTelemetry (OTLP) — der Export ist eingebaut, damit binden Sie ein selbst betriebenes Langfuse an. Die Anbindung besteht aus zwei Zeilen in backend/.env und einem Neustart des Backend-Containers.
Die eingebauten Ansichten für Nutzung und Systemzustand (Analytik, Audit-Logs, System-Info) sind unter Observability beschrieben.
Das Grafana/Tempo/Loki-Szenario für Infrastruktur-Monitoring ist in der On-Premise-Deployment-Checkliste beschrieben, die Sie mit Ihren Installationsunterlagen erhalten. Parallel lassen sich beide Szenarien nur über einen OTel-Collector als Verteiler betreiben — stimmen Sie das mit Localmind ab.

​
Voraussetzungen

​
Einrichtung

1

Langfuse vorbereiten

Legen Sie in der Langfuse-Oberfläche ein Projekt an (z. B. „Localmind Produktion”). Erstellen Sie im Projekt unter Settings → API Keys → Create new API keys ein Schlüsselpaar und notieren Sie beide Werte: Public Key (pk-lf-…) und Secret Key (sk-lf-…, wird nur einmal angezeigt).Der OTLP-Empfangsendpunkt lautet:
Langfuse nimmt OTLP über HTTP (http/protobuf) an, nicht über gRPC.
2

Zugangsdaten als Auth-Header vorbereiten

Langfuse authentifiziert eingehende Traces per HTTP Basic Auth mit den Projekt-Schlüsseln. Erzeugen Sie den Base64-Wert aus publickey:secretkey:
Verwenden Sie echo -n — ohne -n gerät ein Zeilenumbruch in den Wert und die Authentifizierung schlägt fehl. Versenden Sie den Secret Key nicht per E-Mail oder Chat.
3

Localmind konfigurieren

Ergänzen Sie in backend/.env im Installationsverzeichnis der Instanz zwei Zeilen (Werte ohne Anführungszeichen):
backend/.env
Binden Sie nur das Backend an — dort entstehen die Traces. Die Frontend-Variable PUBLIC_OTEL_EXPORTER_OTLP_ENDPOINT gehört zum Grafana-Szenario und bleibt leer.Die Datei ist berechtigungsgeschützt (0600) — verändern Sie die Berechtigungen nicht.
4

Backend neu starten

5

Verifizieren

  1. Führen Sie in Localmind einen kurzen Test-Chat mit einem Agenten.
  2. Öffnen Sie in Langfuse das Projekt: Tracing → Traces, Zeitraum „letzte Stunde”.
  3. Neue Trace-Einträge erscheinen; der Export arbeitet gepuffert, die ersten Einträge können 1–2 Minuten verzögert sein.
Sie sehen die Aufrufketten des Backends (HTTP-, Datenbank-, Redis- und externe Aufrufe sowie KI-Aufrufe); die Detailtiefe der KI-spezifischen Attribute ist versionsabhängig.

​
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.