Log-Analysator-Plugin

Macht den Editor zu einer vollwertigen Log-Werkbank: strukturierte Protokolldateien über editierbare Profile parsen, nach geparsten Feldern und Zeitstempeln navigieren, mehrere Quellen auf einer Zeitachse zusammenführen, eine einzelne Anfrage über Quellen hinweg verfolgen und Raten / Perzentile / Top-N-Werte analysieren — alles, ohne den Rohtext in einen normalen Editor-Tab zu laden.

Wo Sie es finden

Das Plugin fügt dem Menü Log-Analysator drei Einträge hinzu:

• Log-Analysator ▸ Als Log öffnen… — eine einzelne Protokolldatei in einem dedizierten Log-Ansichtsfenster öffnen.
• Log-Analysator ▸ Zusammengeführte Logs öffnen… — zwei oder mehr Dateien wählen, jeder ihr Profil geben und sie verschränkt auf einer Zeitachse sehen.
• Log-Analysator ▸ Systemlog öffnen… (nur Windows) — das Windows-Ereignisprotokoll in derselben Ansicht abfragen, mit Filtern, die an PowerShells Get-WinEvent durchgereicht werden.

Eine Seite Einstellungen ▸ Erweiterungen ▸ Log-Analysator erlaubt die Standard-Level-Chips, das Fallback-Profil für Dateien ohne Glob-Treffer, die Schwelle „vor dem Parsen von Dateien über N MB warnen“, den Standard-Filtermodus und das Follow-Tail-Abfrageintervall — ein Regler für den Datei-Tail-Timer und den Systemlog-Strom (jede Abfrage des Windows-Ereignisprotokolls startet einen PowerShell-Prozess, schwere Quellen mögen es also langsamer).

Große Dateien parsen in einem Hintergrund-Thread mit Live-Datensatzzähler, und die teuren Aggregationen (Nachrichten-Vorlagen, Anomalien) rechnen ebenfalls im Hintergrund — die Statusleiste zeigt „Analysiere Statistiken im Hintergrund…“, und die Panels füllen sich, sobald fertig; das Fenster bleibt durchgehend reaktionsfähig. Bei sehr großen Ladungen aggregieren die Statistiken über die neuesten 150 000 Datensätze, und die Zeitachse tastet die gesamte Spanne ab.

Einzeldatei-Log-Ansicht

Das Öffnen eines Logs zeigt das dedizierte Fenster Log-Ansicht. Es spiegelt die Ergonomie der tabellenbasierten Fenster des Editors (wie das Vergleichsfenster) und bleibt der Tab-Leiste des Editors fern.

Aufbau

• Werkzeugleiste — Level-Chips (TRACE…FATAL), Filtermodus + Filterzeile, Nächster / Vorheriger Fehler (F8 / Shift+F8), Gehe zu Zeit (Ctrl+G).
• Zeitachsen-Streifen oben — Ereignisvolumen in Zeit-Eimern, nach Level gefärbt. Einen Bereich ziehen filtert nach Zeit; ein Klick auf einen Balken springt in der Tabelle zum ersten Datensatz ab diesem Eimer.
• Tabelle in der Mitte — Zeit / Level / Quelle / Nachricht, virtualisiert, scrollt also auch bei Hunderttausenden Datensätzen flüssig.
• Detailbereich unter der Tabelle — der vollständige rohe mehrzeilige Eintrag der gewählten Zeile.
• Statistik-Panel rechts angedockt — Zähler pro Level, Ereignisrate, Perzentil-Auswahl (p50/p95/p99 über ein beliebiges numerisches Feld, Standard bytes), Verteilung der HTTP-Statusklassen (1xx…5xx, verborgen ohne status-Feld) und eine Top-N-Tabelle über ein beliebiges Feld (Standard url, gedeckelt bei 25 Zeilen).

Die Datensatztabelle und der Detailbereich verwenden die Editorschrift aus Einstellungen ▸ Allgemein — dieselbe Schriftart und -größe wie ein normaler Editor-Tab, sodass Zeitstempel und Level Spalte für Spalte fluchten. Eine Änderung dieser Einstellung wirkt auch auf bereits geöffnete Log-Ansichten, ohne sie neu zu öffnen. Dasselbe gilt für die zusammengeführte Ansicht, ihre Nebeneinander-Bereiche und das Sequenzdiagramm. Werkzeugleiste, Filterzeile und Statistikpanel behalten die Oberflächenschrift: Sie sind Rahmen, nicht Log-Inhalt.

Filtermodi

Die Filterzeile akzeptiert fünf Ausdrucksarten; den Modus wählen Sie in der Combo links daneben:

Modus	Was er matcht
Einfach	Teilzeichenkette ohne Groß-/Kleinschreibung gegen die Rohzeile.
Wörter	Leerraum-getrennte Tokens; jedes Token muss irgendwo in der Zeile vorkommen, in beliebiger Reihenfolge. phpinfo GET trifft eine Zeile mit phpinfo und GET.
Platzhalter	*- und ?-Glob gegen die Rohzeile, ohne Groß-/Kleinschreibung.
Regex	Ein QRegularExpression-Muster, standardmäßig ohne Groß-/Kleinschreibung.
Abfrage	Strukturierte Grammatik mit Feld-, Level- und Zeit-Prädikaten plus AND/OR/NOT und Klammern.

Beispiele für den Abfrage-Modus:

level>=WARN
status:500 AND method:POST
message~/timeout|refused/ AND @time in [09:00..09:05]
NOT (source:nginx OR source:apache)
level>=ERROR OR (status:5\d\d AND method:POST)

Die Filterzeile entprellt die Eingabe um 200 ms, damit die Tabelle nicht bei jedem Tastendruck neu filtert; Enter oder Fokusverlust wendet sofort an, das Leeren der Zeile ebenfalls. Kompiliert ein Platzhalter-/Regex-/Abfrage-Ausdruck nicht, färbt sich die Zeile rot und der Tooltip zeigt die Diagnose — der Proxy behält den letzten gültigen Filter auf dem Schirm, die Tabelle leert sich also nicht während des Tippens.

Navigation

• F8 / Shift+F8 — nächster / vorheriger Fehler- oder Fatal-Datensatz.
• Ctrl+G — zu einer bestimmten Zeit gehen (UTC, Kalender-Popup).
• Ein Klick auf einen Zeitachsen-Balken springt zum ersten Datensatz des Eimers.

Diese drei Kürzel sind im Tastenkürzel-Zuordner neu belegbar (Kategorie Log Analyzer); offene Log-Ansichten übernehmen eine Neubelegung sofort, und die Tooltips der Werkzeugleiste zeigen das aktuelle Kürzel.

Live-Parsen + Abbrechen

Große Dateien zeigen Datensätze binnen Dutzenden Millisekunden; das Parsen läuft im Hintergrund weiter, und die Tabelle wächst mit eintreffenden Datensätzen. Filtern, Scrollen und F8 funktionieren, während das Parsen noch läuft. Das Schließen des Fensters stoppt den Worker zügig.

Zusammengeführte Log-Ansicht

Log-Analysator ▸ Zusammengeführte Logs öffnen… dient der Untersuchung eines Problems über mehrere Quellen — Client- plus Server-Log, App-Log plus Systemjournal, Web-Access plus -Error usw.

Die Profilwahl pro Datei

Nach der Wahl von zwei oder mehr Dateien erscheint ein kleiner Dialog mit einer Zeile pro Datei und einer Profil-Combo pro Zeile. Die Combo ist vorbelegt durch Abgleich des Dateinamens mit den Dateinamen-Globs jedes Profils (ohne Groß-/Kleinschreibung). Für ein typisches nginx-Deployment wählt access.log automatisch nginx — access log (default combined) und error.log automatisch nginx — error log. Vor OK lässt sich jede Zeile manuell übersteuern.

Aufbau

• Werkzeugleiste — Level-Chips, Filterzeile mit Modus-Combo, Trace-Bedienelemente (Combo + Verfolgen / Leeren), Umschalter Sequenzdiagramm, Umschalter Nebeneinander.
• Zeitachsen-Streifen oben — gestapeltes Histogramm pro Quelle mit einer Spur je Quelle, korrelierte Ausbrüche sieht man also visuell.
• Trace-Banner über der Tabelle — bernsteinfarbener Streifen nur bei aktivem Trace-Filter: Folge <field> = <value> — N Zeilen über alle Quellen hinweg.
• Gestapelter Hauptbereich — drei Seiten, umschaltbar aus der Werkzeugleiste:
  • Tabelle (Standard): eine Zeile pro zusammengeführtem Datensatz mit den Spalten Zeit / Quelle / Level / Logger / Nachricht; die Vordergrundfarbe der Quellspalte ist die Spurfarbe der Quelle, die Quellidentität erfasst man also im Vorbeigehen.
  • Sequenzdiagramm — siehe Trace verfolgen.
  • Nebeneinander-Ansichten — siehe Nebeneinander.
• Detailbereich unter der Tabelle.

Filter, die sich kombinieren

In der zusammengeführten Ansicht läuft die Filter-Pipeline in dieser Reihenfolge, alles baut aufeinander auf:

1. Quellsichtbarkeit — ein Kästchen im linken Rand der Zeitleiste, eines je Spur, neben Name und Farbe der Quelle. Eine abgewählte Spur behält ihre Zeile, abgeblendet: sie muss es, denn dieses Kästchen ist der einzige Weg zurück. Rechtsklick auf den Rand bietet Nur diese Quelle anzeigen / Alle Quellen anzeigen.
2. Level-Chips — TRACE…FATAL.
3. Trace verfolgen — siehe unten.
4. Textfilter — Einfach / Wörter / Platzhalter / Regex / Abfrage (dieselben Modi und dasselbe Verhalten wie in der Einzeldatei-Ansicht, angewendet auf den zusammengeführten Strom).

Sie können also z. B. level>=ERROR AND status:500 über nginx-Access- und -Error-Logs in einem Ausdruck ausführen und einen einzelnen Client durch beide verfolgen — der Trace-Filter engt die Menge weiter ein, ohne die Level-/Quell-/Textfilter zu brechen.

Trace verfolgen

1. Wählen Sie einen Korrelationsschlüssel in der Trace:-Combo der Werkzeugleiste. Sie ist mit dem üblichen Satz vorbelegt (trace_id / request_id / session_id / correlation_id / span_id / xRequestId) plus jedem tatsächlich in den geladenen Datensätzen vorkommenden Feldnamen. Bei Bedarf einen eigenen Namen tippen.
2. Eine Zeile in der Tabelle auswählen.
3. Trace folgen klicken — oder die Zeile rechtsklicken und Trace folgen: \<field>=\<value> für einen der üblichen Schlüssel wählen, die der Datensatz trägt (ein Ein-Schritt-Weg ohne die Combo).

Die Tabelle filtert sofort auf die Datensätze, die den Wert dieses Schlüssels über alle Quellen teilen. Trace löschen entfernt den Filter.

Sequenzdiagramm

Sobald ein Trace-Filter aktiv ist und genau 2–4 Quellen sichtbar sind, wird der Umschalter Sequenzdiagramm verfügbar. Er schaltet den Hauptbereich auf ein Diagramm mit festen Spuren:

• Jede sichtbare Quelle ist eine vertikale Spur, oben mit farbigem Feld beschriftet.
• Eine Zeile pro Datensatz, die Zeit fließt von oben nach unten. Der echte Zeitstempel steht links, Präzision geht also nicht verloren; die Zeilen sind rangbasiert (feste Höhe) statt zeitproportional, weil ein echter Trace Ausbrüche plus lange Pausen hat und eine zeitproportionale Achse den Großteil des Bildschirms an die Pausen verschwenden würde.
• Ein farbiger Punkt auf der Spur der besitzenden Quelle plus ein dezenter grauer Pfeil zwischen aufeinanderfolgenden Datensätzen auf verschiedenen Spuren — man sieht den Trace buchstäblich zwischen den Systemen springen.
• Level-Chip und Nachrichtentext rechts.

Ein Klick auf eine Diagrammzeile scrollt die zugrundeliegende Tabelle zu diesem Datensatz. Den Umschalter ausschalten führt zur Tabelle zurück.

Bei >4 Quellen ist das Diagramm deaktiviert, die Tabellenansicht bleibt.

Nebeneinander-Ansichten

Sind genau zwei Quellen sichtbar, wird der Umschalter Nebeneinander verfügbar. Er teilt den Hauptbereich in zwei Tabellenbereiche — je eine Quelle — mit über den Zeitstempel gekoppelten Scroll-Positionen: Scrollen Sie einen Bereich, folgt der andere zum nächstgelegenen Datensatz ab dieser Zeit. Drift zwischen Server-Uhren zeigt sich natürlich als Auseinanderziehen der Bereiche.

Die Umschalter Sequenzdiagramm und Nebeneinander schließen sich gegenseitig aus (das Einschalten des einen schaltet den anderen ab); beide fallen auf die Tabellenansicht zurück, wenn die Zahl der aktiven Quellen ihren unterstützten Bereich verlässt.

Rotationssätze sind eine Spur

Drei Dateien aus einem Rotationssatz auszuwählen heißt, ein Log auszuwählen — sie werden daher als eine Spur geladen. Der Auswahldialog zeigt eine Zeile je Spur mit ihren Segmenten darunter, das älteste zuerst, und die Spur trägt den Namen ihrer neuesten Datei mit der Anzahl der älteren — MxAPILog.txt (+2).

Rechtsklick auf eine Spur in der Zeitleiste bietet Jede rotierte Datei einzeln anzeigen und, sobald getrennt, Rotierte Dateien zu einer Spur zusammenführen. Das Trennen ist eine Neuaufteilung dessen, was bereits im Speicher liegt — es wird nichts erneut gelesen — ändert aber die Bedeutung einer Zeile, weshalb die Tabelle ihre Auswahl verliert.

Quellen müssen vergleichbare Zeiten angeben

Eine Zusammenführung legt Datensätze mehrerer Quellen auf eine Achse, was nur dann etwas bedeutet, wenn alle gleich viel Datum angeben können. Ein Syslog ohne Jahr lässt sich ohne Erfindung des Jahres nicht gegen ein datiertes Log stellen, und ein Build-Log ganz ohne Zeitstempel überhaupt nicht. Das Mischen wird vorab abgelehnt, mit einer Meldung, welche Quellen zu welcher Gruppe gehören. Führen Sie Quellen gleicher Art zusammen oder öffnen Sie sie einzeln.

Wiederherstellung

Eine zusammengeführte Ansicht kehrt mit der Sitzung zurück. Gespeichert werden das je Spur gewählte Profil und die Dateien, zu denen diese Spur aufgelöst wurde; die Datensätze werden im Hintergrund neu eingelesen, sodass der Tab sofort erscheint und sich füllt. Verschwundene Dateien und gelöschte Profile werden übersprungen und protokolliert, statt beim Start zu einer Rückfrage zu werden.

Native Systemprotokolle (Windows)

Log-Analysator ▸ Systemlog öffnen… fragt das Windows-Ereignisprotokoll ab, ohne eine Datei auf der Festplatte zu brauchen. Der Dialog fragt nach einem Kanal (Application / System / Security / eigener Name), einem optionalen Mindest-Level und einer Datensatzobergrenze. Das Plugin ruft PowerShells Get-WinEvent | ConvertTo-Json -Compress mit durchgereichtem Filter auf und parst die NDJSON-Ausgabe mit dem mitgelieferten Profil windows-event-log.

Die Aktion wird nur registriert, wenn der Host tatsächlich eine funktionierende Windows-Ereignisprotokoll-Quelle hat — unter Linux und macOS fehlt sie wirklich, statt ausgegraut zu sein.

Quellen für das macOS Unified Log und Linux journald sind geplant und fügen sich hinter dieselbe interne Schnittstelle ein, ohne UI-Änderungen, wenn sie landen.

Profile

Die Engine hat keine eingebauten Spezialparser. Jedes unterstützte Format — Apache, nginx, syslog, JSON Lines, logfmt, CSV, Windows-Ereignisprotokoll — ist eine LogProfile-JSON-Datei im Verzeichnis log-profiles/ der Anwendung. Benutzerprofile liegen im Ordner log-profiles/ des Benutzer-Konfigurationsverzeichnisses und übersteuern mitgelieferte nach id.

Jedes Profil beschreibt:

• Zeilenmodell — regex, json, logfmt, csv oder delimited.
• Zeitstempel — welches Feld, akzeptierte Formate im strftime-Stil, Quell-Zeitzone, Epochen-Einheiten.
• Level — welches Feld plus eine Abbildung roher Tokens auf das kanonische Enum Trace / Debug / Info / Warn / Error / Fatal.
• Fortsetzung — wie Folgezeilen am aktuellen Datensatz kleben (Java-Stacktraces werden ein Eintrag, nicht 30).
• abgeleitete Felder — Zusatzfelder, die ein Untermuster über ein bestehendes Feld berechnet. Die mitgelieferten apache+nginx-Profile nutzen das, um ein einheitliches Feld client_ip bereitzustellen, damit Follow trace der zusammengeführten Ansicht Access- und Error-Ereignisse desselben Clients über beide Quellen korrelieren kann.
• Rotation — welche Dateien ein logisches Log bilden und in welcher Reihenfolge. Siehe Rotation: einen Dateisatz beschreiben.

Sie müssen diese Dateien nicht von Hand schreiben: der Editor dafür — mit Feldgreifer, grok-artigen Aliassen und einem Live-Zeitstempeltester — ist unter Profile bearbeiten beschrieben.

Zeiten werden so genau angezeigt, wie das Log sie angibt

Nicht jedes Log gibt ein vollständiges Datum an. RFC-3164-Syslog nennt Monat, Tag und Uhrzeit, aber kein Jahr; manche eingebetteten und internen Logs nennen nur die Uhrzeit; Build-Ausgaben gar nichts.

Die Spalte Zeit zeigt genau das, was in der Zeile stand — 13:36:55, Oct 10 14:32:52 oder einen vollständigen Zeitstempel mit UTC — und füllt eine Lücke nie mit einer Vermutung. Dasselbe gilt für den TSV-Export und für die Vorschau im Profileditor, damit ein erfundenes Jahr die Anwendung nicht verlassen und später für ein echtes gehalten werden kann.

Sortierung, Zeitleiste und Statistik funktionieren innerhalb einer solchen Datei weiterhin: die fehlenden Teile werden intern verankert, damit die Datensätze untereinander vergleichbar bleiben. Sichtbar werden sie nie.

Profile bearbeiten

Log-Analysator ▸ Profil bearbeiten… listet jedes Profil mit dem Abzeichen Integriert oder Benutzerdefiniert. Ein Profil auszuwählen lädt es.

Integrierte Profile sind schreibgeschützt, genau wie integrierte Themes: das Formular wird angezeigt, ist aber deaktiviert, und Klonen ist der Weg, eines zu ändern. Ein Klon erhält eine freie Kennung, damit eine Kopie das Profil, aus dem sie stammt, niemals stillschweigend verdeckt. Neu beginnt bei null, Löschen entfernt ein eigenes Profil, und der Wechsel weg von ungespeicherter Arbeit fragt vorher nach.

Wird ein Profil importiert, dessen Kennung mit einer integrierten übereinstimmt, so wird es unter einer freien Kennung gespeichert, statt sie zu ersetzen — und der Editor nennt welche.

Rotation: einen Dateisatz beschreiben

Ein rotiertes Log ist ein Strom, der auf mehrere Dateien verteilt wurde. Ein Profil sagt mit zwei Namen, welche Dateien zusammengehören — mehr ist nicht nötig, und weil es nur eine Beschreibung gibt, kann nichts einander widersprechen.

Feld	Bedeutung
liveName	Die Datei, in die gerade geschrieben wird.
rotatedName	Die Form, die die älteren Dateien annehmen.
indexOrder	Welches Ende der Nummerierung das neueste ist.
orderBy	Woher die Reihenfolge kommt. Fast immer name.

Platzhalter

Beide Namen akzeptieren diese. Außerhalb davon ist jedes Zeichen wörtlich — . ist ein Punkt, kein „beliebiges Zeichen", und * ist ein Sternchen, kein Platzhalter.

Platzhalter	Bedeutet
%LIVE%	Die geöffnete Datei. Zu verwenden, wenn das Profil den Namen nicht im Voraus kennen kann.
%N	Die Rotationsnummer. Wird als Zahl gelesen, sodass _10 nach _9 einsortiert wird und nicht zwischen _1 und _2.
%Y %y	Jahr, vier- oder zweistellig. Zweistellige nutzen den üblichen Umbruch: 69–99 heißt 19xx, 00–68 heißt 20xx.
%m %b %B	Monat als Zahl, Abkürzung (Jul) oder ausgeschrieben (July).
%d %j	Tag des Monats oder Tag des Jahres.
%H %M %S	Stunde, Minute, Sekunde — für Schemata, die öfter als einmal täglich rotieren.
%%	Ein wörtliches Prozentzeichen.

Es sind dieselben strftime-Felder, die das Profil in den Zeitstempelformaten verwendet; ein zweiter Satz ist nicht zu lernen.

Eine Kompressionsendung (.gz, .zip, .bz2, .xz) wird automatisch behandelt und darf in keinem der Namen auftauchen: jedes Schema hängt sie zuletzt an, nach allem, was das Muster beschreibt.

Die drei Zustände von liveName

Wert	Wann
%LIVE%	Ein Allzweckprofil, das den Namen nicht kennen kann — der Satz ist an die geöffnete Datei gebunden.
Ein wörtlicher Name, z. B. access.log	Das Profil ist für eine Anwendung geschrieben, deren aktive Datei immer so heißt.
Leer	Es gibt keine unnummerierte aktive Datei: jede Datei ist nummeriert oder datiert. So arbeiten IIS und java.util.logging.

Beispiele

Schema	liveName	rotatedName
logrotate	%LIVE%	%LIVE%.%N
logrotate mit dateext	%LIVE%	%LIVE%-%Y%m%d
Apache / nginx	access.log	access.log.%N
IIS	(leer)	u_ex%y%m%d.log
log4j2 / logback, Standardrollierung	%LIVE%	app-%Y-%m-%d-%N.log
Stündliche Rotation	%LIVE%	app-%Y-%m-%d-%H.log
java.util.logging	(leer)	java%N.log

Wie die Reihenfolge bestimmt wird

Mit orderBy: name — der Vorgabe — entscheidet zuerst das Datum im Namen, die Nummer bricht Gleichstände innerhalb eines Datums, und eine Datei ohne Nummer ist die aktive und damit neueste. indexOrder sagt, in welche Richtung die Nummern laufen: higher-is-older bei logrotate und spdlog, higher-is-newer bei Serilog, Boost.Log und allem, was mit der Zeit aufwärts zählt. Am Namen allein ist das nicht zu erkennen — deshalb muss es das Profil sagen.

Die übrigen orderBy-Werte sind für Sätze, deren Nummern nicht verlässlich sind. Zyklische Rotation verwendet dieselben wenigen Nummern immer wieder, die Nummer ist also ein Platz und kein Alter; first-record-time liest dann den ersten Zeitstempel jeder Datei, und mtime weicht auf das Dateisystem aus.

Wird name gewählt und tragen die Namen weder Datum noch Nummer, fällt die Reihenfolge auf den ersten Datensatz zurück, dann auf mtime, dann auf den bloßen Namen — und die Statusleiste sagt, auf welche, denn mtime wird durch Kopieren, Entpacken, Zurückspielen eines Backups oder einen Branch-Wechsel überschrieben.

Ein Datum im Dateinamen wird nie zum Zeitstempel eines Datensatzes

Aus Dateinamen gelesene Daten dienen einzig dazu, die Segmente in eine Reihenfolge zu bringen. Datensätze nehmen ihren Zeitstempel immer aus der Zeile, aus der sie geparst wurden. Eine Datei namens access.log-20260730 enthält weiterhin Datensätze zu den Zeiten, die ihre eigenen Zeilen angeben.

Abgelehnte Muster

Ein Muster mit zwei %N oder mit einem %N direkt an einem Datumsfeld wird beim Laden des Profils abgelehnt und die Rotation dafür abgeschaltet, mit der Begründung in der Diagnose. app_%N%Y%m%d.log lässt sich bei app_1220260730.log auf mehrere Arten lesen, und eines davon stillschweigend zu wählen würde den Satz falsch ordnen, ohne dass auf dem Bildschirm etwas darauf hinweist. Setzen Sie ein beliebiges wörtliches Zeichen dazwischen — jedes reale Schema tut das ohnehin.

Der Profileditor prüft beide Namen während der Eingabe, sodass ein abgelehntes Muster dort auffällt und nicht erst beim Öffnen.

Nach Anwendungslauf aufteilen

Ein Lauf ist ein Leben der Anwendung von Start bis Ende und nicht dasselbe wie eine Datei: Rotation nach Größe zerschneidet einen Lauf über mehrere Dateien, und ein nur größenrotiertes Log kann mehrere Läufe in einer Datei enthalten.

Gibt das Log beim Start eine Zeile aus — Volluto logging system started…, Begin file log, ein Framework-Banner — tragen Sie einen passenden regulären Ausdruck in das Profilfeld runStartMarker ein. Ein Rechtsklick auf eine Spur in der Zeitleiste bietet dann Nach Anwendungslauf aufteilen, und jeder Lauf wird zu einer eigenen Spur. Der Eintrag erscheint nur, wenn die Datensätze tatsächlich mehr als einen Lauf enthalten.

Ohne Marker lassen sich die Grenzen nur aus zeitlichen Lücken erraten, und dieses Raten ist absichtlich standardmäßig aus. Ein Lauf ist ein Begriff aus Anwendungs-Logs; nginx, apache, syslog und Container-Logs sind durchlaufende Dienste ganz ohne Läufe, und eine ruhige Nacht würde sonst als hunderte Neustarts gelesen. Wo geraten wird, passt sich die Schwelle dem Rhythmus des Logs an und wird ganz verworfen, wenn sie Läufe ergibt, die zu kurz sind, um echt zu sein.

Rückwärts laufende Zeit innerhalb einer Quelle gilt immer als Grenze und wird immer gemeldet — sie bedeutet entweder einen Neustart oder falsch geordnete Segmente, und beides sollte man wissen.

Themes

Die Farben pro Level kommen aus dem Theme — das Plugin registriert eine Palettenkategorie pro kanonischem Level, der Theme-Editor zeigt sie, und jedes Theme kann sie übersteuern. Ein Themewechsel aktualisiert Level-Spalte, Zeitachsen-Streifen, Statistik-Panel und Sequenzdiagramm im Gleichschritt.

Siehe auch

• Vergleich / Diff — das Vergleichsfenster, dem die Fenster des Log-Analysators nachempfunden sind.
• Protokollierung & Diagnose — die eigene Protokolldatei des Editors (getrennt von der Sicht des Log-Analysators auf beliebige Protokollformate).