2.12 Protokolle und Logs systematisch auswerten Protokolldateien gehören zu den wichtigsten Informationsquellen bei der Fehleranalyse. Sie dokumentieren Ereignisse, Zustandsänderungen, Warnungen und Fehler, die während des Betriebs eines Systems oder einer Anwendung auftreten. Logs können unter anderem folgende Fragen beantworten: Wann begann die Störung? Welches System oder welcher Dienst meldete den Fehler zuerst? Welcher Benutzer, Prozess oder Dienst war beteiligt? Trat unmittelbar vorher eine Konfigurationsänderung auf? Ist das Problem einmalig oder wiederkehrend? Sind mehrere Systeme zur gleichen Zeit betroffen? Welche Fehlernummer, Ereignis-ID oder Statusmeldung wurde protokolliert? War ein Fehler die Ursache oder nur eine Folge eines anderen Problems? Grundregel: Nicht mit dem auffälligsten Fehler beginnen, sondern mit dem ersten relevanten Ereignis in der zeitlichen Kette. 1. Kennzeichnungen und Sicherheitsregeln Kennzeichnung Bedeutung [RO] Liest Informationen aus, ohne sie absichtlich zu verändern [TEST] Führt einen aktiven Test aus oder erzeugt zusätzliche Logeinträge [PRIV] Benötigt möglicherweise Administrator- oder Root-Rechte [FILE] Erzeugt oder verändert eine Datei [SENS] Ausgabe kann vertrauliche Daten enthalten [CHANGE] Verändert Konfiguration, Protokollierung oder Systemzustand [DISRUPT] Kann Dienste oder Systeme beeinträchtigen Logs können unter anderem folgende vertrauliche Informationen enthalten: Benutzernamen und E-Mail-Adressen, interne Hostnamen und IP-Adressen, vollständige Datei- und Verzeichnispfade, aufgerufene URLs und Suchbegriffe, Sitzungs- und Korrelations-IDs, Kommandozeilen und Programmparameter, Datenbank- und Servernamen, Inhalte von Anfragen und Antworten, Zugangstoken oder andere Geheimnisse, personenbezogene oder geschäftliche Daten. Deshalb gilt: Protokolle nur so umfangreich wie erforderlich erfassen. Exportierte Logs geschützt speichern. Zugriff auf autorisierte Personen begrenzen. Vor externer Weitergabe sensible Inhalte redigieren. Originaldateien möglichst unverändert sichern. Arbeitskopien getrennt vom Original anlegen. Aufbewahrungs- und Löschfristen beachten. Protokolle niemals unkontrolliert in öffentliche Analysedienste hochladen. 2. Wie wird eine Log-Analyse systematisch begonnen? Vor dem Öffnen der ersten Protokolldatei sollten mindestens folgende Informationen bekannt sein: Information Beispiel Betroffenes System CLIENT-023 Betroffener Dienst DNS-Client Fehlerbeginn 2026-07-31 09:42:15 CEST Letzter bekannter funktionierender Zeitpunkt 2026-07-31 09:35 CEST Betroffener Benutzer Max Mustermann Fehlerbeschreibung Interne Anwendung nicht erreichbar Reproduzierbarkeit Bei jedem Anmeldeversuch Kürzliche Änderung VPN-Client aktualisiert Zeitzone des meldenden Systems Europe/Berlin Vergleichssystem CLIENT-024 funktioniert Empfohlener Analysezeitraum Der Zeitraum sollte zunächst eng um das Ereignis gelegt werden: Fehlerzeitpunkt: 09:42 Uhr Erste Untersuchung: 09:37 bis 09:47 Uhr Falls dort keine Ursache erkennbar ist, wird das Zeitfenster schrittweise erweitert. Bewährte Reihenfolge Uhrzeit und Zeitzone aller beteiligten Systeme prüfen. Fehler reproduzieren und exakten Zeitpunkt notieren. Passendes Protokoll bestimmen. Zeitfenster begrenzen. Nach Quelle, Dienst, Prozess oder Ereignis-ID filtern. Das erste relevante Ereignis suchen. Vorhergehende und nachfolgende Ereignisse betrachten. Meldungen zwischen beteiligten Systemen zeitlich korrelieren. Hypothese aufstellen. Hypothese durch einen kontrollierten Test überprüfen. 3. Welche Informationen eines Logeintrags sind wichtig? Feld Bedeutung Prüffrage Zeitstempel Zeitpunkt des Ereignisses Welche Zeitzone wird verwendet? Hostname meldendes System Ist es wirklich das betroffene System? Quelle oder Provider erzeugende Komponente Welcher Dienst oder Treiber meldet das Ereignis? Prozess und PID beteiligter Prozess Läuft derselbe Prozess noch? Benutzer oder UID Sicherheitskontext Unter welchem Konto trat der Fehler auf? Schweregrad Einordnung durch die Anwendung Ist Error wirklich die Ursache? Ereignis-ID typisierter Ereigniscode Ist die ID providerspezifisch? Nachricht menschenlesbare Beschreibung Enthält sie Ursache, Folge oder nur Status? Fehlercode technischer Rückgabewert Ist der Code dezimal oder hexadezimal? Korrelations-ID verbindet zusammengehörige Vorgänge Taucht dieselbe ID in anderen Logs auf? Dienst oder Unit betroffene Komponente Welche Abhängigkeiten besitzt sie? Datei und Zeile Position im Programmcode Passt sie zur eingesetzten Version? Dauer Laufzeit einer Operation Wo entsteht die Verzögerung? Remote-Endpunkt beteiligtes Zielsystem Waren DNS, Routing und Port erreichbar? Eine Ereignis-ID ist normalerweise nur zusammen mit der Quelle eindeutig. Ereignis-ID 1000 von Quelle A ≠ Ereignis-ID 1000 von Quelle B 4. Wie werden Schweregrade richtig interpretiert? Allgemeiner Schweregrad Typische Bedeutung Trace sehr detaillierter interner Ablauf Debug Diagnoseinformationen für Entwicklung und Administration Information reguläres Ereignis oder Statusmeldung Notice bemerkenswertes, aber nicht zwingend fehlerhaftes Ereignis Warning unerwarteter Zustand; Verarbeitung kann weiterlaufen Error Operation ist fehlgeschlagen Critical schwerwiegender Fehler mit deutlicher Beeinträchtigung Alert unmittelbares Eingreifen erforderlich Emergency System oder Dienst ist nicht mehr verwendbar Die genaue Bedeutung hängt von der jeweiligen Anwendung ab. Nicht jedes Programm verwendet dieselbe Einteilung. Wichtige Regeln Eine Warnung ist nicht automatisch die Ursache. Eine Fehlermeldung kann nur die Folge eines früheren Fehlers sein. Eine Informationsmeldung kann den entscheidenden Hinweis enthalten. Debug-Protokollierung kann relevante Informationen liefern, erzeugt aber viel Datenvolumen. Wiederholte Meldungen können auf automatische Wiederholungsversuche hinweisen. Eine erfolgreiche Wiederholung kann einen vorherigen Fehler bereits kompensiert haben. Beispiel einer Ereigniskette 09:42:10 INFO DNS-Abfrage gestartet 09:42:15 WARNING Zeitüberschreitung bei DNS-Server 192.168.10.10 09:42:15 INFO Zweiter DNS-Server wird verwendet 09:42:16 INFO Name erfolgreich aufgelöst 09:42:16 ERROR HTTPS-Verbindung abgelehnt Hier ist die DNS-Warnung möglicherweise nicht die unmittelbare Ursache, weil die Namensauflösung anschließend erfolgreich war. Die abgelehnte HTTPS-Verbindung muss getrennt untersucht werden. 5. Wie werden Datum, Uhrzeit und Zeitzone geprüft? Aufgabe Windows Linux macOS Lokale Zeit [RO] Get-Date -Format o [RO] date --iso-8601=seconds [RO] date "+%Y-%m-%dT%H:%M:%S%z" UTC-Zeit [RO] (Get-Date).ToUniversalTime().ToString("o") [RO] date -u "+%Y-%m-%dT%H:%M:%SZ" [RO] date -u "+%Y-%m-%dT%H:%M:%SZ" Zeitzone [RO] Get-TimeZone [RO] timedatectl status [RO][PRIV] sudo systemsetup -gettimezone Zeitquelle [RO] w32tm /query /source [RO] timedatectl timesync-status [TEST] sntp -d time.apple.com Synchronisationsstatus [RO] w32tm /query /status [RO] timedatectl status [TEST] sntp -d time.apple.com chrony-Status Nicht zutreffend [RO] chronyc tracking Nicht standardmäßig vorhanden chrony-Quellen Nicht zutreffend [RO] chronyc sources -v Nicht standardmäßig vorhanden Warum ist das wichtig? Bereits wenige Minuten Zeitabweichung können die Zuordnung zwischen folgenden Systemen erschweren: Client und Server, Firewall und Anwendung, Webserver und Datenbank, Hypervisor und virtuelle Maschine, Reverse Proxy und Backend, Identitätsanbieter und Cloudanwendung. Ein Zeitstempel ohne Zeitzone ist nicht eindeutig. 2026-07-31 14:30:00 Ein Zeitstempel mit Offset ist eindeutig zuordenbar: 2026-07-31T14:30:00+02:00 UTC-Darstellung: 2026-07-31T12:30:00Z 6. Wie werden Windows-Ereignisprotokolle grafisch untersucht? Die Windows-Ereignisanzeige wird mit folgendem Befehl geöffnet: [RO] eventvwr.msc Wichtige Protokollbereiche: Protokoll Typische Inhalte Anwendung Anwendungs-, Datenbank- und Laufzeitfehler Sicherheit Anmeldungen, Kontoereignisse und überwachte Zugriffe Setup Installation und Systemkonfiguration System Treiber, Dienste, Netzwerk und Betriebssystem Weitergeleitete Ereignisse zentral gesammelte Ereignisse anderer Systeme Anwendungs- und Dienstprotokolle komponentenspezifische Windows-Protokolle Empfohlenes Vorgehen Passendes Protokoll auswählen. Aktuelles Protokoll filtern verwenden. Zeitraum auf den Störungszeitraum begrenzen. Ereignisebene auswählen. Falls bekannt, Quelle und Ereignis-ID eingeben. Ereignis in der Detailansicht öffnen. Allgemeine und XML-Ansicht vergleichen. Ereignisse unmittelbar davor und danach untersuchen. Relevante Ereignisse exportieren oder dokumentieren. Wichtige Felder Protokollname, Quelle beziehungsweise Provider, Ereignis-ID, Ebene, Benutzer, Opcode und Aufgabe, Computername, Zeitstempel, Prozess- und Thread-ID, Ereignisdaten. Die XML-Ansicht kann Informationen enthalten, die in der allgemeinen Beschreibung nicht vollständig dargestellt werden. 7. Wie werden Windows-Ereignisse mit PowerShell gelesen? Verfügbare Ereignisprotokolle auflisten [RO] Get-WinEvent -ListLog * | Select-Object LogName, RecordCount, IsEnabled, LogMode, MaximumSizeInBytes Nur aktivierte Protokolle anzeigen: [RO] Get-WinEvent -ListLog * | Where-Object IsEnabled | Sort-Object LogName | Select-Object LogName, RecordCount Neueste Ereignisse des Systemprotokolls [RO] Get-WinEvent -LogName System -MaxEvents 20 Neueste Ereignisse des Anwendungsprotokolls [RO] Get-WinEvent -LogName Application -MaxEvents 20 Ereignisse der letzten Stunde [RO] $Start = (Get-Date).AddHours(-1) Get-WinEvent -FilterHashtable @{ LogName = 'System' StartTime = $Start } Fehler und kritische Ereignisse der letzten 24 Stunden [RO] $Start = (Get-Date).AddHours(-24) Get-WinEvent -FilterHashtable @{ LogName = 'System' Level = 1, 2 StartTime = $Start } | Select-Object TimeCreated, Id, LevelDisplayName, ProviderName, Message Level Windows-Ebene 1 Kritisch 2 Fehler 3 Warnung 4 Information 5 Ausführlich Nach Ereignis-ID filtern [RO] Get-WinEvent -FilterHashtable @{ LogName = 'System' Id = 7036 } -MaxEvents 20 Nach Provider filtern [RO] Get-WinEvent -FilterHashtable @{ LogName = 'System' ProviderName = 'Service Control Manager' StartTime = (Get-Date).AddHours(-4) } Mehrere Ereignis-IDs abfragen [RO] Get-WinEvent -FilterHashtable @{ LogName = 'System' Id = 6005, 6006, 6008, 1074 StartTime = (Get-Date).AddDays(-7) } | Select-Object TimeCreated, Id, ProviderName, Message Ergebnis übersichtlich ausgeben [RO] Get-WinEvent -FilterHashtable @{ LogName = 'System' Level = 1, 2, 3 StartTime = (Get-Date).AddHours(-2) } | Select-Object TimeCreated, Id, LevelDisplayName, ProviderName, MachineName, Message | Format-List Nach Text in der Meldung suchen [RO] Get-WinEvent -LogName Application -MaxEvents 1000 | Where-Object Message -Match 'timeout|Zeitüberschreitung' Die Filterung mit FilterHashtable erfolgt bereits beim Abruf und ist bei großen Protokollen effizienter als eine nachträgliche Filterung mit Where-Object . Eine Textsuche in der formatierten Nachricht erfordert jedoch häufig eine nachträgliche Auswertung. 8. Wie werden Windows-Ereignisse exportiert und archiviert? Systemprotokoll als EVTX exportieren [RO][PRIV][FILE][SENS] wevtutil epl System C:\Temp\System.evtx Anwendungsprotokoll exportieren [RO][PRIV][FILE][SENS] wevtutil epl Application C:\Temp\Application.evtx Ereignisse mit PowerShell als CSV exportieren [RO][FILE][SENS] $Start = (Get-Date).AddHours(-2) Get-WinEvent -FilterHashtable @{ LogName = 'System' StartTime = $Start } | Select-Object TimeCreated, Id, LevelDisplayName, ProviderName, MachineName, Message | Export-Csv -Path 'C:\Temp\System-Events.csv' -NoTypeInformation -Encoding UTF8 Ereignisse als XML sichern [RO][FILE][SENS] Get-WinEvent -LogName System -MaxEvents 100 | Export-Clixml -Path 'C:\Temp\System-Events.xml' Verfügbare Protokolle mit wevtutil auflisten [RO] wevtutil el Letzte zehn Systemereignisse im Textformat anzeigen [RO] wevtutil qe System /c:10 /rd:true /f:text Option Bedeutung qe Ereignisse abfragen epl Protokoll exportieren /c:10 maximal zehn Ereignisse /rd:true neueste Ereignisse zuerst /f:text Textausgabe /f:xml XML-Ausgabe Protokoll nicht während der Analyse löschen Der folgende Befehl löscht ein Ereignisprotokoll und darf nicht als regulärer Diagnoseschritt verwendet werden: [PRIV][CHANGE][DISRUPT] wevtutil cl System Das Löschen vernichtet möglicherweise entscheidende Beweise und kann gegen betriebliche oder rechtliche Vorgaben verstoßen. 9. Wie werden Linux-Protokolle mit journalctl untersucht? Bei systemd-basierten Linux-Systemen werden viele Ereignisse im systemd-Journal gespeichert und mit journalctl ausgewertet. Gesamtes Journal anzeigen [RO] journalctl Neueste Einträge zuerst anzeigen [RO] journalctl -r Aktuellen Systemstart untersuchen [RO] journalctl -b Vorherigen Systemstart untersuchen [RO] journalctl -b -1 Verfügbare Systemstarts anzeigen [RO] journalctl --list-boots Nur Kernelmeldungen anzeigen [RO] journalctl -k Kernelmeldungen des aktuellen Starts [RO] journalctl -k -b Protokoll eines Dienstes anzeigen [RO] journalctl -u ssh.service [RO] journalctl -u nginx.service Protokoll eines Dienstes live verfolgen [RO] journalctl -u nginx.service -f Beenden mit: Strg+C Ereignisse seit einem Zeitpunkt [RO] journalctl --since "2026-07-31 09:30:00" Zeitfenster eingrenzen [RO] journalctl \ --since "2026-07-31 09:30:00" \ --until "2026-07-31 10:00:00" Relative Zeitangaben [RO] journalctl --since "30 minutes ago" [RO] journalctl --since today Nach Priorität filtern [RO] journalctl -p err Fehler und schwerwiegendere Meldungen des aktuellen Starts: [RO] journalctl -b -p err Warnungen und schwerwiegendere Meldungen eines Dienstes: [RO] journalctl -u nginx.service -p warning Priorität Nummer emerg 0 alert 1 crit 2 err 3 warning 4 notice 5 info 6 debug 7 Mit -p warning werden normalerweise warning und alle schwerwiegenderen Prioritäten angezeigt. Nach Prozess-ID filtern [RO] journalctl _PID=4321 Nach ausführbarer Datei filtern [RO] journalctl _EXE=/usr/sbin/sshd Nach Benutzer-ID filtern [RO] journalctl _UID=1000 Ausgabe ohne Pager [RO] journalctl -u nginx.service --no-pager ISO-Zeitstempel verwenden [RO] journalctl -u nginx.service -o short-iso Ausführliche Felder eines Ereignisses anzeigen [RO] journalctl -u nginx.service -n 10 -o verbose 10. Wie wird der Status eines Linux-Dienstes einschließlich Logs geprüft? Dienststatus anzeigen [RO] systemctl status nginx.service Ohne interaktiven Pager: [RO] systemctl status nginx.service --no-pager Vollständige Zeilen ohne Kürzung: [RO] systemctl status nginx.service --no-pager --full Prüfen, ob der Dienst aktiv ist [RO] systemctl is-active nginx.service Prüfen, ob der Dienst aktiviert ist [RO] systemctl is-enabled nginx.service Fehlgeschlagene Units anzeigen [RO] systemctl --failed Journal des Dienstes seit dem aktuellen Start [RO] journalctl -b -u nginx.service Wichtige Unterscheidung Befehl Aussage systemctl is-active Läuft die Unit aktuell? systemctl is-enabled Ist ein automatischer Start konfiguriert? systemctl status Status, PID und letzte Logmeldungen journalctl -u ausführlicher zeitlicher Verlauf der Unit Ein Dienst kann aktiviert, aber aktuell nicht aktiv sein. Umgekehrt kann ein manuell gestarteter Dienst aktiv sein, obwohl er nicht für den automatischen Start aktiviert wurde. 11. Wie werden klassische Linux-Protokolldateien gelesen? Abhängig von Distribution und Dienst befinden sich Textprotokolle häufig unter: /var/log/ Typische Beispiele: Pfad Möglicher Inhalt /var/log/syslog allgemeine Systemmeldungen bei Debian/Ubuntu /var/log/messages allgemeine Systemmeldungen bei RHEL-artigen Systemen /var/log/auth.log Authentifizierungsereignisse bei Debian/Ubuntu /var/log/secure Authentifizierungsereignisse bei RHEL-artigen Systemen /var/log/kern.log Kernelmeldungen /var/log/dmesg gespeicherte Boot- und Kernelmeldungen /var/log/nginx/ Nginx-Zugriffs- und Fehlerprotokolle /var/log/apache2/ Apache-Protokolle bei Debian/Ubuntu /var/log/httpd/ Apache-Protokolle bei RHEL-artigen Systemen Die tatsächlichen Pfade hängen von Distribution, Paket, Konfiguration und Protokollierungsdienst ab. Sie müssen deshalb auf dem konkreten System geprüft werden. Datei mit less öffnen [RO] less /var/log/syslog Nützliche Tasten in less : Taste Funktion G zum Dateiende g zum Dateianfang /text vorwärts suchen ?text rückwärts suchen n nächster Treffer N vorheriger Treffer q beenden Letzte Zeilen anzeigen [RO] tail -n 50 /var/log/syslog Neue Zeilen live verfolgen [RO] tail -f /var/log/syslog Datei auch nach Rotation weiterverfolgen [RO] tail -F /var/log/nginx/error.log tail -F versucht im Gegensatz zu tail -f , die Datei nach einer Rotation oder Neuerstellung erneut zu öffnen. Bestimmten Begriff suchen [RO] grep -i "error" /var/log/syslog Mehrere Begriffe suchen [RO] grep -Ei "error|failed|timeout|denied" /var/log/syslog Zeilennummern anzeigen [RO] grep -Ein "error|failed|timeout|denied" /var/log/syslog Treffer mit Kontext anzeigen [RO] grep -Ein -B 3 -A 5 "timeout" /var/log/syslog Option Bedeutung -i Groß- und Kleinschreibung ignorieren -E erweiterte reguläre Ausdrücke -n Zeilennummer anzeigen -B 3 drei Zeilen vor dem Treffer -A 5 fünf Zeilen nach dem Treffer -C 5 fünf Zeilen vor und nach dem Treffer 12. Wie werden rotierte und komprimierte Linux-Logs durchsucht? Protokolle werden häufig rotiert, damit einzelne Dateien nicht unbegrenzt wachsen. Beispiel: auth.log auth.log.1 auth.log.2.gz auth.log.3.gz Datei Bedeutung auth.log aktuelles Protokoll auth.log.1 vorherige unkomprimierte Generation auth.log.2.gz ältere komprimierte Generation Komprimiertes Protokoll anzeigen [RO] zless /var/log/auth.log.2.gz Komprimiertes Protokoll durchsuchen [RO] zgrep -i "failed" /var/log/auth.log.2.gz Mehrere rotierte Dateien durchsuchen [RO] zgrep -Ei "failed|denied|timeout" /var/log/auth.log.*.gz Aktuelle und ältere unkomprimierte Dateien durchsuchen: [RO] grep -Ei "failed|denied|timeout" /var/log/auth.log /var/log/auth.log.1 Vor einer Analyse sollte geprüft werden, ob der Störungszeitpunkt bereits in einer rotierten Datei liegt. 13. Wie werden Kernel- und Hardwaremeldungen unter Linux geprüft? Kernelmeldungen aus dem Journal [RO] journalctl -k -b Klassische dmesg-Ausgabe [RO][PRIV] sudo dmesg Menschenlesbare Zeitstempel: [RO][PRIV] sudo dmesg --human Nur Warnungen und Fehler anzeigen: [RO][PRIV] sudo dmesg --level=warn,err,crit,alert,emerg Nach typischen Hardware- und Netzwerkproblemen suchen: [RO][PRIV] sudo dmesg --human | grep -Ei "error|failed|timeout|reset|link.*down|I/O" Typische Hinweise: Meldung Mögliche Untersuchungsrichtung I/O error Datenträger, Kabel, Controller oder Dateisystem link down Netzwerkkabel, Switchport, Treiber oder Interface reset Gerät, Bus, Treiber oder Stromversorgung out of memory Speicherdruck und OOM-Killer segfault Programmfehler, Bibliothek oder Speicherproblem read-only filesystem Dateisystemfehler oder Schutzreaktion firmware failed to load fehlende oder inkompatible Firmware Eine Meldung beschreibt zunächst nur eine Beobachtung. Beispielsweise kann ein link down durch das bewusste Abziehen eines Kabels entstanden sein. 14. Wie werden macOS-Protokolle mit der Konsole untersucht? Die App Konsole zeigt unter anderem: Live-Protokollmeldungen, System- und Anwendungsaktivitäten, Absturzberichte, Diagnoseberichte, Spin- und Hang-Berichte, Systemberichte. Öffnen über Spotlight: Konsole Oder über das Terminal: [RO] open -a Console Empfohlenes Vorgehen In der Seitenleiste den lokalen Mac auswählen. Live-Anzeige nur für einen kurzen Zeitraum aktivieren. Suchfeld nach Prozess, Subsystem, Kategorie oder Meldung filtern. Fehler einmal reproduzieren. Live-Anzeige wieder anhalten. Ereignisse unmittelbar vor und nach dem Fehler untersuchen. Detailbereich des Ereignisses öffnen. Prozess, Subsystem, Kategorie und Zeitstempel dokumentieren. Abhängig von Benutzerrechten und Systemeinstellungen sind nicht alle Meldungen sichtbar. Für bestimmte Protokolle kann eine administrative Authentifizierung erforderlich sein. 15. Wie werden macOS-Protokolle mit log show ausgewertet? macOS verwendet das Unified Logging System. Historische Ereignisse werden mit log show untersucht. Letzte zehn Minuten anzeigen [RO] log show --last 10m Letzte Stunde anzeigen [RO] log show --last 1h Kompakte Darstellung [RO] log show --last 10m --style compact Nach Prozess filtern [RO] log show \ --last 30m \ --style compact \ --predicate 'process == "Safari"' Nach Subsystem filtern [RO] log show \ --last 30m \ --style compact \ --predicate 'subsystem == "com.apple.network"' Das konkrete Subsystem muss zuvor aus einem passenden Ereignis ermittelt werden. Es darf nicht allein anhand des Produktnamens angenommen werden. Nach Text in der Ereignismeldung suchen [RO] log show \ --last 30m \ --style compact \ --predicate 'eventMessage CONTAINS[c] "error"' Mehrere Bedingungen kombinieren [RO] log show \ --last 30m \ --style compact \ --predicate 'process == "Safari" AND eventMessage CONTAINS[c] "network"' Informations- und Debugmeldungen einbeziehen [RO] log show \ --last 10m \ --info \ --debug \ --style compact Debugmeldungen können sehr umfangreich sein. Das Zeitfenster sollte deshalb möglichst klein gewählt werden. Bestimmtes Zeitfenster untersuchen [RO] log show \ --start '2026-07-31 09:30:00' \ --end '2026-07-31 09:45:00' \ --style compact Datumsformat, Zeitzone und unterstützte Optionen sollten auf der eingesetzten macOS-Version mit man log beziehungsweise log help show geprüft werden. 16. Wie werden macOS-Protokolle live verfolgt? Live-Ausgabe starten [RO] log stream Kompakte Live-Ausgabe [RO] log stream --style compact Bestimmten Prozess verfolgen [RO] log stream \ --style compact \ --predicate 'process == "Safari"' Nach Meldungsinhalt filtern [RO] log stream \ --style compact \ --predicate 'eventMessage CONTAINS[c] "timeout"' Informationsmeldungen einbeziehen [RO] log stream --info --style compact Beenden mit: Strg+C Sicherer Ablauf Filter vorbereiten. Live-Aufzeichnung starten. Problem genau einmal reproduzieren. Aufzeichnung sofort beenden. Zeitstempel und relevante Ereignisse dokumentieren. Eine ungefilterte Live-Ausgabe kann sehr schnell unübersichtlich werden. 17. Wie werden Docker-Containerlogs untersucht? Docker schreibt standardmäßig die Standardausgabe und Standardfehlerausgabe eines Containers in den konfigurierten Logging-Treiber. Die tatsächlich verfügbaren Logs hängen deshalb von Container, Anwendung und Logging-Konfiguration ab. Laufende Container anzeigen [RO] docker ps Auch beendete Container anzeigen: [RO] docker ps -a Logs eines Containers anzeigen [RO][SENS] docker logs beispiel-container Letzte 100 Zeilen anzeigen [RO][SENS] docker logs --tail 100 beispiel-container Zeitstempel einblenden [RO][SENS] docker logs --timestamps --tail 100 beispiel-container Logs live verfolgen [RO][SENS] docker logs --follow --tail 100 beispiel-container Logs seit einem relativen Zeitpunkt [RO][SENS] docker logs --since 30m beispiel-container Logs seit einem absoluten Zeitpunkt [RO][SENS] docker logs \ --since "2026-07-31T09:30:00+02:00" \ beispiel-container Zeitfenster begrenzen [RO][SENS] docker logs \ --since "2026-07-31T09:30:00+02:00" \ --until "2026-07-31T09:45:00+02:00" \ --timestamps \ beispiel-container Docker-Compose-Dienste anzeigen [RO] docker compose ps Logs eines Compose-Dienstes [RO][SENS] docker compose logs --tail 100 beispiel-dienst Compose-Logs live verfolgen [RO][SENS] docker compose logs --follow --tail 100 beispiel-dienst Wichtige Grenzen Nicht jede Anwendung schreibt alle Fehler nach stdout oder stderr . Ein Container kann zusätzlich interne Logdateien verwenden. Ein nicht mehr vorhandener Container kann auch nicht mehr direkt mit docker logs abgefragt werden. Logrotation und Logging-Treiber beeinflussen die Verfügbarkeit. Das Fehlen einer Meldung beweist nicht, dass kein Fehler aufgetreten ist. 18. Wie werden Webserver- und Reverse-Proxy-Logs interpretiert? Webserver führen häufig mindestens zwei getrennte Protokolle: Protokoll Inhalt Access Log eingegangene HTTP-Anfragen und Antwortstatus Error Log interne Fehler, Verbindungsprobleme und Konfigurationshinweise Typischer Access-Log-Eintrag: 192.0.2.50 - - [31/Jul/2026:09:42:15 +0200] "GET /login HTTP/1.1" 502 157 Bestandteil Bedeutung 192.0.2.50 Client-IP-Adresse Zeitstempel Zeitpunkt und Zeitzone GET HTTP-Methode /login angeforderter Pfad HTTP/1.1 Protokollversion 502 HTTP-Statuscode 157 übertragene Antwortgröße, abhängig vom Logformat Wichtige HTTP-Statusgruppen Bereich Bedeutung 1xx Information 2xx erfolgreiche Verarbeitung 3xx Umleitung 4xx Anfrage konnte aus Clientsicht nicht verarbeitet werden 5xx serverseitige Verarbeitung fehlgeschlagen Typische Statuscodes: Status Bedeutung Untersuchungsrichtung 200 Anfrage erfolgreich Inhalt und Antwortzeit prüfen 301 / 302 Umleitung Ziel und Weiterleitungskette prüfen 400 ungültige Anfrage Header, Syntax und Proxy prüfen 401 Authentifizierung erforderlich oder fehlgeschlagen Anmeldedaten und Authentifizierungsdienst 403 Zugriff verweigert Berechtigungen und Regeln 404 Ressource nicht gefunden Pfad, Routing und Deployment 429 zu viele Anfragen Rate-Limit und Last 500 interner Serverfehler Anwendungslog prüfen 502 ungültige Antwort vom Backend Backend-Erreichbarkeit und Proxy 503 Dienst nicht verfügbar Dienststatus, Wartung und Kapazität 504 Zeitüberschreitung zum Backend Backend-Laufzeit, Netzwerk und Timeout Ein 502 wird häufig am Reverse Proxy sichtbar, obwohl die eigentliche Ursache im Backenddienst liegt. Deshalb müssen Proxy- und Backend-Logs über Zeitstempel, Pfad und Korrelations-ID verbunden werden. 19. Wie werden Authentifizierungsfehler untersucht? Bei Anmeldeproblemen können mehrere Systeme beteiligt sein: Client → Anwendung → Reverse Proxy → Identitätsanbieter → Verzeichnisdienst → MFA-Dienst Zu erfassende Informationen exakter Zeitpunkt, Benutzerkennung, Client und Quell-IP, Zielanwendung, Authentifizierungsverfahren, verwendeter Identitätsanbieter, Korrelations- oder Request-ID, Fehlercode, Ergebnis einer Vergleichsanmeldung, mögliche Uhrzeitabweichung. Typische Ursachen Beobachtung Mögliche Untersuchungsrichtung Benutzer unbekannt falscher Mandant, falsche Domäne oder Synchronisation Kennwort abgelehnt falsches Kennwort, Kontosperre oder abgelaufenes Kennwort Token abgelaufen Zeitabweichung oder zu lange Sitzung Zertifikat ungültig Ablaufdatum, Vertrauenskette oder Hostname MFA fehlgeschlagen Endgerät, Push-Dienst oder Richtlinie Zugriff verweigert Rolle, Gruppe oder Conditional-Access-Regel LDAP nicht erreichbar DNS, Routing, Port, TLS oder Dienststatus Wiederholte Fehlversuche gespeicherte alte Zugangsdaten oder automatischer Dienst Authentifizierungsprotokolle enthalten besonders schützenswerte Informationen. Kennwörter, Tokens oder Cookies dürfen nicht in die Dokumentation kopiert werden. 20. Wie werden Meldungen verschiedener Systeme miteinander korreliert? Beispiel einer verteilten Anfrage 09:42:15.120 Client sendet Anfrage 09:42:15.145 Reverse Proxy nimmt Anfrage an 09:42:15.151 Backend beginnt Verarbeitung 09:42:20.152 Backend meldet Datenbank-Timeout 09:42:20.153 Reverse Proxy erhält keine gültige Antwort 09:42:20.154 Client erhält HTTP 504 Der 504 -Fehler auf dem Client ist hier eine Folge. Der erste technisch relevante Fehler ist der Datenbank-Timeout im Backend. Geeignete Korrelationsmerkmale Merkmal Nutzen Zeitstempel grobe zeitliche Zuordnung Request-ID eindeutige Anfrageverfolgung Trace-ID verteilte Ablaufverfolgung Session-ID Zuordnung zu einer Sitzung Benutzer-ID Zuordnung zu einem Konto Quell-IP Zuordnung zu einem Client Zielpfad Zuordnung zu einer Funktion Prozess-ID Zuordnung zu einem lokalen Prozess Transaktions-ID Zuordnung zu einem Geschäftsvorgang Korrelationsregel Gleiche Uhrzeit allein ist kein Beweis für denselben Vorgang. Je mehr Merkmale übereinstimmen, desto belastbarer ist die Zuordnung. 21. Wie wird nach Fehlercodes und Meldungen gesucht? Vor der Internetrecherche sollten folgende Angaben vollständig erfasst werden: Produktname, Produktversion, Betriebssystemversion, Provider oder Quelle, Ereignis-ID, vollständiger Fehlercode, genaue Fehlermeldung, betroffene Funktion, Zeitpunkt und Kontext. Gute Suchanfrage Microsoft-Windows-DNS-Client Event ID 1014 Windows 11 Ungenaue Suchanfrage Internet geht nicht Fehler Quellenreihenfolge offizielle Herstellerdokumentation, offizielle Knowledge Base oder Supportartikel, offizielle Quellcode-Repositories und Issue-Tracker, Dokumentation des eingesetzten Projekts, seriöse Fachquellen, Community-Beiträge als ergänzende Hinweise. Ein Community-Beitrag kann eine nützliche Hypothese liefern, ersetzt aber keine Prüfung am eigenen System. 22. Welche typischen Fehler werden bei der Log-Analyse gemacht? Fehler Folge Besseres Vorgehen Nur nach dem Wort error suchen relevante Warnungen und Statusmeldungen fehlen Dienst, Zeitfenster und Ereigniskette prüfen Nur das letzte Ereignis betrachten ursprüngliche Ursache wird übersehen zeitlich rückwärts zum ersten relevanten Fehler gehen Zeitzonen ignorieren Ereignisse werden falsch zugeordnet Zeit und UTC-Offset dokumentieren Gesamtes Log ungefiltert lesen relevante Ereignisse gehen in der Menge unter Zeitfenster und Quelle begrenzen Logs vor Sicherung löschen Beweise gehen verloren zuerst exportieren und Integrität sichern Debug-Logging dauerhaft aktivieren Speicherplatz- und Datenschutzprobleme kurzzeitig aktivieren und danach zurücksetzen Fehlermeldung isoliert suchen falsche Produkt- oder Versionslösung Quelle, Version und Kontext ergänzen Nur ein System prüfen verteilte Ursache bleibt verborgen alle beteiligten Systeme korrelieren Fehlerhäufigkeit nicht beachten Einzelereignis wird überbewertet Häufigkeit und Vergleichswerte prüfen Geheimnisse in Tickets kopieren Sicherheitsvorfall möglich Daten vor Weitergabe redigieren Logdatei während der Analyse verändern Beweiskraft sinkt Original sichern und Arbeitskopie verwenden Nur Fehlermeldungen berücksichtigen erfolgreicher Fallback wird übersehen gesamte Ereigniskette betrachten 23. Wie wird eine aussagekräftige Ereigniskette erstellt? Eine gute Ereigniskette enthält nicht sämtliche Logzeilen, sondern die für den Vorgang relevanten Ereignisse. Zeit System Quelle Ereignis Bedeutung 09:42:10.100 CLIENT-023 Anwendung Anfrage gestartet Benutzeraktion beginnt 09:42:10.130 PROXY-01 Nginx Anfrage angenommen Proxy ist erreichbar 09:42:10.150 APP-01 Backend DB-Abfrage gestartet Backend verarbeitet Anfrage 09:42:15.151 APP-01 Backend DB-Timeout erster belegter Fehler 09:42:15.152 PROXY-01 Nginx Upstream timeout Folgefehler 09:42:15.160 CLIENT-023 Anwendung HTTP 504 sichtbare Auswirkung Auswertung Symptom: Client erhält HTTP 504. Erster belegter Fehler: Datenbank-Timeout auf APP-01. Folgefehler: Reverse Proxy erhält keine rechtzeitige Backend-Antwort. Nächster Prüfschritt: Datenbankerreichbarkeit, Datenbanklast und Abfragedauer im Zeitraum 09:42:10 bis 09:42:15 untersuchen. 24. Kompakte Befehlsübersicht für Windows, Linux und macOS Aufgabe Windows Linux macOS Grafische Loganzeige öffnen [RO] eventvwr.msc abhängig von Desktop und Distribution [RO] open -a Console Neueste Systemereignisse [RO] Get-WinEvent -LogName System -MaxEvents 20 [RO] journalctl -n 20 [RO] log show --last 10m --style compact Aktuellen Start untersuchen Ereignis-IDs und Startzeit filtern [RO] journalctl -b [RO] log show --last boot --style compact Vorherigen Start untersuchen Systemprotokoll nach vorherigem Startzeitraum filtern [RO] journalctl -b -1 über Zeitfenster beziehungsweise Logarchiv Kernelmeldungen Systemprotokoll und providerspezifische Logs [RO] journalctl -k -b [RO] log show --last 1h --predicate 'process == "kernel"' Letzte Stunde Get-WinEvent mit StartTime=(Get-Date).AddHours(-1) [RO] journalctl --since "1 hour ago" [RO] log show --last 1h Dienstprotokoll nach Provider oder Dienstprotokoll filtern [RO] journalctl -u nginx.service nach process oder subsystem filtern Live-Anzeige Ereignisanzeige oder providerspezifisch [RO] journalctl -f [RO] log stream --style compact Fehler filtern Get-WinEvent mit Level=1,2 [RO] journalctl -p err Predicate nach Prozess, Typ oder Meldung Textdatei lesen [RO] Get-Content .\app.log [RO] less /var/log/app.log [RO] less /Pfad/app.log Letzte 50 Zeilen [RO] Get-Content .\app.log -Tail 50 [RO] tail -n 50 /var/log/app.log [RO] tail -n 50 /Pfad/app.log Datei live verfolgen [RO] Get-Content .\app.log -Wait -Tail 50 [RO] tail -F /var/log/app.log [RO] tail -F /Pfad/app.log Text suchen [RO] Select-String -Path .\app.log -Pattern 'error' [RO] grep -i 'error' /var/log/app.log [RO] grep -i 'error' /Pfad/app.log Komprimiertes Log lesen abhängig vom Archivformat [RO] zless /var/log/app.log.2.gz [RO] gzcat /Pfad/app.log.gz | less Ereignisse exportieren [FILE][SENS] wevtutil epl System C:\Temp\System.evtx [FILE][SENS] journalctl --since today > journal.txt [FILE][SENS] log show --last 1h > macos-log.txt Containerlogs [RO][SENS] docker logs --tail 100 NAME [RO][SENS] docker logs --tail 100 NAME [RO][SENS] docker logs --tail 100 NAME log show --last boot kann je nach eingesetzter macOS-Version beziehungsweise Werkzeugsyntax nicht verfügbar sein. Die lokal unterstützten Optionen sind mit log help show zu prüfen. Ein festes Zeitfenster mit --start und --end ist die eindeutigere Alternative. 25. Dokumentationsvorlage für eine Log-Analyse Ticketnummer: Analysedatum: Betroffenes System: Betriebssystem: Anwendung oder Dienst: Anwendungsversion: Betroffener Benutzer: Fehlerbeschreibung: Fehlerzeitpunkt: Zeitzone: Letzter funktionierender Zeitpunkt: Reproduzierbar: Ja / Nein Untersuchte Protokolle: - - - Verwendete Filter: - Zeitraum: - Quelle/Provider: - Ereignis-ID: - Prozess/PID: - Dienst/Unit: - Benutzer/UID: - Korrelations-ID: - Suchbegriffe: Erster relevanter Fehler: Zeitpunkt: System: Quelle: Ereignis-ID oder Fehlercode: Vollständige Meldung: Vorhergehende Ereignisse: - - - Nachfolgende Ereignisse: - - - Ereigniskette: 1. 2. 3. 4. Arbeitshypothese: Begründung: Kontrollierter Test: Testergebnis: Ermittelte Ursache: Durchgeführte Änderung: Rückweg: Abschlussprüfung: Gesicherte Dateien: - EVTX: - Journal: - Textlog: - CSV: - Diagnosearchiv: Original unverändert gesichert: Ja / Nein Sensible Daten redigiert: Ja / Nein Speicherort: Zugriffsberechtigung: Aufbewahrungs- oder Löschfrist: 26. Offizielle Quellen und weiterführende Dokumentation Microsoft Get-WinEvent – Microsoft Learn wevtutil – Microsoft Learn Windows-Ereignisprotokollierung – Microsoft Learn Linux und systemd journalctl – systemd-Dokumentation systemctl – systemd-Dokumentation systemd-journald – systemd-Dokumentation systemd Journal Fields Apple Konsole – Benutzerhandbuch für macOS Protokollmeldungen in der Konsole anzeigen Protokollmeldungen und Aktivitäten suchen Lokale Befehlsreferenz: man log und log help Docker docker logs – Docker-Dokumentation Docker Logging Drivers docker compose logs Befehlsoptionen, Protokollpfade und verfügbare Felder können von Betriebssystem-, Distributions- und Anwendungsversion abhängen. Vor dem produktiven Einsatz ist deshalb zusätzlich die lokale Hilfeseite des konkreten Systems zu prüfen.