2.12 Protokolle und Logs systematisch auswerten

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:

1. Protokolle nur so umfangreich wie erforderlich erfassen.
2. Exportierte Logs geschützt speichern.
3. Zugriff auf autorisierte Personen begrenzen.
4. Vor externer Weitergabe sensible Inhalte redigieren.
5. Originaldateien möglichst unverändert sichern.
6. Arbeitskopien getrennt vom Original anlegen.
7. Aufbewahrungs- und Löschfristen beachten.
8. Protokolle niemals unkontrolliert in öffentliche Analysedienste hochladen.

Vor dem Öffnen der ersten Protokolldatei sollten mindestens folgende Informationen bekannt sein:

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

1. Uhrzeit und Zeitzone aller beteiligten Systeme prüfen.
2. Fehler reproduzieren und exakten Zeitpunkt notieren.
3. Passendes Protokoll bestimmen.
4. Zeitfenster begrenzen.
5. Nach Quelle, Dienst, Prozess oder Ereignis-ID filtern.
6. Das erste relevante Ereignis suchen.
7. Vorhergehende und nachfolgende Ereignisse betrachten.
8. Meldungen zwischen beteiligten Systemen zeitlich korrelieren.
9. Hypothese aufstellen.
10. Hypothese durch einen kontrollierten Test überprüfen.

Eine Ereignis-ID ist normalerweise nur zusammen mit der Quelle eindeutig.

Ereignis-ID 1000 von Quelle A ≠ Ereignis-ID 1000 von Quelle B

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.

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

Die Windows-Ereignisanzeige wird mit folgendem Befehl geöffnet:

[RO] eventvwr.msc

Wichtige Protokollbereiche:

Empfohlenes Vorgehen

1. Passendes Protokoll auswählen.
2. Aktuelles Protokoll filtern verwenden.
3. Zeitraum auf den Störungszeitraum begrenzen.
4. Ereignisebene auswählen.
5. Falls bekannt, Quelle und Ereignis-ID eingeben.
6. Ereignis in der Detailansicht öffnen.
7. Allgemeine und XML-Ansicht vergleichen.
8. Ereignisse unmittelbar davor und danach untersuchen.
9. 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.

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

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.

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

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.

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

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

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

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.

Abhängig von Distribution und Dienst befinden sich Textprotokolle häufig unter:

/var/log/

Typische Beispiele:

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:

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

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

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.

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:

Eine Meldung beschreibt zunächst nur eine Beobachtung. Beispielsweise kann ein link down durch das bewusste Abziehen eines Kabels entstanden sein.

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

1. In der Seitenleiste den lokalen Mac auswählen.
2. Live-Anzeige nur für einen kurzen Zeitraum aktivieren.
3. Suchfeld nach Prozess, Subsystem, Kategorie oder Meldung filtern.
4. Fehler einmal reproduzieren.
5. Live-Anzeige wieder anhalten.
6. Ereignisse unmittelbar vor und nach dem Fehler untersuchen.
7. Detailbereich des Ereignisses öffnen.
8. 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.

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.

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

1. Filter vorbereiten.
2. Live-Aufzeichnung starten.
3. Problem genau einmal reproduzieren.
4. Aufzeichnung sofort beenden.
5. Zeitstempel und relevante Ereignisse dokumentieren.

Eine ungefilterte Live-Ausgabe kann sehr schnell unübersichtlich werden.

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.

Webserver führen häufig mindestens zwei getrennte Protokolle:

Typischer Access-Log-Eintrag:

192.0.2.50 - - [31/Jul/2026:09:42:15 +0200] "GET /login HTTP/1.1" 502 157

Wichtige HTTP-Statusgruppen

Typische Statuscodes:

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.

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

Authentifizierungsprotokolle enthalten besonders schützenswerte Informationen. Kennwörter, Tokens oder Cookies dürfen nicht in die Dokumentation kopiert werden.

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

Korrelationsregel

Gleiche Uhrzeit allein ist kein Beweis für denselben Vorgang.

Je mehr Merkmale übereinstimmen, desto belastbarer ist die Zuordnung.

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

1. offizielle Herstellerdokumentation,
2. offizielle Knowledge Base oder Supportartikel,
3. offizielle Quellcode-Repositories und Issue-Tracker,
4. Dokumentation des eingesetzten Projekts,
5. seriöse Fachquellen,
6. Community-Beiträge als ergänzende Hinweise.

Ein Community-Beitrag kann eine nützliche Hypothese liefern, ersetzt aber keine Prüfung am eigenen System.

Eine gute Ereigniskette enthält nicht sämtliche Logzeilen, sondern die für den Vorgang relevanten Ereignisse.

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.

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.

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:

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.