1. Read Logs

RU | EN | DE

Dieser Artikel wurde ursprünglich auf Russisch verfasst. Er richtet sich an Systemadministratoren und Softwareentwickler. Ich habe versucht, ihn entsprechend für diese Zielgruppe anzupassen.

Wie man Logs liest, wenn es zu viele davon gibt

Die Zeit der Monolithen ist vorbei. Heute verwirren Logs oft mehr, als dass sie helfen. Mehrere Services, mehrere Protokolldateien und widersprüchliche Einträge — keine offensichtliche Ursache in dieser monotonen Untersuchung. Doch die Suche lässt sich eingrenzen, und die Antwort findet sich fast immer in der Kette der Ereignisse.

Open: Logs_admin_pic001.png

Befehle, praktische Tipps und eine Liste nützlicher Tools finden Sie im weiteren Verlauf des Artikels. Vorab ein Hinweis: Der Artikel enthält ziemlich viel Text. Wer direkt zum praktischen Teil springen möchte, kann sofort zu den Abschnitten Linux, Windows oder Tools wechseln — die Tool-Liste befindet sich ganz am Ende.

Was sind Logs?

Ich beginne, wie üblich, mit etwas Theorie für Einsteiger. Ein Log ist eine chronologische Aufzeichnung von Ereignissen, die ein System, eine Anwendung oder ein einzelner Dienst als relevant eingestuft hat.

Anhand von Logs versucht man normalerweise herauszufinden, welcher Benutzer eine Anfrage gesendet hat, welcher Prozess abgestürzt ist, welcher Dienst nicht geantwortet hat, wo ein Fehler aufgetreten ist und was das System unmittelbar vor dem Ausfall noch ausgeführt hat. Open: Logs_admin_pic002.png

Logs gibt es in vielen Varianten: Systemlogs, Serverlogs, Anwendungslogs, Mail-Logs, Authentifizierungs- und Autorisierungsprotokolle, Datenbanklogs, Containerlogs, Proxy-Logs, Logs von Load Balancern und Netzwerkgeräten. Zur besseren Übersicht werden sie meistens nach ihrer Quelle unterteilt.

Wenn ein Benutzer einen 502-Fehler sieht, ist es sinnvoller, zuerst bei nginx oder in der Anwendung zu suchen — und nicht direkt im vollständigen Systemprotokoll des ganzen Tages. Wenn die SSH-Anmeldung nicht funktioniert, helfen als Erstes auth.log, secure oder die Sicherheitsereignisse in Windows. Wenn ein Dienst plötzlich beendet wurde, muss man sowohl das Anwendungslog als auch den Dienstmanager und die Systemereignisse rund um den Absturz betrachten.

Kommen wir nun zu den Wichtigkeitsstufen. Ohne sie erinnert ein Log sehr schnell an eine Textwand aus „Matrix“. Logmeldungen besitzen unterschiedliche Schweregrade:

INFO beschreibt den normalen Betrieb.
DEBUG hilft Entwicklern, Details der Ausführung zu erkennen.
WARN weist auf ein mögliches Problem hin.
ERROR protokolliert einen Fehler.
FATAL und CRITICAL weisen auf einen kritischen Zustand oder einen Fehler hin, der den Betrieb des Systems oder einer Komponente ernsthaft beeinträchtigt.

Zusätzlich gibt es noch TRACE. Auf dieser Ebene schreibt die Anwendung sehr detailliert mit, was intern passiert: Aufrufe, Übergänge zwischen Komponenten, Parameter und interne Zustände. Auf Produktivsystemen sollte man diese Stufe nur mit Vorsicht aktivieren, weil sie den Datenträger sehr schnell zum Verbrauchsmaterial machen kann.

Open: Logs_admin_pic003_de.png

Eine besondere Freude für Entwickler und gleichzeitig ein wiederkehrender Schmerz für Administratoren ist der Stack Trace — also die Aufrufkette, über die eine Anwendung bis zum Fehler gelangt ist. Er zeigt die Stelle, an der sich das Problem bemerkbar gemacht hat. Die eigentliche Ursache kann jedoch in einer anderen Schicht liegen, daher sollte man hier vorsichtig interpretieren.

Womit man bei der Analyse beginnen sollte

Wenn bereits alles brennt, suchen viele zuerst nach error. Manchmal hilft das, aber oft führt es nur tiefer in den Wald. Ich empfehle, zuerst den Suchrahmen festzulegen, zum Beispiel:

wann die Verschlechterung begonnen hat,
wo sie sichtbar wurde,
welche Komponente dem Symptom am nächsten liegt,
welche Logs genau zu dieser Ereigniskette gehören.

Wenn das Monitoring ab 14:32 einen Anstieg von 5xx-Fehlern zeigt, ergibt es keinen Sinn, den gesamten access.log des Tages zu lesen. Nehmen Sie den Zeitraum rund um 14:32, prüfen Sie den eingehenden Traffic, die Anwendungsfehler, den Zustand des Dienstes und die Systemereignisse in zeitlicher Nähe.

Besser ist es, nach folgendem Schema vorzugehen: Symptom, die dem Symptom nächste Komponente, Abhängigkeiten und anschließend die Systemebene. Bei Fehlern auf einer Website kann man zum Beispiel von nginx zur Anwendung gehen, danach zur Datenbank, Queue, DNS, zum Dateisystem und schließlich zum Kernel.

Wie man aus mehreren Quellen eine zusammenhängende Geschichte baut

Wie man Logs liest, wenn es sehr viele davon gibt, zeige ich anhand von Linux und Windows. Außerdem gehe ich kurz auf einige praktische Tricks für Container-Umgebungen ein.

Linux

Beginnen wir mit Linux, weil man dort besonders häufig per SSH arbeitet. Logs liegen meistens unter /var/log/, aber die konkreten Pfade hängen von Distribution und Dienst ab.

In Debian und Ubuntu findet man Systemmeldungen normalerweise unter /var/log/syslog, Authentifizierungsereignisse unter /var/log/auth.log. In RHEL, CentOS, AlmaLinux und Rocky Linux begegnet man häufiger /var/log/messages und /var/log/secure.

nginx-Logs liegen meistens unter /var/log/nginx/, Apache-Logs unter /var/log/apache2/ oder /var/log/httpd/. PostgreSQL und MySQL können sowohl in eigene Verzeichnisse schreiben als auch in journald, wenn der Dienst entsprechend konfiguriert ist.

Wenn auf dem System systemd verwendet wird, würde ich mit journalctl beginnen. Dieses Werkzeug kann bereits nach Dienst, Zeit, PID, Boot-Vorgang und Wichtigkeitsstufe filtern und zwingt Sie nicht dazu, die richtige Zeile manuell aus einem großen allgemeinen Log-Sumpf herauszufischen.

Um zum Beispiel die letzten 200 Zeilen eines bestimmten Dienstes anzuzeigen, ersetzen Sie myapp.service durch den Namen Ihrer Unit:

journalctl -u myapp.service -n 200 --no-pager

Wenn der Dienst nginx heißt, sieht der Befehl so aus:

journalctl -u nginx -n 200 --no-pager

Der Parameter -n 200 zeigt die letzten 200 Einträge. Wenn ein Dienst selten schreibt, reicht -n 50; wenn er sehr gesprächig ist, nehmen Sie eher -n 1000. --no-pager deaktiviert die seitenweise Anzeige, damit die Ausgabe direkt im Terminal erscheint oder weiterverarbeitet werden kann.

Wenn der Zeitraum des Incidents bekannt ist, sollte man die Ausgabe sofort zeitlich begrenzen. Angenommen, die Degradation begann am 14. März 2025 gegen 21:00 Uhr und der Dienst war um 21:30 Uhr wiederhergestellt:

journalctl -u myapp.service --since "2025-03-14 21:00" --until "2025-03-14 21:30" --no-pager

Für die Live-Beobachtung eines Dienstes verwenden wir -f, ähnlich wie bei tail -f:

journalctl -u myapp.service -f

Wenn nur Warnungen und Fehler benötigt werden, fügen wir einen Prioritätsfilter hinzu:

journalctl -u myapp.service -p warning..alert --since "1 hour ago" --no-pager

Hier filtert warning..alert normale Informationsmeldungen heraus. Das ist praktisch, wenn ein Dienst sehr viele INFO-Einträge schreibt. Aber denken Sie daran: Manchmal versteckt sich die Ursache genau in einer scheinbar normalen Zeile direkt vor dem Fehler.

Wenn ein Dienst nach einem Neustart abgestürzt ist oder das Problem aus dem vorherigen Boot-Vorgang stammen könnte, ist ein Vergleich der aktuellen und der vorherigen Systemstarts hilfreich:

journalctl -b -u myapp.service --no-pager
 
journalctl -b -1 -u myapp.service --no-pager

Dabei zeigt -b den aktuellen Boot-Vorgang, -b -1 den vorherigen. Das hilft besonders dann, wenn das Symptom nach einem Neustart verschwunden ist, die Ursache aber noch im vorherigen Journal liegt.

Kernel-Meldungen betrachten wir separat. Das ist wichtig bei Verdacht auf OOM Killer, Datenträgerprobleme, Dateisystemfehler, Netzwerkinterfaces oder Treiber:

journalctl -k --since "1 hour ago" --no-pager

Eine schnelle Filterung nach typischen Begriffen sieht in solchen Fällen so aus:

journalctl -k --since "1 hour ago" | grep -Ei 'oom|killed process|segfault|ext4|xfs|nvme|i/o error|link is down|reset'

Wenn Sie Killed process sehen, steht in der Nähe meistens auch der Prozess, den der OOM Killer beendet hat. Wenn I/O error, nvme reset oder Dateisystemfehler auftauchen, liegt das Problem möglicherweise bereits unterhalb der Anwendungsebene.

Wenn journald nicht weiterhilft und Sie vor einer normalen Logdatei stehen, beginnt die alte Schule. Bei klassischen Logdateien hilft die Suche mit Kontext. Man sucht also nicht nur eine Zeile, sondern sieht sofort, was davor und danach passiert ist:

grep -n -A20 -B10 'timeout' /var/log/myapp/app.log

Ersetzen Sie timeout durch eine IP-Adresse, einen Login-Namen, eine Request ID, einen Fehlercode oder einen Ausschnitt der Meldung. -A20 zeigt 20 Zeilen nach dem Treffer, -B10 10 Zeilen davor, -n ergänzt Zeilennummern. Wenn das Ereignis kurz ist, reichen -A5 -B5; wenn Sie eine längere Kette sehen müssen, nehmen Sie zum Beispiel -A50 -B20.

Für eine Suche ohne Beachtung der Groß- und Kleinschreibung fügen Sie -i hinzu:

grep -ni -A10 -B10 'exception' /var/log/myapp/app.log

Wenn Sie nicht nur eine Datei, sondern ein ganzes Logverzeichnis durchsuchen müssen:

grep -Rni --include='*.log' 'timeout' /var/log/myapp/

--include='*.log' verhindert, dass grep in temporäre Dateien oder in alles Mögliche hineinsucht, was zufällig danebenliegt.

Wenn Logs nach der Rotation bereits komprimiert wurden, verwenden wir zgrep:

zgrep -ni 'timeout' /var/log/myapp/app.log*.gz

Wenn das Zeitformat im Log klar ist, lesen Sie nicht den ganzen Tag. Angenommen, die Einträge beginnen mit 2025-03-14 21:05:..., und Sie benötigen die gesamte Stunde 21:

grep '^2025-03-14 21:' /var/log/myapp/app.log

Wenn ein Minutenbereich gebraucht wird, zum Beispiel von 21:10 bis 21:19:

grep '^2025-03-14 21:1[0-9]:' /var/log/myapp/app.log

Für die aktuelle Datei verwenden wir tail. Wenn Sie die letzten 500 Zeilen sehen und neue Einträge weiter beobachten möchten, können Sie die Zahl an die Lautstärke des Dienstes anpassen:

tail -n 500 -f /var/log/myapp/app.log

Wenn die Datei rotiert wird, ist -F besser, weil es nach dem Umbenennen der alten Datei automatisch der neuen Datei folgt:

tail -n 500 -F /var/log/nginx/error.log

Access-Logs sind besonders tückisch. Sie sehen aus wie eine endlose Warteschlange identischer Zeilen, sind aber in aggregierter Form sehr nützlich. Man sollte sie möglichst schnell in Zähler verwandeln. Zum Beispiel, um die häufigsten IP-Adressen in nginx zu sehen:

awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -20

head -20 zeigt die ersten 20 Ergebnisse. Wenn Sie eine breitere Liste benötigen, ändern Sie den Wert zum Beispiel auf head -50.

Wenn Sie ein ungewöhnliches Access-Log-Format verwenden, schauen Sie sich zuerst ein paar Zeilen an:

head -3 /var/log/nginx/access.log

Wenn im log_format von nginx als letztes Feld $request_time geschrieben wird, können Sie die langsamsten Requests so anzeigen:

awk '{print $NF, $7, $9}' /var/log/nginx/access.log | sort -nr | head -20

Wenn die Request-Zeit bei Ihnen an einer anderen Stelle steht, prüfen Sie zuerst das Logformat:

grep -R "log_format" /etc/nginx/nginx.conf /etc/nginx/conf.d/

Bei Auth-Logs gilt dieselbe Logik. Lesen Sie nicht alles der Reihe nach, sondern bilden Sie sofort gezielte Auszüge. In Debian und Ubuntu können fehlgeschlagene SSH-Logins zum Beispiel so angezeigt werden:

grep 'Failed password' /var/log/auth.log | tail -50

In RHEL-ähnlichen Systemen entsprechend so:

grep 'Failed password' /var/log/secure | tail -50

Einer der nützlichsten Linux-Tricks ist: Suchen Sie immer nach request ID, trace ID oder correlation ID, sofern solche IDs vorhanden sind. Mit ihnen lässt sich der Weg einer einzelnen Anfrage über nginx, Anwendung, Queue und Worker viel einfacher rekonstruieren:

grep -Rni 'request_id=abc123' /var/log/myapp/

Wenn der Identifikator wie eine UUID aussieht, kann man zuerst prüfen, welche IDs besonders häufig vorkommen:

grep -oE '[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}' /var/log/myapp/app.log | sort | uniq -c | sort -nr | head -20

Danach nimmt man die verdächtige ID und betrachtet sie mit Kontext:

grep -n -A30 -B10 'abc123' /var/log/myapp/app.log

Wenn es in den Logs keinen durchgängigen Identifikator gibt, ist das bereits ein eigener Befund nach der Untersuchung. Er sollte ergänzt werden, sonst wird eine verteilte Umgebung bei jedem Incident erneut zur Archäologie.

Windows

Wenn unter Linux „alles eine Datei“ ist — und meistens eine Textdatei —, dann hat sich die Logging-Architektur bei Microsoft historisch in Richtung strikter Strukturierung und binärer Formate entwickelt. Der Übergang zu Event Tracing for Windows, kurz ETW, und XML-Schemata hat einfaches Log-Parsen mit grep oder Notepad praktisch unmöglich gemacht und zwingt dazu, PowerShell und die Architektur der Windows-Ereignisprotokolle genauer zu verstehen.

Für eine ernsthafte forensische Analyse muss man hier genau wissen, wo das Betriebssystem seine Artefakte physisch speichert:

Klassische Systemprotokolle wie System, Application, Security sowie Hunderte spezialisierte Dienstprotokolle liegen im Verzeichnis C:\Windows\System32\winevt\Logs\ im Format .evtx.
IIS-Webserver-Logs werden unter %SystemDrive%\inetpub\logs\LogFiles\ oder C:\Windows\System32\LogFiles\ gespeichert. Die Unterverzeichnisse heißen nach dem Schema W3SVC1, W3SVC2 usw.; die Zahl entspricht der internen ID der Website in der IIS-Konsole.
Windows Update schreibt seit Windows 10 nicht mehr einfach in die Textdatei C:\Windows\WindowsUpdate.log. Die Telemetrie wird nun fortlaufend in binäre .etl-Dateien geschrieben, die unter C:\Windows\logs\WindowsUpdate liegen.

Die wichtigste Regel ist dieselbe wie unter Linux: Erst die Auswahl begrenzen, dann lesen.

Die wichtigsten Protokolle sind: System für Systemereignisse und Dienste, Application für Anwendungen, Security für Anmelde- und Sicherheitsereignisse sowie separate Protokolle für Anwendungen und Windows-Serverrollen. Wenn ein Dienst abstürzt, beginnen Sie mit System und dem Service Control Manager. Wenn eine Anwendung abstürzt, prüfen Sie Application. Wenn es um Logins, Rechte oder verdächtige Aktivitäten geht, brauchen Sie Security; dafür sind häufig Administratorrechte erforderlich.

Wichtig ist außerdem: Über viele Jahre war Get-EventLog das zentrale PowerShell-Cmdlet zum Auslesen von Ereignissen. Seine Architektur ist jedoch veraltet. Heute funktioniert es nur mit klassischen Legacy-Protokollen, verwendet veraltete Windows-APIs und ist vor allem bei der Filterung von Daten ineffizient.

Microsoft empfiehlt dafür Get-WinEvent. Die Filterung erfolgt hier auf der Seite des Eventlog-Dienstes selbst. Für maximale Geschwindigkeit bietet Get-WinEvent zwei Filtermechanismen: FilterHashtable und FilterXML.

Weiter zu den Befehlen. Systemereignisse der letzten 30 Minuten sehen Sie so:

Get-WinEvent -FilterHashtable @{LogName='System'; StartTime=(Get-Date).AddMinutes(-30)}

Wenn Sie statt 30 Minuten die letzten zwei Stunden benötigen, ersetzen Sie AddMinutes(-30) durch AddHours(-2):

Get-WinEvent -FilterHashtable @{LogName='System'; StartTime=(Get-Date).AddHours(-2)}

Fehler aus dem Anwendungsprotokoll der letzten zwei Stunden:

Get-WinEvent -FilterHashtable @{LogName='Application'; Level=2; StartTime=(Get-Date).AddHours(-2)}

Level=2 bedeutet Fehler, Level=3 Warnungen und Level=4 Informationsereignisse.

Wenn Sie Fehler und Warnungen zusammen benötigen, können Sie eine kurze Auswahl so filtern:

Get-WinEvent -FilterHashtable @{LogName='Application'; StartTime=(Get-Date).AddHours(-2)} |
  Where-Object {$_.LevelDisplayName -in 'Error','Warning'}

Ein konkretes Ereignis, zum Beispiel ein Anwendungsabsturz mit Event ID 1000, wird so angezeigt:

Get-WinEvent -FilterHashtable @{LogName='Application'; ID=1000; StartTime=(Get-Date).AddHours(-2)}

Ereignisse des Service Control Managers, die helfen zu verstehen, wann ein Dienst gestartet wurde, abgestürzt ist oder beendet wurde, sehen Sie so:

Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Service Control Manager'; StartTime=(Get-Date).AddHours(-2)}

Damit die Ausgabe lesbar bleibt, lassen wir nur Zeit, ID, Quelle, Ebene und Meldung anzeigen:

Get-WinEvent -FilterHashtable @{LogName='System'; StartTime=(Get-Date).AddMinutes(-30)} |
  Select-Object TimeCreated, Id, ProviderName, LevelDisplayName, Message |
  Format-List

Für das Sicherheitsprotokoll kann man sich die fehlgeschlagenen Anmeldungen der letzten Stunde ansehen. Event ID 4625 steht zum Beispiel für einen fehlgeschlagenen Logon:

Get-WinEvent -FilterHashtable @{LogName='Security'; ID=4625; StartTime=(Get-Date).AddHours(-1)} |
  Select-Object TimeCreated, Id, ProviderName, Message |
  Format-List

Für Textlogs funktioniert PowerShell fast wie tail:

Get-Content .\app.log -Tail 200 -Wait

-Tail 200 zeigt die letzten 200 Zeilen. Wenn ein kurzer Ausschnitt reicht, nehmen Sie 50. Wenn das Log sehr laut ist und Sie den Moment vor dem Fehler erfassen müssen, nehmen Sie 1000. -Wait wartet weiter auf neue Zeilen.

Außerdem können Sie in einem Textlog suchen:

Select-String -Path .\app.log -Pattern 'timeout|exception|failed'

Oder in einem ganzen Verzeichnis:

Get-ChildItem C:\Logs -Recurse -Filter *.log |
  Select-String -Pattern 'timeout|exception|failed'

Der wichtigste Windows-Trick: Öffnen Sie keine riesigen Logs im Editor und exportieren Sie nicht das gesamte EventLog ohne Filter. Für EventLogs sollten Sie FilterHashtable verwenden, weil die Filterung damit deutlich effizienter ist.

Wichtig! Es ist praktisch UNMÖGLICH, alle relevanten Befehle in einem Artikel abzudecken. Wenn Sie also Anfänger sind und gerade lernen — oder wenn Ihr System genau jetzt ausgefallen ist und Sie hektisch in diesem Artikel nach einer Rettung suchen — dann entschuldige ich mich und empfehle, zusätzlich in Tutorials, Büchern, Suchmaschinen oder mit einem Chatbot weiterzusuchen. Ich habe diesen Beitrag vor allem geschrieben, um an die Grundlagen der Arbeit mit einer großen Menge an Logs zu erinnern.

Was bei der Analyse wirklich Zeit spart

Zeit sparen vor allem Gewohnheiten.

Begrenzen Sie die Auswahl, bevor Sie lesen. Unter Linux sind das journalctl --since, --until, -u, -p, _PID. Unter Windows ist es Get-WinEvent -FilterHashtable. Je genauer der erste Schnitt ist, desto weniger Müll müssen Sie im Kopf behalten.
Zählen Sie Wiederholungen. Ein einzelner error kann Hintergrundrauschen sein. Tausend identische timeout-Meldungen innerhalb von fünf Minuten sehen dagegen bereits sehr nach einem Symptom aus. Deshalb ist sort | uniq -c | sort -nr oft nützlicher, als eine Datei von oben nach unten zu lesen.
Betrachten Sie den Kontext. Befehle ohne -A, -B oder -C liefern häufig zu wenig, denn in Logs ist nicht nur die Zeile mit dem Fehler wichtig, sondern auch das, was davor passiert ist. Zum Beispiel ein neues Deployment, eine erneute Verbindung zur Datenbank, ein Connection Reset, eine Konfigurationsänderung oder ein Worker-Neustart.

Open: Logs_admin_pic004_de.png

Prüfen Sie die Rotation und ältere Log-Instanzen. Unter Linux kann der Fehler bereits in einer .gz-Datei gelandet sein, unter Windows dagegen in einem anderen Ereignisprotokoll.
Dokumentieren Sie den Verlauf der Untersuchung. Wenn es viele Logs gibt, beginnt das Gedächtnis schnell damit, eine bequeme Version der Ereignisse zu ergänzen. Notieren Sie den Zeitpunkt des ersten Symptoms, die bereits ausgeführten Befehle, verdächtige Meldungen und Hypothesen, die sich nicht bestätigt haben. Eine Stunde später erspart Ihnen das, dieselben Dinge erneut zu prüfen.

Und die etwas pedantische, aber wichtige sechste Gewohnheit: Ergänzen Sie Anwendungen um saubere Logging-Felder. Ein Timestamp in einem einheitlichen Format, Log-Level, Service, Instance, Request ID, User ID ohne personenbezogene Daten, Endpoint, Duration, Response Status und Trace ID sparen mehr Zeit als jeder schöne Log-Viewer.

Top-Tools zum Lesen und Analysieren von Logs

Für die Analyse komplexer und umfangreicher Logdaten sollten Sie jedoch fertige und gut verfügbare Werkzeuge verwenden. Zum Beispiel kostenlose lokale Tools:

lnav — ein konsolenbasierter Log-Viewer. Er kann mehrere Logs gleichzeitig öffnen, Archive lesen, Formate erkennen, eine zeitliche Ereigniskette aufbauen und SQL-Abfragen über Logs ausführen.
ripgrep — eine schnelle rekursive Suche über Dateien. Funktioniert unter Linux, macOS und Windows und ist besonders praktisch für große Log- und Quellcodeverzeichnisse.
jq — ein Werkzeug für die Arbeit mit JSON. Besonders nützlich für Container und moderne Anwendungen, die strukturierte JSON-Logs schreiben.
Klogg — ein grafischer Viewer für große Logdateien. Geeignet für gigabytegroße Dateien, die sich mit einem normalen Editor kaum sinnvoll öffnen lassen.
LogExpert — ein Windows-Tool zum Anzeigen von Logs. Es unterstützt Tail-Funktion, Filter, Hervorhebung, Tabs und Plugins. Praktisch für Anwendungslogs in einer grafischen Oberfläche.
Log Parser 2.2 — ein weiteres Windows-Tool mit SQL-ähnlichen Abfragen. Nützlich für IIS, Event Log, CSV, XML und Textlogs, besonders in älteren Windows-Infrastrukturen.

Beim zentralisierten Sammeln von Logs helfen bereits umfangreichere Werkzeuge:

Grafana Loki — ein System zur Speicherung und Suche von Logs. Die Self-hosted-Version ist kostenlos, in Grafana Cloud gibt es einen kostenlosen Tarif sowie kostenpflichtige Tarife nach Datenvolumen. Loki eignet sich gut für Kubernetes und Microservices, weil es stark mit Labels arbeitet und nicht den gesamten Text wie klassische Volltextsysteme indexiert.
SigNoz — eine Observability-Plattform für Logs, Metriken und Traces. Die Self-hosted-Version ist kostenlos, Cloud-Tarife sind kostenpflichtig. Praktisch dort, wo OpenTelemetry eingesetzt wird und Logs mit Request-Traces verknüpft werden sollen.
Elastic Stack / ELK — ein Stack zum Sammeln, Speichern und Durchsuchen von Logs auf Basis von Elasticsearch, Logstash oder Beats und Kibana. Im Self-managed-Betrieb gibt es kostenlose Funktionen. Besonders stark ist der Stack bei Volltextsuche, Analyse und großen unstrukturierten Datenmengen.
Graylog — eine Plattform für zentralisiertes Log-Management. Geeignet für Infrastruktur-Logs, Netzwerkgeräte, Anwendungen, Alerts und Ereignisströme.
Splunk — eine kommerzielle Plattform für die zentrale Sammlung und Suche von Ereignissen. Der Preis hängt vom Datenvolumen und der gewählten Edition ab. Splunk ist stark bei Suchsprache, Security, Audit und der Untersuchung komplexer Incidents.

Fazit

Ich wiederhole es noch einmal: Wenn es nur wenige Logs gibt, muss man meist einfach die richtige Zeile finden — und der Fall ist fast erledigt. Wenn es sehr viele Logs werden, muss man nach Mustern suchen. Eine saubere Analyse beginnt deshalb nicht mit error, sondern mit Zeit, Quelle, Kontext und einer kurzen zeitlichen Ereigniskette. Konsolenbefehle bleiben dabei unverzichtbar. Wenn das System jedoch verteilt ist, sollten Logs zentral gesammelt werden.

VBO Wiki

Explorer