# Logging on RHEL: Journald & rsyslog im Team

TL;DR / Management Summary In der RHEL-Welt (Red Hat Enterprise Linux) verlassen wir uns auf ein Duo: systemd-journald sammelt strukturierte Daten direkt vom Kernel und den Diensten, während rsyslog diese Daten oft in Textform für SIEM-Systeme oder Langzeit-Archive aufbereitet. Ein Senior Admin muss wissen, wie man das Journal in RHEL persistent macht (standardmäßig oft nur im RAM) und wie man zwischen binärem Journal und klassischem Syslog navigiert.

# 1. Einführung & Architektur

Der hybride Log-Stack.

RHEL nutzt journald als primären Empfänger. Rsyslog liest die Daten vom Journal via das Modul imjournal ab.

graph TD
    A[Kernel / Processes] --> B[systemd-journald]
    B -->|Binary Storage| C[/run/log/journal/ - RAM]
    B -->|Binary Storage| D[/var/log/journal/ - Disk]
    B -->|Forward| E[rsyslog]
    E -->|Text Files| F[/var/log/messages]
    E -->|Text Files| G[/var/log/secure]
    E -->|Forward| H[Remote Log Server / Splunk]

# 2. Persistenz einschalten

Logs, die den Reboot überleben.

Auf vielen RHEL-Minimal-Installationen ist das Journal flüchtig (volatile).

# Schritt 1: Verzeichnis anlegen

Sobald das Verzeichnis existiert, nutzt journald es automatisch.

sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal
sudo systemctl restart systemd-journald

# Schritt 2: Konfiguration (/etc/systemd/journald.conf)

[Journal]
Storage=persistent
Compress=yes
SystemMaxUse=1G
RuntimeMaxUse=128M

# 3. RHEL Spezifische Log-Dateien

Wo steht was im Syslog?

Obwohl journalctl alles sieht, trennt rsyslog in RHEL traditionell wichtige Ereignisse:

# 4. Day-2 Operations: Analyse & Export

Den Überblick behalten.

# Boot-Logs vergleichen

Da RHEL-Server oft lange laufen, ist der Vergleich zwischen Boots essenziell.

# Zeige alle verfügbaren Boot-IDs
journalctl --list-boots

# Vergleiche Logs des aktuellen Boots mit dem vorletzten
journalctl -b -2

# Logs exportieren (für den Support)

Wenn Sie einen Red Hat Support Case eröffnen, schicken Sie keine Textdateien. Nutzen Sie SOS-Report:

sudo sosreport

Dies sammelt alle Logs, Configs und Systemdaten in einem komprimierten Archiv.

# 5. Troubleshooting & “War Stories”

Wenn das Journal streikt.

# Story 1: “Der Log-Speicher frisst die Disk”

Symptom: Die Root-Partition ist voll, obwohl die Applikations-Logs klein sind. Ursache: Das Journal hat keine Limits (SystemMaxUse) und ein Dienst produziert tausende Warnungen pro Sekunde. Lösung: Limitieren Sie das Journal in der journald.conf und räumen Sie sofort auf:

sudo journalctl --vacuum-size=500M

# Story 2: “Time-Drift Verwirrung”

Symptom: journalctl --since "1 hour ago" zeigt keine Ergebnisse, obwohl der Dienst läuft. Ursache: Die Systemzeit des Servers wurde via NTP korrigiert (z.B. von 2020 auf 2023). Das binäre Journal ist nach Zeitstempeln sortiert und “findet” die neuen Einträge nicht im erwarteten Bereich. Lösung: Nutzen Sie journalctl -f, um das Ende des Logs zu sehen, oder löschen Sie das Journal und starten Sie neu, um die Indizierung zu fixen.

# 6. Fazit & Empfehlung

• Persistent: Machen Sie das Journal immer persistent (Storage=persistent).
• Audit-Logs: Nutzen Sie für Security-Audits weiterhin auditd (siehe Artikel 030), da journald nicht revisionssicher gegen Root-Manipulation ist.
• Zentralisierung: Leiten Sie /var/log/secure via rsyslog sofort an einen externen Host weiter.

# Anhang: Cheatsheet