Wo Betriebssysteme ihre Logs ablegen und wie sich jedes davon abfragen lässt

Worum es geht

«Logs prüfen» bedeutet auf jedem System einen anderen Speicher und einen anderen Befehl.

System	Ablageort der Logs	Abfragebefehl
Linux mit systemd	das binäre Journal, dazu Dateien unter /var/log für Dienste, die es umgehen	journalctl -u NAME --since "1 hour ago"
Linux mit rsyslog	Textdateien unter /var/log (syslog unter Debian/Ubuntu, messages unter RHEL; Dateien pro Facility werden in /etc/rsyslog.conf und /etc/rsyslog.d festgelegt)	grep, less; auf systemd-Hosts erhält rsyslog seine Meldungen in der Regel vom Journal, daher sieht auch journalctl sie
macOS	das Unified Log, ein binärer Speicher, der nicht als einfache Dateien sichtbar ist	log show --predicate 'process == "NAME"' --last 1h oder log stream, um live mitzuverfolgen
Windows	die Kanäle des Event-Log-Dienstes (Application, System, Security sowie Kanäle einzelner Anwendungen)	Get-WinEvent -FilterHashtable @{LogName='Application'; StartTime=(Get-Date).AddHours(-1)} (-LogName und -FilterHashtable lassen sich nicht kombinieren)
AIX	das binäre Error Log (Hardware- und Softwarefehler) und, davon getrennt, syslog, sofern konfiguriert	errpt für das Error Log; für syslog die in /etc/syslog.conf genannte Datei mit tail -f verfolgen (die Standarddatei enthält keine aktiven Regeln)
FreeBSD	Textdateien unter /var/log, rotiert durch newsyslog, geleitet über /etc/syslog.conf	grep, less oder tail -f /var/log/messages

Warum es wichtig ist

Die binären Speicher (das systemd-Journal, das Unified Log von macOS, das Windows Event Log, das Error Log von AIX) lassen sich nicht mit grep lesen. Jeder braucht ein eigenes Abfragewerkzeug, und jedes Werkzeug hat eine eigene Filtersyntax: einen Unit-Namen unter Linux, einen Prädikatsausdruck unter macOS, eine Filter-Hashtable oder XPath unter Windows. Logging in Textdateien (reines rsyslog, FreeBSD, der Grossteil der AIX-Anwendungslogs) ist mit jedem Textwerkzeug nutzbar, verliert aber die strukturierten Felder der binären Speicher, etwa die Boot-ID des Prozesses oder die genaue Kombination aus Facility und Severity.

So wird es angewendet

• Vor dem Formulieren einer Abfrage den Speicher bestimmen: journalctl -u für eine Service-Unit und tail für eine einfache Datei sind nicht austauschbar. Wird der falsche Befehl auf dem falschen System ausgeführt, liefert er stillschweigend nichts statt eines Fehlers.
• Jede Abfrage zuerst zeitlich eingrenzen (--since, --last, -FilterHashtable @{StartTime=...}) und erst danach nach Inhalt. Unbegrenzte Log-Abfragen sind die häufigste Ursache dafür, dass ein Agent-Skript hängen bleibt oder seine eigene Ausgabe überflutet.
• Unter macOS müssen log show und log stream aus einem Admin-Konto oder mit sudo laufen; Meldungsargumente, die als privat markiert sind, erscheinen in beiden Fällen als <private>. Dies ist bei unbeaufsichtigten Skripten einzuplanen.
• Unter Windows Get-WinEvent verwenden, nicht das ältere Get-EventLog: Nur das erstere liest die Kanäle einzelner Anwendungen, und Get-EventLog existiert in PowerShell 7 nicht.

Stolpersteine

• Annehmen, errpt von AIX sei ein allgemeines Anwendungslog. Es ist ein Error Log für Hardware- und Softwarefehler, kein Ort, an den die meisten Daemons von Drittanbietern ihre Routinemeldungen schreiben.
• Auf einem systemd-Host nur /var/log/syslog lesen: Ab Debian 12 wird rsyslog nicht mehr standardmässig installiert, die Datei existiert daher unter Umständen nicht, und das Journal ist der einzige Speicher.
• Das Windows-Security-Log aus einer Sitzung ohne erhöhte Rechte abfragen: Das Lesen erfordert Administratorrechte, und das Skript erhält einen Zugriff-verweigert-Fehler statt eines leeren Ergebnisses.