Tail unter Linux: Überwachung eines Live-Logs, ohne den Befehl alle zehn Sekunden erneut auszuführen

Wenn ein Linux-Dienst nicht mehr reagiert oder eine Anwendung Fehler erzeugt, wird es schnell mühsam, alle zehn Sekunden denselben Befehl auszuführen. Genau in solchen Situationen ist es angebracht, Schwanz Es bietet einen Service: Man zeigt die letzten Zeilen einer Datei an und kann dann live verfolgen, was passiert.

Ich nutze es hauptsächlich, um Protokolle bei einem Neustart eines Dienstes, einer SSH-Verbindung, einem Nginx-Fehler oder beim Schreiben eines Skripts in eine Datei zu überprüfen. Es ist kein magisches Diagnosewerkzeug, aber oft der schnellste Weg, um festzustellen, ob überhaupt etwas passiert.

Welchen Zweck hat tail unter Linux?

Die Bestellung Schwanz Zeigt das Ende einer Datei an. Ohne Optionen werden die letzten zehn Zeilen angezeigt:

tail /var/log/syslog

Unter Debian oder Ubuntu können Sie je nach Konfiguration auch auf Dateien wie diese stoßen. /var/log/auth.log, /var/log/nginx/error.log oder Anwendungsprotokolle, die in /var/log/service-name/.

Als Erstes sollten Sie überprüfen, ob die Datei existiert und ob Sie die Berechtigung haben, sie zu lesen.

ls -lh /var/log/syslog
sudo tail /var/log/syslog

Wenn der Befehl keine Ausgabe liefert, ist das nicht unbedingt ein Fehler. Die Datei könnte leer sein, in Ihrer Distribution fehlen oder durch das Systemd-Protokoll ersetzt worden sein.

Mit tail -n können Sie mehr oder weniger Zeilen anzeigen.

Standardmäßig reichen zehn Zeilen selten aus, wenn man versucht, einen Fehler zu verstehen. -NSie wählen die Anzahl der anzuzeigenden Zeilen:

tail -n 50 /var/log/syslog
sudo tail -n 100 /var/log/nginx/error.log

Ich rate Ihnen, mit 50 oder 100 Zeilen zu beginnen. Wenn Sie 5000 Zeilen anfordern, verlieren Sie den Vorteil von `tail` und es wäre manchmal besser, die Datei mit einem anderen Befehl zu öffnen. weniger oder direkt filtern.

Bei einer sehr ausführlichen Datei können Sie auch tail mit grep :

sudo tail -n 200 /var/log/syslog | grep -i "error"

Aber Vorsicht: Zu frühes Filtern kann dazu führen, dass man die Nachricht kurz vor dem Fehler verpasst. Wenn ich noch nicht weiß, wonach ich suche, lese ich zuerst die Rohdaten.

Verfolge ein Live-Log mit tail -f

Die nützlichste Option ist -FEs hält den Befehl geöffnet und zeigt neue Zeilen an, sobald sie in die Datei geschrieben werden:

sudo tail -f /var/log/syslog

Anschließend können Sie ein zweites Terminal öffnen, Ihren Dienst neu starten, die problematische Verbindung wiederherstellen oder den Fehler in der Anwendung reproduzieren. Neue Zeilen werden fortlaufend hinzugefügt.

sudo systemctl restart nginx
sudo tail -f /var/log/nginx/error.log

Um die Nachverfolgung zu beenden, verwenden Sie einfach Strg + CSchließen Sie Ihre SSH-Sitzung nicht abrupt, wenn Sie mit einem Remote-Server verbunden sind, insbesondere wenn Sie gerade dabei sind, einen wichtigen Dienst zu reparieren.

Es gibt auch Schwanz -Fmit einem großen F. Diese Option folgt dem Dateinamen und ist weniger anfällig für Protokollrotationen. Dies ist nützlich, wenn die Datei von einem anderen System neu erstellt werden kann. logrotieren während Ihrer Diagnose.

sudo tail -F /var/log/nginx/error.log

Filtern Sie während der Wiedergabe, ohne den Live-Feed zu verlieren.

Sie können eine Datei verfolgen und gleichzeitig filtern. So suchen Sie nach einem bestimmten Fehler:

sudo tail -f /var/log/syslog | grep --line-buffered -i "failed"

Die Option --zeilengepuffert verhindert grep Es hält Zeilen zu lange in der Warteschlange. Ohne diese Funktion könnte man meinen, es passiere nichts, obwohl der Filter die Anzeige tatsächlich blockiert.

Für einfache Diagnosen öffne ich oft zwei Terminals: eines mit dem vollständigen Protokoll und ein weiteres mit dem Filter. So vermeide ich, eine Warnung zu verpassen, die nicht das exakte gesuchte Wort enthält.

Wann ist journalctl tail vorzuziehen?

Bei neueren Distributionen mit systemd wird eine Menge Information durchgereicht. JournalctlWenn Sie nach Protokollen eines systemd-Dienstes suchen, ist journalctl oft übersichtlicher als tail, um eine Datei zu überwachen. /var/log.

sudo journalctl -u ssh -n 50
sudo journalctl -u ssh -f

Mit -uSie zielen auf eine systemd-Unit ab. -n 50Es werden die letzten 50 Zeilen angezeigt. -FSie verfolgen die Nachrichten live, genau wie bei Tails.

Wenn Sie einen Dienst neu starten, können Sie daher die beiden Ansätze kombinieren:

sudo systemctl restart ssh
sudo systemctl status ssh --no-pager
sudo journalctl -u ssh -f

Ich verwende `tail` meist dann, wenn ich genau weiß, welche Anwendungsdatei ich überwachen möchte. Für einen systemd-Dienst, einen Bootvorgang oder einen Startfehler nutze ich in der Regel `journalctl`. Weitere Informationen dazu finden Sie im Artikel unter [Link einfügen]. journalctl und die Protokolle vom letzten Start Dieser Auftrag wird einwandfrei ausgeführt.

Häufige Fehler mit dem Schwanz

Der erste Fehler besteht darin, die falsche Datei zu verwenden. Bevor Sie sich in einem unübersichtlichen Protokoll verstricken, überprüfen Sie den Dienst und die geöffneten Dateien:

systemctl status nginx --no-pager
sudo journalctl -u nginx -n 50
sudo ls -lh /var/log/nginx/

Zweiter Fehler: Vergessen der Berechtigungen. Auf einem Server benötigen viele Protokolldateien Berechtigungen. SudoWenn Sie eine Nachricht haben Zugriff verweigertÄndern Sie die Dateiberechtigungen nicht willkürlich. Starten Sie stattdessen den Lesevorgang mit sudo neu.

Dritter Fehler: die Verwechslung des Fehlens von Protokollen mit dem Fehlen eines Problems. Eine Anwendung kann an anderer Stelle protokollieren, ihre Protokolle an systemd senden oder nur bestimmte Fehlerstufen protokollieren.

Um den Serverstatus umfassender zu überprüfen, können Sie auch mithilfe von systemd nach fehlerhaften Diensten suchen:

systemctl --fehlgeschlagen
systemctl list-jobs

Wenn das Problem einen Netzwerkport oder einen Dienst betrifft, der nicht mehr erreichbar ist, siehe den Artikel über netstat, ss und offene Ports unter Linux kann Ihnen auch dabei helfen, zu überprüfen, was tatsächlich ausgestellt ist.

Eine einfache Methode zur Diagnose, ohne vom Thema abzuschweifen.

Wenn ich einen Dienst überprüfen muss, der gerade ausgefallen ist, verwende ich eine Kurzmethode:

• den betreffenden Dienst oder die betreffende Protokolldatei identifizieren;
• Zeigen Sie die letzten Zeilen an mit tail -n 50 Oder journalctl -n 50 ;
• Beginnen Sie mit der Verfolgung Schwanz -f, Schwanz -F Oder journalctl -f ;
• Die problematische Aktion reproduzieren;
• Notieren Sie sich den genauen Zeitpunkt und die Meldung, bevor Sie die Konfiguration ändern.

Dieser letzte Punkt verhindert planloses Herumprobieren. Ein Blick ins Protokoll zum richtigen Zeitpunkt ist besser als drei Neustarts, ohne zu verstehen, was gerade passiert ist.

Als Referenzdokumentation können Sie die GNU Coreutils-Seite konsultieren. Schwanz und die systemd-Seite auf Journalctl.

sudo apt update && sudo apt upgrade