Anfängerleitfaden für Syslogs unter Linux

Jahrzehntelang wurde die Linux-Protokollierung vom syslogd-Daemon verwaltet.

Syslogd würde die Protokollmeldungen sammeln, die das System verarbeitet und Anwendungen an das /dev/log-Pseudogerät senden. Dann würde es die Meldungen an die entsprechenden Nur-Text-Protokolldateien im /var/log/-Verzeichnis weiterleiten.

Syslogd würde wissen, wohin die Nachrichten gesendet werden sollen, da jede Kopfzeile Metadatenfelder enthält (einschließlich eines Zeitstempels und des Nachrichtenursprungs und der Nachrichtenpriorität).

Im Gefolge des unerbittlichen, welterobernden Molochs von systemd wird die Linux-Protokollierung nun auch von journald übernommen. Ich sage auch, weil syslogd nirgendwo hingegangen ist und Sie die meisten seiner traditionellen Protokolldateien immer noch in /var/log/ finden können. Aber Sie müssen sich darüber im Klaren sein, dass es einen neuen Sheriff in der Stadt gibt, dessen (Befehlszeilen-)Name Journalctl lautet.

Aber in diesem Artikel geht es nicht um journald. Der Fokus liegt hier auf systemd, also lassen Sie uns ein bisschen mehr ausgraben.

Protokollierung mit syslogd

Alle Protokolle, die von Ereignissen auf einem syslogd-System generiert werden, werden der Datei /var/log/syslog hinzugefügt. Abhängig von ihren Identifizierungsmerkmalen können sie jedoch auch an eine oder mehrere andere Dateien im selben Verzeichnis gesendet werden.

Bei syslogd wird die Art und Weise, wie Nachrichten verteilt werden, durch den Inhalt der 50-default.conf bestimmt Datei, die sich in /etc/rsyslog.d/ befindet Verzeichnis.

Dieses Beispiel aus 50-default.conf zeigt, wie als cron-bezogen gekennzeichnete Protokollmeldungen in die Datei cron.log geschrieben werden. In diesem Fall weist das Sternchen (*) syslogd an, Einträge mit einer beliebigen Prioritätsstufe zu senden (im Gegensatz zu einer einzelnen Stufe wie emerg oder err):

cron.*     /var/log/cron.log

Das Arbeiten mit syslogd-Protokolldateien erfordert keine speziellen Tools wie journalctl. Aber wenn Sie darin gut werden wollen, müssen Sie wissen, welche Art von Informationen in jeder der Standardprotokolldateien gespeichert sind.

Die folgende Tabelle listet die häufigsten syslogd-Protokolldateien und
ihre Zwecke.

Dateiname	Zweck
auth.log	Systemauthentifizierung und Sicherheitsereignisse
boot.log	Eine Aufzeichnung von Boot-bezogenen Ereignissen
dmesg	Kernel-Ring-Pufferereignisse im Zusammenhang mit Gerätetreibern
dpkg.log	Ereignisse zur Verwaltung von Softwarepaketen
kern.log	Linux-Kernel-Ereignisse
syslog	Eine Sammlung aller Protokolle
wtmp	Verfolgt Benutzersitzungen (Zugriff über die Befehle who und last)

Darüber hinaus schreiben einzelne Anwendungen manchmal in ihre eigenen Protokolldateien. Oft sehen Sie auch ganze Verzeichnisse wie /var/log/apache2/ oder /var/log/mysql/, die erstellt wurden, um Anwendungsdaten zu erhalten.

Die Protokollumleitung kann auch über eine von acht Prioritätsstufen gesteuert werden, zusätzlich zu dem *-Symbol (für alle Prioritätsstufen), das Sie zuvor gesehen haben.

Ebene	Beschreibung
debuggen	Hilfreich beim Debuggen
Informationen	Information
Hinweis	Normale Bedingungen
warnen	Bedingungen, die Warnungen erfordern
irr	Fehlerbedingungen
kritisch	Kritische Bedingungen
Warnung	Sofortiges Handeln erforderlich
auftauchen	System unbrauchbar

Protokolldateien mit sysglogd verwalten

Standardmäßig verarbeitet syslogd Protokollrotation, -komprimierung und -löschung hinter den Kulissen ohne Ihre Hilfe. Aber Sie sollten wissen, wie es gemacht wird, falls Sie jemals Protokolle haben, die einer besonderen Behandlung bedürfen.

Welche Art von Sonderbehandlung könnte ein einfacher Baumstamm jemals erfordern? Angenommen, Ihr Unternehmen muss die Transaktionsberichterstattungsregeln einhalten, die mit regulatorischen oder Branchenstandards wie Sarbanes-Oxley oder PCI-DSS verbunden sind. Wenn Ihre IT-Infrastrukturaufzeichnungen für längere Zeit zugänglich bleiben müssen, dann möchten Sie das auf jeden Fall
um zu wissen, wie man sich in den Schlüsseldateien zurechtfindet.

Um das Logrotate-System in Aktion zu sehen, listen Sie einige Inhalte des Verzeichnisses /var/log/ auf. Die Datei auth.log beispielsweise erscheint in drei verschiedenen Formaten:

• auth.log - Die derzeit aktive Version, in die neue Authentifizierungsnachrichten geschrieben werden.
• auth.log.1 - Die letzte Datei, die außer Betrieb rotiert wurde. Es wird im unkomprimierten Format verwaltet, um es einfacher zu machen, es schnell wieder in Aktion zu setzen, falls es nötig sein sollte.
• auth.log.2.gz - Eine ältere Sammlung (wie Sie anhand der Dateierweiterung .gz in der folgenden Auflistung sehen können), die komprimiert wurde, um Platz zu sparen.

Nach sieben Tagen, wenn das nächste Rotationsdatum eintrifft, wird auth.log.2.gz in auth.log.3.gz umbenannt, auth.log.1 wird komprimiert und in auth.log.2.gz, auth.log umbenannt wird zu auth.log.1, und eine neue Datei wird erstellt und erhält den Namen auth.log.

Der standardmäßige Protokollrotationszyklus wird in der Datei /etc/logrotate.conf gesteuert. Die in dieser Auflistung dargestellten Werte rotieren Dateien nach einer einzigen aktiven Woche und löschen alte Dateien nach vier Wochen.

# rotate log files weekly
weekly
# keep 4 weeks worth of backlogs
rotate 4
# create new (empty) log files after rotating old ones
create
# packages drop log rotation information into this directory
include /etc/logrotate.

Das Verzeichnis /etc/logrotate.d/ enthält auch angepasste Konfigurationsdateien zum Verwalten der Protokollrotation einzelner Dienste oder Anwendungen. Wenn Sie den Inhalt dieses Verzeichnisses auflisten, sehen Sie diese Konfigurationsdateien:

$ ls /etc/logrotate.d/
apache2 apt dpkg mysql-server
rsyslog
samba
unattended-upgrade

Sie können ihren Inhalt anzeigen, um zu sehen, welche Art von Konfiguration sie bei der Protokollrotation haben.

💡Viele Administratoren entscheiden sich dafür, Protokolleinträge auf speziell entwickelte Remote-Protokollserver umzuleiten, wo die Daten die ganze spezielle Aufmerksamkeit erhalten, die sie verdienen. Dadurch können Anwendungsserver für ihre unmittelbaren Aufgaben entlastet und Protokolldaten an einem einzigen, leicht zugänglichen zentralen Ort konsolidiert werden.

So lesen Sie die Syslog-Dateien

Sie wissen, dass Sie mit Ihrer Zeit Besseres anzufangen haben, als Millionen von Zeilen mit Protokolleinträgen zu lesen.

Auf den Einsatz von cat sollte hier gänzlich verzichtet werden. Es wird einfach Tausende von Zeilen auf Ihrem Bildschirm ausgeben.

Ich schlage vor, grep zu verwenden, um Text durch die Dateien zu filtern.

Mit dem Befehl tail -f können Sie die aktuelle Protokolldatei in Echtzeit lesen. Sie können es mit grep kombinieren, um nach gewünschtem Text zu filtern.

In einigen Fällen müssen Sie möglicherweise auf die alten, komprimierten Protokolle zugreifen. Sie können die Datei immer zuerst extrahieren und dann grep, less und andere Befehle verwenden, um ihren Inhalt zu lesen, es gibt jedoch eine bessere Option. Es gibt z-Befehle wie zcat, zless usw., mit denen Sie an den komprimierten Dateien arbeiten können, ohne sie explizit zu extrahieren.

Ein praktisches Beispiel für die Protokollanalyse

Hier ist ein offensichtliches Beispiel, das die Datei auth.log nach Hinweisen auf fehlgeschlagene Anmeldeversuche durchsucht. Suche nach dem Wort Scheitern wird
Gibt eine beliebige Zeile zurück, die den Ausdruck Authentifizierungsfehler enthält.

Wenn Sie dies von Zeit zu Zeit überprüfen, können Sie Versuche erkennen, ein Konto zu kompromittieren, indem Sie das richtige Passwort erraten. Jeder kann ein oder zwei Mal ein Passwort vermasseln, aber zu viele Fehlversuche sollten Sie misstrauisch machen:

$ cat /var/log/auth.log | grep 'Authentication failure'
Sep 6 09:22:21 workstation su[21153]: pam_authenticate: Authentication failure

Wenn Sie die Art von Administrator sind, die niemals Fehler macht, wird diese Suche möglicherweise leer bleiben. Sie können sich mindestens ein Ergebnis garantieren, indem Sie mit einem Programm namens Logger manuell einen Protokolleintrag erstellen. Probieren Sie es so aus:

logger "Authentication failure"

Sie können einen echten Fehler auch im Voraus aussäen, indem Sie sich bei einem Benutzerkonto anmelden und das falsche Passwort eingeben.

Wie Sie sehen, hat grep die Arbeit für Sie erledigt, aber alles, was Sie den Ergebnissen entnehmen können, ist, dass ein Authentifizierungsfehler aufgetreten ist. Wäre es nicht hilfreich zu wissen, um wessen Konto es sich handelt? Sie können die Ergebnisse von grep erweitern, indem Sie ihm sagen, dass es die Zeilen unmittelbar vor und nach der Übereinstimmung einbeziehen soll.

Dieses Beispiel druckt die Übereinstimmung zusammen mit den Linien darum herum. Es teilt Ihnen mit, dass jemand, der das Konto david verwendet, erfolglos versucht hat, sich mit su (Benutzer wechseln) beim Studio-Konto anzumelden:

$ cat /var/log/auth.log | grep -C1 failure
Sep 6 09:22:19 workstation su[21153]: pam_unix(su:auth): authentication
failure; logname= uid=1000 euid=0 tty=/dev/pts/4 ruser=david rhost=
user=studio
Sep 6 09:22:21 workstation su[21153]: pam_authenticate:
Authentication failure
Sep 6 09:22:21 workstation su[21153]: FAILED su for studio by david

Was kommt als Nächstes?

Die Grundlagen zu kennen ist eine Sache, das Wissen anzuwenden ist eine andere Sache. Die Kenntnis der Grundlagen hilft jedoch in verschiedenen Situationen.

Jetzt, da Sie die Grundlagen von Syslogs in Linux kennen, haben Sie vielleicht eine etwas bessere Zeit beim Umgang mit Protokollen.

Dieser Artikel ist ein Auszug aus dem Buch Linux in Action von David Clinton. Es wird von Manning Publication herausgegeben und Sie können 30 % Rabatt erhalten auf allen Manning-Büchern mit dem Code nlitsfoss22 an der Kasse.

Linux im Action-Buch

Viel Spaß beim Lernen von Linux.