Technische Zusammenfassung: CelerLog: Schnelle Log-Parsing durch dynamisches Routing

Problemstellung

Log-Parsing ist eine Voraussetzung für die automatisierte Systemanalyse und wandelt rohe, halbstrukturierte Log-Nachrichten in strukturierte Formate um, die aus statischen Vorlagen und dynamischen Parametern bestehen. Während syntaxbasierte Parser (z. B. Drain) eine hohe Effizienz bieten, fehlt es ihnen oft an der semantischen Reasoning-Fähigkeit, die erforderlich ist, um komplexe oder sich entwickelnde Log-Muster zu bewältigen, was zu einer geringeren Genauigkeit führt. Umgekehrt erreichen neuartige semantische Parser auf Basis von Large Language Models (LLMs) eine überlegene Genauigkeit durch die Nutzung des natürlichen Sprachverständnisses, leiden jedoch unter prohibitiver Latenz und finanziellen Kosten. Diese Kosten resultieren aus einem grundlegenden Designfehler: der Anwendung schwerer semantischer Inferenz auf jede Log-Nachricht, unabhängig davon, ob eine solche Komplexität notwendig ist. Bestehende Optimierungsstrategien wie Caching oder Sampling adressieren die Ursache nicht: die Unfähigkeit, Logs zu unterscheiden, die semantisches Reasoning erfordern, von denen, die durch einfache statistische Analyse gelöst werden können.

Methodik

Die Autoren schlagen CelerLog vor, einen hybriden Log-Parser, der Logs dynamisch basierend auf ihren statistischen Merkmalen an die am besten geeignete Verarbeitungsmaschine weiterleitet. Die Kernidee besteht darin, dass die überwiegende Mehrheit der Logs wiederkehrende Muster mit variierenden Parametern aufweist (dichte Gruppen), die durch statistische Analyse geparst werden können, während nur eine Minderheit der Logs solche Muster vermissen lässt (spärliche Gruppen) und LLM-basierte semantische Inferenz erfordert.

CelerLog besteht aus drei Hauptkomponenten:

1. Dynamischer Router

Der Router fungiert als Verkehrsleiter und klassifiziert eingehende Logs durch einen zweistufigen Prozess in dichte und spärliche Gruppen:

• Zweistufige Gruppierung:
  • Maskierungsbasierte Skelett-Gruppierung: Roh-Logs werden vorverarbeitet, um variable Token (Zahlen, Zeichenfolgen usw.) in vorgesehene Platzhalter (z. B. <NUM>, <UCL>) zu maskieren, wodurch „maskierte Skelette" entstehen. Logs mit identischen Skeletten werden gruppiert.
  • Längenbasierte Gruppierung: Diese Skelettgruppen werden basierend auf ihrer Token-Länge weiter zu „Eimern" (buckets) aggregiert, da Logs aus derselben Vorlage typischerweise dieselbe Länge aufweisen.
• Ankerbasiertes Zusammenführen: Innerhalb jedes Eimers identifiziert der Router „Anker"-Gruppen (jene mit der höchsten Anzahl eindeutiger Logs). Anschließend berechnet er die Positions-aware Jaccard-Ähnlichkeit zwischen dem Anker und anderen Gruppen.
  • Ein dynamischer Ähnlichkeitsschwellenwert wird aus der „Singleton-Ratio-Kurve" abgeleitet, um den optimalen Trennpunkt für das Zusammenführen zu bestimmen, wodurch ein übermäßiges Zusammenführen verhindert wird, während gültige Muster erfasst werden.
  • Eine leichte Verben-Prüfung stellt semantische Konsistenz sicher (z. B. dass das Kernaktionsverb gemeinsam ist).
  • Gruppen, die erfolgreich mit einem Anker zusammengeführt werden, werden als dichte Log-Gruppen klassifiziert. Nicht zusammengeführte Gruppen werden als spärliche Log-Gruppen klassifiziert.

2. Statistischer Prozessor (Schnelle Spur)

Dichte Log-Gruppen werden an dieses effiziente Modul weitergeleitet. Anstatt ein LLM aufzurufen, führt es eine direkte statistische Analyse durch:

• Es richtet die Logs in der Gruppe aus und analysiert die Werteverteilung an jeder Token-Position.
• Positionen, die mehrere unterschiedliche Werte enthalten, werden als Parameter identifiziert und mit Wildcards maskiert (z. B. <*>).
• Positionen mit einzelnen Werten werden als statische Teilstücke der Vorlage beibehalten.
• Dieser Prozess liefert die endgültige Vorlage und die Parameter mit minimalem Rechenaufwand und null Risiko von LLM-Halluzinationen.

3. LLM-basierter Prozessor (Langsame Spur)

Spärliche Log-Gruppen, die keine ausreichenden statistischen Signale aufweisen, werden an ein LLM weitergeleitet.

• Aufgabengestaltung: Um Halluzinationen und Kosten zu minimieren, wird das LLM nicht aufgefordert, die vollständige Vorlage zu generieren. Stattdessen wird es aufgefordert, eine Variablenidentifikation durchzuführen und eine Liste der exakten Variablenstrings zurückzugeben, die im Log gefunden wurden.
• Verifizierung: Das System verifiziert, dass die identifizierten Variablen im ursprünglichen Log existieren, bevor sie maskiert werden, um die endgültige Vorlage zu generieren. Falls das LLM versagt oder ungültige Ausgaben produziert, kehrt das System zum ursprünglichen Log zurück, um Fehler zu vermeiden.
• Parallelisierung: Um Skalierbarkeit zu gewährleisten, setzt CelerLog Datenparallelismus für die Routing-Phase (Verarbeitung von Eimern über CPU-Kerne hinweg) und asynchrones I/O für die LLM-Phase (Batching von Anfragen) ein.

Hauptbeiträge

1. Erkenntnis über Log-Verteilung: Die Autoren identifizieren, dass der Engpass bei bestehenden LLM-basierten Parsern die einheitliche Anwendung semantischer Inferenz ist. Sie zeigen auf, dass eine Mehrheit der Logs wiederkehrende statistische Muster besitzt, die für das Parsing ohne LLMs ausreichen.
2. Kategorisierung in Dicht vs. Spärlich: Die Arbeit definiert formal dichte Log-Gruppen (reich an statistischer Variation) und spärliche Log-Gruppen (statisch oder isoliert) und schlägt eine Hybridstrategie vor, um diesen Unterschied auszunutzen.
3. CelerLog-Rahmenwerk: Die Einführung eines dynamischen Routing-Mechanismus, der Logs entweder an einen schnellen statistischen Prozessor oder an einen LLM-basierten Prozessor leitet, wodurch sowohl Effizienz als auch Wirksamkeit maximiert werden.
4. Umfassende Evaluierung: Umfangreiche Experimente auf 14 öffentlichen Datensätzen zeigen, dass CelerLog die State-of-the-Art-Baselines in puncto Genauigkeit übertrifft und dabei Zeit und Kosten drastisch reduziert.

Experimentelle Ergebnisse

Evaluiert auf 14 öffentlichen Datensätzen (einschließlich Apache, HPC, OpenSSH und Zookeeper) zeigt CelerLog eine signifikante Überlegenheit gegenüber sowohl syntaxbasierten (Drain, AEL, Brain) als auch LLM-basierten (LILAC, LogBatcher, LUNAR) Baselines:

• Wirksamkeit: CelerLog erreicht eine durchschnittliche Gruppierungs-Genauigkeit (GA) von 0,927 und eine Parsing-Genauigkeit (PA) von 0,875 und übertrifft die beste LLM-basierte Baseline (LogBatcher) in der PA mit einem signifikanten Abstand (0,875 vs. 0,786).
• Effizienz:
  • CelerLog ist 7,9× bis 18,6× schneller als LLM-basierte Methoden.
  • Bemerkenswerterweise ist die parallele Version von CelerLog bis zu 1,5× schneller als der weit verbreitete syntaxbasierte Parser Drain.
• Kostenreduktion:
  • Token-Verbrauch: Reduziert um 80,2 %–94,1 % im Vergleich zu LLM-Methoden (z. B. von ~207.000 Token für LUNAR auf ~12.000 für CelerLog).
  • LLM-Aufrufe: Reduziert um 86,4 %–90,9 % (z. B. von ~370 Aufrufen für LUNAR auf ~34 für CelerLog).
• Robustheit: Ablationsstudien bestätigen, dass das Entfernen des Routers oder des statistischen Prozessors die Leistung erheblich verschlechtert oder die Kosten erhöht. Die Sensitivitätsanalyse zeigt, dass CelerLog robust gegenüber Hyperparametereinstellungen (Ähnlichkeitsschwellenwerte und Top-k-Auswahl) ist. Darüber hinaus behält das System über verschiedene Backbone-LLMs hinweg eine stabile Leistung bei, von großen Modellen (Gemini-3-pro) bis hin zu kleineren (Qwen3-8b).

Bedeutung

Die Arbeit behauptet, dass CelerLog eine neue Pareto-Grenze für das Log-Parsing etabliert und eine Lösung bietet, die gleichzeitig hochgenau und kosteneffektiv ist. Indem CelerLog erkennt, dass nicht alle Logs ein komplexes semantisches Verständnis erfordern, schließt es die Lücke zwischen der Geschwindigkeit syntaxbasierter Parser und der Genauigkeit semantischer Parser. Die Autoren positionieren diese Arbeit als praktischen Enabler für die reale, großskalige Log-Analyse, bei der die prohibitiven Kosten aktueller LLM-basierter Ansätze deren Einsatz bisher eingeschränkt haben. Der hybride Ansatz stellt sicher, dass teure LLM-Ressourcen nur für die Logs reserviert werden, die sie tatsächlich benötigen, wodurch die automatisierte Log-Analyse skalierbar und wirtschaftlich tragfähig wird.