translated_content> Grep unter Linux: einen Fehler in den Protokollen finden

Ein cat /var/log/syslog auf einem aktiven Server zeigt vor allem eine Sache: zu viele Zeilen. Wenn ein Dienst ausfällt oder ein Fehler auftritt, suchen Sie zuerst nach dem Namen des Dienstes, der Uhrzeit und der genauen Meldung. grep hilft dabei, den Lärm zu reduzieren, ohne die Zeilen zu verlieren, die erklären, was kurz zuvor passiert ist.

Diese Methode funktioniert bei einer Datei im /var/log genauso wie bei der Ausgabe von journalctl. Sie ersetzt nicht das vollständige Protokoll: Sie dient dazu, einen zuverlässigen Ausgangspunkt zu finden und dann diesen Punkt zu erweitern.

Mit einer lesbaren Suche beginnen

Fügen Sie die Zeilennummern hinzu und ignorieren Sie die Groß- und Kleinschreibung, wenn das Programm Error, ERROR oder error vermischt:

grep -n -i 'error' /var/log/mein-dienst.log

-n zeigt die Zeilennummer an. Es wird nützlich, wenn Sie die Datei in less öffnen, zwei Suchen vergleichen oder den Auszug in ein Ticket kopieren müssen. Die Apostrophe verhindern, dass die Shell spezielle Zeichen im Muster interpretiert. Das Handbuch von grep erklärt die Such- und Kontextoptionen im Detail.

• -i sucht ohne Unterscheidung zwischen Groß- und Kleinschreibung.
• -n fügt die Zeilennummer hinzu.
• -F behandelt den Text als literale Zeichenfolge, nützlich für einen Fehler, der ., [ oder ? enthält.
• -E aktiviert erweiterte reguläre Ausdrücke.
• -C 3 zeigt drei Zeilen vor und nach jeder Übereinstimmung an.

Für einen genauen Fehler ziehen Sie -F vor. Eine IP-Adresse, ein Pfad oder eine Nachricht mit eckigen Klammern kann sonst als regulärer Ausdruck interpretiert werden:

grep -n -F 'connection refused [127.0.0.1:5432]' /var/log/mein-dienst.log

Die Zeilen beibehalten, die den Fehler erklären

Eine mit ERROR gekennzeichnete Zeile zeigt selten allein die Ursache an. Zeigen Sie den Kontext an, bevor Sie Schlussfolgerungen ziehen:

grep -n -i -C 3 'error' /var/log/mein-dienst.log

grep -n -i -A 5 'failed' /var/log/mein-dienst.log

grep -n -i -B 5 'panic' /var/log/mein-dienst.log

-C 3 behält drei Zeilen auf jeder Seite. -A zeigt nur die nachfolgenden Zeilen an, -B nur die vorhergehenden. Wenn mehrere Fehler weit auseinanderliegen, trennt grep die Gruppen durch --. Dieser Separator ist kein Bestandteil des Protokolls.

Wenn Sie mehrere Symptome kennen, fügen Sie diese mit -E zusammen:

grep -n -i -E 'error|failed|timeout|refused' /var/log/mein-dienst.log

Dieser Befehl gibt auch Meldungen zurück, die nicht unbedingt mit Ihrem Vorfall zu tun haben. Fügen Sie dann den Prozessnamen, den Port oder die Anforderungs-ID hinzu, anstatt die Liste der Schlüsselwörter willkürlich zu verlängern.

journalctl filtern, bevor grep ausgeführt wird

Mit systemd beginnen Sie damit, das Protokoll auf die Einheit und den Zeitraum des Vorfalls zu beschränken. So vermeiden Sie, dass Nachrichten anderer Dienste vermischt werden:

journalctl -u nginx --since 'vor 30 Minuten' --no-pager
journalctl -u nginx --since 'vor 30 Minuten' --no-pager | grep -n -i -C 2 'error'

Ersetzen Sie nginx durch den tatsächlichen Namen der Einheit, z. B. postgresql, docker oder Ihren Anwendungsdienst. Wenn der Vorfall auf einen Neustart folgt, fügen Sie -b hinzu, um beim aktuellen Neustart zu bleiben. Das Handbuch von journalctl beschreibt auch die Filter nach Einheit und Zeitraum. Unser Leitfaden über journalctl und die Protokolle des letzten Neustarts erläutert diesen Filter im Detail.

Starten Sie keine Suche über mehrere Jahre Protokolle, bevor Sie die Uhrzeit des Problems eingegrenzt haben. Ein Fehler um 14:12 Uhr verdient ein kurzes Fenster um 14:12 Uhr, gefolgt von einer breiteren Durchsicht, falls keine Ursache erscheint.

Den Dienst während der Reproduktion verfolgen

Für ein reproduzierbares Problem öffnen Sie ein zweites Terminal und sehen sich nur die neuen Zeilen an:

journalctl -fu nginx

tail -F /var/log/nginx/error.log | grep --line-buffered -i -E 'error|warn|failed'

journalctl -f verfolgt das Protokoll live. tail -F läuft auch weiter nach einer Dateirotation, was sicherer ist als tail -f bei vielen Anwendungsprotokollen. Die Option --line-buffered behält den Stream nach dem Pipe zu grep lesbar.

Führen Sie dann die fehlgeschlagene Aktion nur einmal aus: eine HTTP-Anfrage, einen kontrollierten Neustart oder eine Testverbindung. Wenn Sie mehrere Tests gleichzeitig starten, wissen Sie nicht mehr, welche Zeile zu welchem Versuch gehört. Um eine klassische Datei zu verfolgen, können Sie auch unsere Methode mit tail konsultieren.

Wenn Sie einen Fehler gefunden haben, notieren Sie sich die Uhrzeit, die betroffene Einheit oder den Prozess und die umgebenden Zeilen. Das ist nützlicher als ein Copy-Paste von tausend Zeilen Protokollen und verhindert, dass Sie eine Konfiguration ändern, bevor Sie den fehlerhaften Dienst identifiziert haben.

n

sudo apt update && sudo apt upgrade