Log-Analyse: Eventlog und journald

Während Syslog das Netzwerkprotokoll für Log-Transport ist, geht es in dieser Lektion um die zwei zentralen lokalen Logsysteme moderner Betriebssysteme: journald auf systemd-basierten Linux-Distributionen und das Windows Event Log. Beide sind das, was du als Administrator zuerst zur Hand nimmst, wenn ein System zickt – „seit wann läuft das nicht?". Beide sind strukturierter und mächtiger als die alten flachen Logdateien, beide haben Filter-Sprachen, mit denen du in Sekunden die richtigen Ereignisse rauspickst – wenn du sie kennst. Diese Lektion zeigt dir die wichtigsten Filter-Kommandos beider Welten und wie sie zusammenarbeiten, denn in heterogenen Umgebungen wirst du beide sehen.

1) Die zwei Welten – Side-by-Side

Konzeptionell machen beide dasselbe: Ereignisse strukturiert speichern, durchsuchbar machen, Logrotation übernehmen. Technisch unterscheiden sie sich stark:

2) journalctl – die wichtigsten Filter

Klick dich durch die Filter, um zu sehen, wie das volle Kommando wächst und welcher Output rauskommt:

3) Severity-Mapping – beide Welten kennen die acht Stufen

Die acht Syslog-Severities kennst du schon. journald nutzt sie 1:1 (0–7 als PRIORITY-Wert). Das Windows Event Log hat seine eigene Bezeichnung mit weniger Stufen – die du beim Forwarding ans zentrale Syslog korrekt mappen musst:

4) Windows Event Log – die Channels

Wo journald alles in einen Strom legt (mit Filtern), trennt Windows in Channels. Die wichtigsten:

Wichtige Event-IDs, die du in der Prüfung kennen solltest (Security-Channel):

5) PowerShell – Get-WinEvent

Das Pendant zu journalctl ist Get-WinEvent. Beispiele, die du beim FISI-Alltag brauchst:

# Alle fehlgeschlagenen Logon-Versuche der letzten 24 Stunden
Get-WinEvent -FilterHashtable @{LogName='Security'; ID=4625;
  StartTime=(Get-Date).AddDays(-1)}

# System-Errors der letzten Stunde
Get-WinEvent -FilterHashtable @{LogName='System'; Level=2;
  StartTime=(Get-Date).AddHours(-1)}

# Nach Source filtern
Get-WinEvent -LogName Application |
  Where-Object ProviderName -eq 'MSSQLServer'

Die alten eventvwr.msc-Klicks ersetzt du damit. Für komplexere Auswertungen geht es in Richtung XPath-Queries (-FilterXPath) – mächtig, aber gewöhnungsbedürftig.

6) Strukturierte vs. unstrukturierte Logs

journald speichert strukturiert: jede Nachricht hat Felder. Das macht Abfragen wie journalctl _PID=1234 oder journalctl _UID=1000 --since today erst möglich. Event Log macht es ähnlich mit seinen Event-IDs und Source/Provider-Feldern.

Klassische Logdateien (/var/log/nginx/access.log, application.log) sind dagegen unstrukturiert – freier Text. Da hilft nur Pattern Matching, oft mit Regulären Ausdrücken, grep, awk, sed. Moderne Anwendungen loggen deshalb zunehmend strukturiert in JSON:

{"ts":"2026-05-18T11:42:18Z","level":"error","msg":"payment failed",
 "user_id":8231,"amount":49.90,"trace_id":"abc123..."}

Damit wird der Logstrom selbst „abfrage-fähig" – Elasticsearch, Loki, Splunk parsen das nativ und lassen dich nach Feldwerten suchen.

7) Forwarding – lokale Logs ins Zentrum bringen

Ein Single-Server-Setup ist die Ausnahme. Im Regelfall hast du Dutzende Maschinen und willst alle Logs an einen zentralen Punkt schicken. Die zwei Welten:

• Linux: journald hat keine eingebaute Forwarding-Funktion auf entfernte Hosts. Üblich: journald → rsyslog/syslog-ng auf demselben Host, dann das Standard-Syslog-Forwarding zum Zentral-Server. Alternative für reichere Pipelines: Filebeat, Fluentd, Vector – direkt zu ELK/Loki/Graylog.
• Windows: nativ über Windows Event Forwarding (WEF/WEC) – Quell-Hosts schicken an einen Collector-Server. Alternative Drittsoftware: NXLog, Winlogbeat, Splunk Universal Forwarder.

In gemischten Umgebungen ergänzt sich beides oft: Linux-Server schicken Syslog, Windows-Server senden Events – ein zentraler Log-Aggregator (z. B. Graylog) normalisiert beides und stellt ein einheitliches Frontend bereit.

8) Was darfst du loggen? – Datenschutz

Logs enthalten oft personenbezogene Daten – IPs, Usernames, manchmal sogar Inhalte von Request-Bodies. Drei Regeln gehören in den Werkzeugkasten:

1. Datenminimierung. Keine Kreditkarten-Nummern, Passwörter, Personal-Ausweis-Nummern in Logs. Bei OAuth-Tokens reicht ein Hash. Mehr in DSGVO-Grundprinzipien.
2. Aufbewahrungsfrist begrenzen. Typisch: 30–90 Tage für operative Logs, längere Fristen nur, wenn Audit-Pflicht (z. B. SOX, BAIT) oder konkreter Use-Case dokumentiert. In den TOMs festhalten.
3. Zugriff einschränken. Wer Logs lesen darf, ist im Berechtigungskonzept festgelegt – per RBAC. Volle journalctl-Zugriffsrechte sind effektiv root-Rechte (Logs enthalten alles, was Anwendungen geloggt haben).

Zusammenfassung

Auf modernen Linux-Systemen läuft die journald die zentrale Log-Sammelstelle: binär, indexiert, abfragbar über journalctl mit Filtern nach Unit, Priority, Zeit, Boot. Auf Windows übernimmt das Event Log mit seinen Channels (Application, Security, System, Forwarded) – abrufbar über die Ereignisanzeige, wevtutil oder PowerShell Get-WinEvent. Beide nutzen die acht Syslog-Severities (etwas anders benannt im Event Log). Strukturierte Logs (Felder oder JSON) sind unstrukturierten Textzeilen vorzuziehen – und Voraussetzung für effiziente Suche in zentralisierten Stacks (ELK, Loki, Graylog, Splunk). Forwarding: Linux meist über journald→rsyslog→Zentrum oder direkt mit Filebeat/Fluentd; Windows nativ per WEC oder per NXLog/Winlogbeat. Datenschutz: Datenminimierung, Aufbewahrungsfristen, RBAC.

Verwandte Lektionen: Syslog · Ereignisanzeige (Windows) · systemd-Dienste · und mehrWeitere relevante LektionenMonitoring-KonzeptReguläre AusdrückeTOMs (DSGVO)RBACProblem ManagementSystematische FehlersucheCIA-Triad