Linux: journalctl

journalctl ist das zentrale Werkzeug zur Analyse von System-Logs auf modernen Linux-Distributionen mit systemd. Das Tool bietet strukturierten Zugriff auf alle von systemd gesammelten Log-Daten und ersetzt in vielen Fällen das direkte Lesen von Log-Dateien in /var/log.

Welche Logs sammelt systemd?

Systemd sammelt Log-Daten aus verschiedenen Quellen in einem zentralen Journal:

Kernel-Logs: Nachrichten des Linux-Kernels, die normalerweise in /var/log/kern.log oder über dmesg zugänglich sind.

Service-Logs: Ausgaben aller systemd-Services, einschließlich deren Standard-Output und Standard-Error.

System-Logs: Nachrichten von systemd selbst über Service-Starts, -Stops und -Fehler.

Boot-Logs: Informationen über den Systemstart und Hardware-Initialisierung.

Authentifizierungs-Logs: Login-Versuche, sudo-Aktivitäten und andere sicherheitsrelevante Events.

Anwendungs-Logs: Direkte Ausgaben von Anwendungen, die das systemd-Journal nutzen.

Grundlegende Verwendung

# Alle verfügbaren Logs anzeigen
journalctl

# Live-Monitoring neuer Log-Einträge
journalctl -f

# Letzte 50 Zeilen anzeigen
journalctl -n 50

Filterung nach Services

# Logs eines bestimmten Services
journalctl -u nginx.service
journalctl -u ssh.service

# Mehrere Services gleichzeitig
journalctl -u nginx.service -u apache2.service

Zeitbasierte Filter

# Logs der letzten Stunde
journalctl --since "1 hour ago"

# Logs zwischen zwei Zeitpunkten
journalctl --since "2024-01-01" --until "2024-01-02"

# Nur heutige Logs
journalctl --since today

SYSLOG_FACILITY

Das Syslog-System kategorisiert Log-Nachrichten nach ihrer Quelle über sogenannte „Facilities“. Diese numerischen Codes helfen bei der Organisation und Filterung von Logs:

# Wichtigste Syslog-Facilities
0  - kernel messages
1  - user-level messages  
2  - mail system
3  - system daemons
4  - security/authorization messages (auth.log)
5  - messages generated internally by syslogd
6  - line printer subsystem
7  - network news subsystem
8  - UUCP subsystem
9  - clock daemon
10 - security/authorization messages (authpriv)
11 - FTP daemon
16 - local use facility (local0)
17 - local use facility (local1)

Filterung nach Syslog-Facility

# Alle Authentifizierungs-Logs (entspricht /var/log/auth.log)
journalctl SYSLOG_FACILITY=4 SYSLOG_FACILITY=10

# Kernel-Logs (entspricht /var/log/kern.log)
journalctl SYSLOG_FACILITY=0

# Mail-System-Logs
journalctl SYSLOG_FACILITY=2

Prioritätslevel

# Nur Fehler und kritische Meldungen
journalctl -p err

# Verfügbare Prioritäten (niedrigste bis höchste):
# debug, info, notice, warning, err, crit, alert, emerg
journalctl -p warning

Praktische Anwendungsfälle

SSH-Aktivitäten überwachen

# Alle SSH-Verbindungen
journalctl -u ssh.service

# Failed Login-Versuche
journalctl | grep "Failed password"

# Erfolgreiche Logins
journalctl | grep "Accepted password"

System-Fehler finden

# Alle Fehler der letzten 24 Stunden
journalctl -p err --since "24 hours ago"

# Boot-Probleme analysieren
journalctl -b 0 -p err

Service-Debugging

# Service-spezifische Fehler
journalctl -u apache2.service -p err -n 100

# Service-Neustart verfolgen
journalctl -u nginx.service --since "10 minutes ago"

Welche Logs sind NICHT über journalctl verfügbar?

Nicht alle Log-Dateien in /var/log werden automatisch von systemd gesammelt:

Anwendungs-spezifische Logs: Viele Anwendungen schreiben weiterhin direkt in eigene Log-Dateien, zum Beispiel:

• /var/log/apache2/access.log (Apache-Zugriffslogs)
• /var/log/mysql/error.log (MySQL-Fehlerprotokolle)
• /var/log/postgresql/postgresql.log

Legacy-System-Logs: Auf Systemen mit traditionellem syslog können manche Logs nur in den entsprechenden Dateien verfügbar sein.

Externe Logs: Log-Dateien, die von Anwendungen erstellt werden, die nicht mit systemd oder syslog integriert sind.

Überprüfung der Verfügbarkeit

Um zu testen, ob bestimmte Log-Inhalte über journalctl verfügbar sind:

# Suche nach spezifischen Begriffen
journalctl | grep -i "apache"
journalctl | grep -i "mysql"

# Prüfung auf UFW-Logs (werden über Kernel geloggt)
journalctl -k | grep UFW

# Vergleich mit traditioneller Log-Datei
sudo tail /var/log/auth.log
journalctl SYSLOG_FACILITY=4 SYSLOG_FACILITY=10 -n 20

Journal-Konfiguration

Das systemd-Journal kann für persistente Speicherung konfiguriert werden:

# Journal-Speicherverbrauch anzeigen
journalctl --disk-usage

# Alte Logs bereinigen
sudo journalctl --vacuum-size=100M
sudo journalctl --vacuum-time=2weeks

Die Konfiguration erfolgt in /etc/systemd/journald.conf:

# Persistente Speicherung aktivieren
Storage=persistent

# Maximale Journal-Größe
SystemMaxUse=1G

Boot-Logs analysieren

# Aktueller Boot
journalctl -b 0

# Vorheriger Boot
journalctl -b -1

# Liste aller verfügbaren Boots
journalctl --list-boots

Ausgabeformate

# Strukturierte JSON-Ausgabe
journalctl -o json

# Kurzes Format
journalctl -o short

# Alle verfügbaren Metadaten
journalctl -o verbose

Fazit

journalctl bietet einen strukturierten und effizienten Zugang zu System-Logs auf systemd-basierten Linux-Distributionen. Das Tool sammelt Logs aus verschiedenen Quellen zentral und ermöglicht präzise Filterung nach Services, Zeiträumen und Prioritäten. Während die meisten System-Logs über journalctl zugänglich sind, schreiben viele Anwendungen weiterhin in separate Log-Dateien. Die Kombination aus journalctl für System-Logs und direktem Dateizugriff für anwendungsspezifische Logs bietet die umfassendste Übersicht über das Systemverhalten.