Füg ein Log ein oder öffne eine Datei, und dieses Werkzeug versteht es: Es erkennt das Format, fasst die Zeilen zu Ereignissen zusammen (ein Stacktrace mit 40 Zeilen ist EIN Ereignis, nicht 40), holt die wiederkehrenden Muster heraus, zeigt die Grundursache der Ausnahmen und kürzt es, damit du es einer KI vorlegen kannst, ohne ein Vermögen an Tokens auszugeben. Alles in deinem Browser: Das Log verlässt deinen Rechner nicht.
Wenn du Zeile für Zeile nach ERROR filterst, behältst du den Kopf des Fehlers und verlierst den Stacktrace, also genau das, was du lesen wolltest. Hier werden die Fortsetzungen (at …, Caused by:, File "…", line N) an ihr Ereignis geklebt, bevor gefiltert, gezählt oder gekürzt wird.
«verbunden mit 10.0.0.1» und «verbunden mit 10.0.0.7» sind dieselbe Meldung. Gruppiert man sie, wird aus einem Log mit einer Million Zeilen zweihundert Dinge, die ein Mensch lesen kann. Daraus ergeben sich die Fehlerquote pro Muster, das, was nur ein einziges Mal auftaucht (meist genau das, was du gesucht hast), und der Vergleich zwischen zwei Läufen.
Kürzt das Log auf ein Token-Budget, das du festlegst, und behält die Fehler mit ihrem Stacktrace, was direkt davor passierte und das Außergewöhnliche; Wiederholtes wird mit seiner Anzahl zusammengefasst. Die Tokens werden mit dem echten Tokenizer des Modells gezählt, nicht geschätzt. Und du kannst vor dem Kopieren die Geheimnisse abdecken.
Prüft, ob dein Log gut geschrieben ist: ausgegebene Passwörter, dieselbe Zeile vierzigtausendmal, Datumsangaben ohne Zeitzone (die es unmöglich machen, zwei Maschinen zu verknüpfen), alles auf demselben Level, oder keine Kennung, mit der man eine Anfrage verfolgen könnte.
Was docker logs als JSON ausgibt, Kubernetes (CRI), journalctl -o json, OpenTelemetry (OTLP JSON) oder CloudTrail kommt verpackt an: Der Text deiner Anwendung steckt darin, und zerteilt. Eine Java-Stacktrace kommt als vierzig einzelne Einträge an. Die Verpackung wird erkannt, der Text darin wird herausgeholt, die Teile werden wieder zusammengefügt und es wird analysiert, als wäre es das Original-Log; das Datum und die Stufe der Verpackung werden nur verwendet, wenn der Text keine eigenen mitbringt.
Filtere, was dich interessiert (die Fehler, einen Zeitbereich), und klicke auf Was unterscheidet…?: Es sagt dir, welche Feld=Wert-Paare dort viel häufiger vorkommen als im Rest des Logs. «92 % der Fehler sind version=2.4.1, gegenüber 10 % im Rest» ist der Hinweis, den du nicht siehst, wenn du dreihundert Fehler einzeln liest. Es ist ein Vergleich von Anteilen, kein statistischer Test: Die Ereignisse eines Logs sind nicht unabhängig.
Wie Filebeat, Fluent Bit, Alloy und Vector dieses gleiche Log mit ihrer mehrzeiligen Regel gruppieren würden, neben wie dieses Tool es gruppiert, mit den Unterschieden markiert: So siehst du, vor dem Deployment, dass dein Collector die Stacktraces zerteilen wird. Und es schreibt dir die Regel für alle vier aus dem Erkannten, im Dialekt der regulären Ausdrücke jedes einzelnen.
Wie tail -f. Öffne die Datei mit Datei(en) öffnen und aktiviere Live verfolgen: Alle 2 Sekunden wird geprüft, ob sie gewachsen ist, und wenn ja, wird das Ende neu gelesen und der Betrachter springt zum Letzten. Wenn sie abgeschnitten oder rotiert wird, wird es angezeigt. Es braucht einen Browser, der eine bereits gewählte Datei erneut lesen lässt (Chrome oder Edge am Computer); in den anderen erscheint der Schalter nicht, und das Öffnen eines Ordners liefert weiterhin den heutigen Stand einer rotierten Serie.
Es verbindet sich mit keinem Server: Was live verfolgt wird, ist eine Datei auf deiner Festplatte, kein Netzwerkstream. Von einer sehr großen Datei wird ein Fenster analysiert (Anfang oder Ende), und dir wird gesagt, welches — um Hunderte von GB zu durchlaufen, gibt es den Betrachter für riesige Dateien.