# 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:
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.
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:
```text
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.
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.
```text
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**
```text
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.
```text
2026-07-31 14:30:00
```
Ein Zeitstempel mit Offset ist eindeutig zuordenbar:
```text
2026-07-31T14:30:00+02:00
```
UTC-Darstellung:
```text
2026-07-31T12:30:00Z
```
6. Wie werden Windows-Ereignisprotokolle grafisch untersucht?
Die Windows-Ereignisanzeige wird mit folgendem Befehl geöffnet:
```cmd
[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**
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.
7. Wie werden Windows-Ereignisse mit PowerShell gelesen?
**Verfügbare Ereignisprotokolle auflisten**
```powershell
[RO] Get-WinEvent -ListLog * |
Select-Object LogName, RecordCount, IsEnabled, LogMode, MaximumSizeInBytes
```
Nur aktivierte Protokolle anzeigen:
```powershell
[RO] Get-WinEvent -ListLog * |
Where-Object IsEnabled |
Sort-Object LogName |
Select-Object LogName, RecordCount
```
**Neueste Ereignisse des Systemprotokolls**
```powershell
[RO] Get-WinEvent -LogName System -MaxEvents 20
```
**Neueste Ereignisse des Anwendungsprotokolls**
```powershell
[RO] Get-WinEvent -LogName Application -MaxEvents 20
```
**Ereignisse der letzten Stunde**
```powershell
[RO] $Start = (Get-Date).AddHours(-1)
Get-WinEvent -FilterHashtable @{
LogName = 'System'
StartTime = $Start
}
```
**Fehler und kritische Ereignisse der letzten 24 Stunden**
```powershell
[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**
```powershell
[RO] Get-WinEvent -FilterHashtable @{
LogName = 'System'
Id = 7036
} -MaxEvents 20
```
**Nach Provider filtern**
```powershell
[RO] Get-WinEvent -FilterHashtable @{
LogName = 'System'
ProviderName = 'Service Control Manager'
StartTime = (Get-Date).AddHours(-4)
}
```
**Mehrere Ereignis-IDs abfragen**
```powershell
[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**
```powershell
[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**
```powershell
[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**
```cmd
[RO][PRIV][FILE][SENS] wevtutil epl System C:\Temp\System.evtx
```
**Anwendungsprotokoll exportieren**
```cmd
[RO][PRIV][FILE][SENS] wevtutil epl Application C:\Temp\Application.evtx
```
**Ereignisse mit PowerShell als CSV exportieren**
```powershell
[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**
```powershell
[RO][FILE][SENS] Get-WinEvent -LogName System -MaxEvents 100 |
Export-Clixml -Path 'C:\Temp\System-Events.xml'
```
**Verfügbare Protokolle mit wevtutil auflisten**
```cmd
[RO] wevtutil el
```
**Letzte zehn Systemereignisse im Textformat anzeigen**
```cmd
[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:
```cmd
[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**
```bash
[RO] journalctl
```
**Neueste Einträge zuerst anzeigen**
```bash
[RO] journalctl -r
```
**Aktuellen Systemstart untersuchen**
```bash
[RO] journalctl -b
```
**Vorherigen Systemstart untersuchen**
```bash
[RO] journalctl -b -1
```
**Verfügbare Systemstarts anzeigen**
```bash
[RO] journalctl --list-boots
```
**Nur Kernelmeldungen anzeigen**
```bash
[RO] journalctl -k
```
**Kernelmeldungen des aktuellen Starts**
```bash
[RO] journalctl -k -b
```
**Protokoll eines Dienstes anzeigen**
```bash
[RO] journalctl -u ssh.service
```
```bash
[RO] journalctl -u nginx.service
```
**Protokoll eines Dienstes live verfolgen**
```bash
[RO] journalctl -u nginx.service -f
```
Beenden mit:
```text
Strg+C
```
**Ereignisse seit einem Zeitpunkt**
```bash
[RO] journalctl --since "2026-07-31 09:30:00"
```
**Zeitfenster eingrenzen**
```bash
[RO] journalctl \
--since "2026-07-31 09:30:00" \
--until "2026-07-31 10:00:00"
```
**Relative Zeitangaben**
```bash
[RO] journalctl --since "30 minutes ago"
```
```bash
[RO] journalctl --since today
```
**Nach Priorität filtern**
```bash
[RO] journalctl -p err
```
Fehler und schwerwiegendere Meldungen des aktuellen Starts:
```bash
[RO] journalctl -b -p err
```
Warnungen und schwerwiegendere Meldungen eines Dienstes:
```bash
[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**
```bash
[RO] journalctl _PID=4321
```
**Nach ausführbarer Datei filtern**
```bash
[RO] journalctl _EXE=/usr/sbin/sshd
```
**Nach Benutzer-ID filtern**
```bash
[RO] journalctl _UID=1000
```
**Ausgabe ohne Pager**
```bash
[RO] journalctl -u nginx.service --no-pager
```
**ISO-Zeitstempel verwenden**
```bash
[RO] journalctl -u nginx.service -o short-iso
```
**Ausführliche Felder eines Ereignisses anzeigen**
```bash
[RO] journalctl -u nginx.service -n 10 -o verbose
```
10. Wie wird der Status eines Linux-Dienstes einschließlich Logs geprüft?
**Dienststatus anzeigen**
```bash
[RO] systemctl status nginx.service
```
Ohne interaktiven Pager:
```bash
[RO] systemctl status nginx.service --no-pager
```
Vollständige Zeilen ohne Kürzung:
```bash
[RO] systemctl status nginx.service --no-pager --full
```
**Prüfen, ob der Dienst aktiv ist**
```bash
[RO] systemctl is-active nginx.service
```
**Prüfen, ob der Dienst aktiviert ist**
```bash
[RO] systemctl is-enabled nginx.service
```
**Fehlgeschlagene Units anzeigen**
```bash
[RO] systemctl --failed
```
**Journal des Dienstes seit dem aktuellen Start**
```bash
[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:
```text
/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**
```bash
[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**
```bash
[RO] tail -n 50 /var/log/syslog
```
**Neue Zeilen live verfolgen**
```bash
[RO] tail -f /var/log/syslog
```
**Datei auch nach Rotation weiterverfolgen**
```bash
[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**
```bash
[RO] grep -i "error" /var/log/syslog
```
**Mehrere Begriffe suchen**
```bash
[RO] grep -Ei "error|failed|timeout|denied" /var/log/syslog
```
**Zeilennummern anzeigen**
```bash
[RO] grep -Ein "error|failed|timeout|denied" /var/log/syslog
```
**Treffer mit Kontext anzeigen**
```bash
[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:
```text
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**
```bash
[RO] zless /var/log/auth.log.2.gz
```
**Komprimiertes Protokoll durchsuchen**
```bash
[RO] zgrep -i "failed" /var/log/auth.log.2.gz
```
**Mehrere rotierte Dateien durchsuchen**
```bash
[RO] zgrep -Ei "failed|denied|timeout" /var/log/auth.log.*.gz
```
Aktuelle und ältere unkomprimierte Dateien durchsuchen:
```bash
[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**
```bash
[RO] journalctl -k -b
```
**Klassische dmesg-Ausgabe**
```bash
[RO][PRIV] sudo dmesg
```
Menschenlesbare Zeitstempel:
```bash
[RO][PRIV] sudo dmesg --human
```
Nur Warnungen und Fehler anzeigen:
```bash
[RO][PRIV] sudo dmesg --level=warn,err,crit,alert,emerg
```
Nach typischen Hardware- und Netzwerkproblemen suchen:
```bash
[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:
```text
Konsole
```
Oder über das Terminal:
```bash
[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.
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**
```bash
[RO] log show --last 10m
```
**Letzte Stunde anzeigen**
```bash
[RO] log show --last 1h
```
**Kompakte Darstellung**
```bash
[RO] log show --last 10m --style compact
```
**Nach Prozess filtern**
```bash
[RO] log show \
--last 30m \
--style compact \
--predicate 'process == "Safari"'
```
**Nach Subsystem filtern**
```bash
[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**
```bash
[RO] log show \
--last 30m \
--style compact \
--predicate 'eventMessage CONTAINS[c] "error"'
```
**Mehrere Bedingungen kombinieren**
```bash
[RO] log show \
--last 30m \
--style compact \
--predicate 'process == "Safari" AND eventMessage CONTAINS[c] "network"'
```
**Informations- und Debugmeldungen einbeziehen**
```bash
[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**
```bash
[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**
```bash
[RO] log stream
```
**Kompakte Live-Ausgabe**
```bash
[RO] log stream --style compact
```
**Bestimmten Prozess verfolgen**
```bash
[RO] log stream \
--style compact \
--predicate 'process == "Safari"'
```
**Nach Meldungsinhalt filtern**
```bash
[RO] log stream \
--style compact \
--predicate 'eventMessage CONTAINS[c] "timeout"'
```
**Informationsmeldungen einbeziehen**
```bash
[RO] log stream --info --style compact
```
Beenden mit:
```text
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.
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**
```bash
[RO] docker ps
```
Auch beendete Container anzeigen:
```bash
[RO] docker ps -a
```
**Logs eines Containers anzeigen**
```bash
[RO][SENS] docker logs beispiel-container
```
**Letzte 100 Zeilen anzeigen**
```bash
[RO][SENS] docker logs --tail 100 beispiel-container
```
**Zeitstempel einblenden**
```bash
[RO][SENS] docker logs --timestamps --tail 100 beispiel-container
```
**Logs live verfolgen**
```bash
[RO][SENS] docker logs --follow --tail 100 beispiel-container
```
**Logs seit einem relativen Zeitpunkt**
```bash
[RO][SENS] docker logs --since 30m beispiel-container
```
**Logs seit einem absoluten Zeitpunkt**
```bash
[RO][SENS] docker logs \
--since "2026-07-31T09:30:00+02:00" \
beispiel-container
```
**Zeitfenster begrenzen**
```bash
[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**
```bash
[RO] docker compose ps
```
**Logs eines Compose-Dienstes**
```bash
[RO][SENS] docker compose logs --tail 100 beispiel-dienst
```
**Compose-Logs live verfolgen**
```bash
[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:
```text
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:
```text
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**
```text
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**
```text
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**
```text
Microsoft-Windows-DNS-Client Event ID 1014 Windows 11
```
**Ungenaue Suchanfrage**
```text
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.
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**
```text
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
```text
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](https://learn.microsoft.com/powershell/module/microsoft.powershell.diagnostics/get-winevent)
- [wevtutil – Microsoft Learn](https://learn.microsoft.com/windows-server/administration/windows-commands/wevtutil)
- [Windows-Ereignisprotokollierung – Microsoft Learn](https://learn.microsoft.com/windows/win32/wes/windows-event-log)
**Linux und systemd**
- [journalctl – systemd-Dokumentation](https://www.freedesktop.org/software/systemd/man/latest/journalctl.html)
- [systemctl – systemd-Dokumentation](https://www.freedesktop.org/software/systemd/man/latest/systemctl.html)
- [systemd-journald – systemd-Dokumentation](https://www.freedesktop.org/software/systemd/man/latest/systemd-journald.service.html)
- [systemd Journal Fields](https://www.freedesktop.org/software/systemd/man/latest/systemd.journal-fields.html)
**Apple**
- [Konsole – Benutzerhandbuch für macOS](https://support.apple.com/guide/console/welcome/mac)
- [Protokollmeldungen in der Konsole anzeigen](https://support.apple.com/guide/console/view-log-messages-cnsl1012/mac)
- [Protokollmeldungen und Aktivitäten suchen](https://support.apple.com/guide/console/find-log-messages-and-activities-cnslbf30b61a/mac)
- Lokale Befehlsreferenz: `man log` und `log help`
**Docker**
- [docker logs – Docker-Dokumentation](https://docs.docker.com/reference/cli/docker/container/logs/)
- [Docker Logging Drivers](https://docs.docker.com/engine/logging/)
- [docker compose logs](https://docs.docker.com/reference/cli/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.