Stille Lücken im Tracing und Speicherplatzverschwendung bei selbst gehostetem Langfuse

Ein Entwickler entdeckte, dass seine selbst gehostete Observability-Plattform Langfuse nur einen Bruchteil der Aktivitäten seiner AI-Agents erfasste, was zu irreführenden Leistungsdaten führte. Die Untersuchung ergab, dass Konfigurationsfehler stille Überwachungsausfälle bei den meisten Agent-Profilen verursachten, während die zugrunde liegende Datenbank Gigabytes unnötiger interner Protokolle ansammelte.

Was passiert ist

Das Problem wurde offensichtlich, als ein AI-Agent fünfundzwanzig Minuten brauchte, um auf einen einfachen Befehl zur Antwort in einem Forum zu reagieren. Anstatt die Aufgabe auszuführen, generierte das Modell eine erfundene Zusammenfassung des Zielartikels. Der Entwickler konsultierte seine Langfuse-Traces, um die Verzögerung zu diagnostizieren, und erwartete Netzwerklatenzen oder Engpässe bei der Tool-Ausführung. Die Trace-Daten zeigten, dass Web-Tools in unter fünf Sekunden ausgeführt wurden, während das lokale Sprachmodell über fünfundzwanzig Minuten mit der Verarbeitung beschäftigt war. Die Ursache war nicht die Leistung, sondern der Kontext: Die Agent-Sitzung hatte begonnen, bevor die Posting-Fähigkeit verfügbar war, sodass das Modell improvisierte, anstatt ein fehlendes Tool zu verwenden.

Dieser Vorfall veranlasste eine tiefere Prüfung des Observability-Setups. Der Entwickler verglich die Anzahl der in der internen Datenbank des Agents aufgezeichneten Sitzungen mit den in Langfuse gespeicherten Traces über einen Zeitraum von vierzehn Tagen. Der Agent hatte 1.387 Modellaufrufe in 188 Sitzungen ausgeführt, doch Langfuse enthielt nur 618 Ereignisse aus 79 Traces. Weitere Analysen zeigten, dass das Tracing nur bei einem von zehn Agent-Profilen aktiviert war, was bedeutet, dass das System etwa 7 % des gesamten Traffics überwachte. Die aktivsten Profile, einschließlich solcher für Coding- und Sicherheitsaufgaben, waren für die Observability-Plattform vollständig unsichtbar.

Der zweite wichtige Befund betraf die Speichernutzung. Langfuse Version 3 verwendet ClickHouse als primären Trace-Speicher, neben PostgreSQL und Redis. Während die tatsächlichen Trace-Daten nur 2,2 MiB belegten, nutzte die ClickHouse-Instanz über 6 GiB Festplattenspeicher. Der Großteil dieses Platzes wurde von den eigenen Diagnosesystemtabellen von ClickHouse verbraucht, wie Trace-Logs und Metrik-Logs, die kontinuierlich schrieben. Diese übermäßige Protokollierung erzeugte erheblichen I/O-Overhead auf dem Host-Rechner und trug zu periodischen Leistungseinbrüchen auf der Festplatte bei.

Wichtige Details

• Das Tracing war nur bei einem von zehn Agent-Profilen aktiv und erfasste ungefähr 7 % aller Modellaufrufe.
• Zu den nicht getrackten Profilen gehörten hochvolumige Agents für Coding-, Sicherheits- und IT-Administrationsaufgaben.
• ClickHouse-Systemprotokolle verbrauchten 6,03 GiB Festplattenspeicher, während die tatsächlichen Trace-Daten nur 2,2 MiB belegten.
• Das Tracing-Plugin schlägt still fehl, wenn API-Schlüssel fehlen, ohne Fehlermeldungen oder Warnungen in den Logs bereitzustellen.
• Einmalige Jobs, die im Safe-Mode laufen, umgehen Plugins vollständig und erfordern eine separate SDK-Integration für das Tracing.
• Das Entfernen von ClickHouse-Systemprotokolltabellen über die Konfiguration stoppt neue Schreibvorgänge, löscht aber vorhandene Daten nicht automatisch.

Hintergrund

Langfuse ist eine Open-Source-Observability-Plattform, die für Anwendungen mit großen Sprachmodellen entwickelt wurde. Sie hilft Entwicklern, Kosten, Latenz und Nutzerfeedback zu verfolgen, indem sie Traces der Interaktionen zwischen Agents und Modellen aufzeichnet. Das Selbsthosting von Langfuse gibt Teams die Kontrolle über ihre Daten, erfordert jedoch die Verwaltung der zugrunde liegenden Infrastruktur, einschließlich der Datenschicht. In Version 3 verlässt sich Langfuse auf ClickHouse, ein spaltenorientiertes Datenbankmanagementsystem, das für Online Analytical Processing (OLAP) optimiert ist. ClickHouse ist leistungsstark bei der Verarbeitung großer Mengen von Zeitreihendaten, umfasst jedoch umfangreiche interne Logging-Funktionen, die die eigene Leistung und Operationen überwachen.

Fail-open-Designmuster sind in Software-Plugins üblich, um sicherzustellen, dass eine fehlende Abhängigkeit die Hauptanwendung nicht zum Absturz bringt. In diesem Kontext deaktiviert sich das Tracing-Plugin einfach selbst, wenn es keine gültigen API-Zugangsdaten findet, anstatt einen Fehler zu werfen. Dies verhindert zwar Anwendungsabstürze, erzeugt aber eine blinde Stelle, an der die Überwachung stoppt, ohne den Betreiber zu alarmieren. Das Verständnis des Unterschieds zwischen anwendungsseitigen Fehlern und stillen Konfigurationslücken ist entscheidend für die Aufrechterhaltung einer zuverlässigen Observability in verteilten Systemen.

Warum es wichtig ist

Für Teams, die ihre eigene AI-Infrastruktur betreiben, kann unvollständige Observability zu falschen Schlussfolgerungen über Systemleistung und Kosten führen. In diesem Fall vermutete der Entwickler zunächst Netzwerkprobleme aufgrund der langen Antwortzeit, aber der Trace zeigte, dass das Problem im Modellreasoning innerhalb einer veralteten Sitzung lag. Wenn das Tracing beim Coding-Agent aktiv gewesen wäre, der den Großteil der Aufrufe ausmachte, hätte das Team Einblick gehabt, wie oft lokale Modelle Latenzspitzen erreichten im Vergleich zu Cloud-Alternativen. Ohne umfassendes Tracing basieren Entscheidungen zur Ressourcenzuweisung auf Gewohnheiten statt auf Daten, was potenziell zu ineffizienter Nutzung teurer GPU-Ressourcen oder Cloud-APIs führt.

Speichermanagement ist eine weitere praktische Sorge für selbst gehostete Dienste. Diagnoseprotokolle sind nützlich für die Fehlersuche bei der Datenbankleistung, können aber schnell kleine Bereitstellungen überwältigen. Wenn interne Protokolle tausendmal mehr Platz verbrauchen als die tatsächlichen Anwendungsdaten, verschlechtern sie die Festplattenleistung und erhöhen die Backup-Zeiten. Für Betreiber, die Homelabs oder kleine Servercluster verwalten, kann unkontrolliertes Log-Wachstum zu Dienstunterbrechungen führen oder häufige manuelle Bereinigungen erfordern. Die Konfiguration der Datenbank, um nur relevante Betriebsdaten aufzubewahren, stellt sicher, dass die Observability-Plattform leichtgewichtig und nachhaltig bleibt.

Was Sie tun können

• Vergleichen Sie die Anzahl der in Ihren Anwendungslogs aufgezeichneten Anfragen mit der Anzahl der Traces in Ihrer Observability-Plattform, um Deckungslücken zu identifizieren.
• Stellen Sie sicher, dass API-Schlüssel und Tracing-Plugins für jedes Agent-Profil, jeden Worker und jeden Service konfiguriert sind, nicht nur für das Standardprofil.
• Senden Sie eine Testanfrage von jedem einzelnen Agent-Profil und bestätigen Sie, dass ein markierter Trace im Dashboard erscheint.
• Untersuchen Sie die ClickHouse-Systemtabellen, um festzustellen, ob Diagnoseprotokolle einen unverhältnismäßig hohen Anteil des Festplattenspeichers im Verhältnis zu Ihren Daten belegen.
• Wenden Sie eine benutzerdefinierte Konfigurationsdatei an, um unnötige ClickHouse-Systemprotokolle zu deaktivieren und angemessene Aufbewahrungsfristen für Query-Logs festzulegen.
• Planen Sie regelmäßige Audits der Tracing-Konfigurationen, insbesondere nach Infrastrukturänderungen wie Updates der Serveradresse oder Rotation von Zugangsdaten.