Tail onder Linux: een live log monitoren zonder het commando elke tien seconden opnieuw uit te voeren.

Wanneer een Linux-service niet meer reageert of een applicatie fouten begint te genereren, wordt het al snel vervelend om elke tien seconden hetzelfde commando uit te voeren. Dit is precies het soort situatie waarin staart Het biedt een service: je toont de laatste regels van een bestand, waarna je live kunt volgen wat er gebeurt.

Ik gebruik het vooral om logbestanden te controleren tijdens een herstart van een service, een SSH-verbinding, een Nginx-fout of wanneer een script naar een bestand schrijft. Het is geen magische diagnostische tool, maar het is vaak de snelste manier om te zien of er daadwerkelijk iets gebeurt.

Wat is het doel van `tail` onder Linux?

De bestelling staart Geeft het einde van een bestand weer. Zonder opties worden de laatste tien regels getoond:

tail /var/log/syslog

Op Debian of Ubuntu, afhankelijk van je configuratie, kun je ook bestanden tegenkomen zoals /var/log/auth.log, /var/log/nginx/error.log of toepassingslogboeken die zijn geplaatst in /var/log/service-naam/.

Voordat u verdergaat, moet u eerst controleren of het bestand bestaat en of u de juiste leesrechten hebt.

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

Als de opdracht geen resultaat oplevert, hoeft dat niet per se een fout te zijn. Het bestand kan leeg zijn, ontbreken in uw distributie of vervangen zijn door het systemd-logbestand.

Geef meer of minder regels weer met de optie -n

Standaard zijn tien regels zelden voldoende als je een fout probeert te begrijpen. -NU kiest het aantal weer te geven regels:

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

Ik raad je aan om te beginnen met 50 of 100 regels. Als je 5000 regels opvraagt, verlies je het voordeel van `tail` en kun je het bestand soms beter openen met minder of om direct te filteren.

Voor een zeer uitgebreid bestand kun je tail ook combineren met grep :

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

Wees echter voorzichtig: te vroeg filteren kan ervoor zorgen dat je het bericht vlak voor de fout mist. Als ik nog niet weet waar ik naar moet zoeken, lees ik eerst de onbewerkte regels.

Volg een live logboek met tail -f

De meest bruikbare optie is -FHet houdt de opdracht open en toont nieuwe regels zodra ze in het bestand worden geschreven:

sudo tail -f /var/log/syslog

Je kunt dan een tweede terminal openen, je service opnieuw starten, de problematische verbinding herstellen of de fout in de applicatie reproduceren. Nieuwe regels worden toegevoegd zodra ze verwerkt zijn.

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

Om de tracking te stoppen, gebruikt u eenvoudigweg de volgende opdracht: Ctrl + CSluit uw SSH-sessie niet abrupt af als u verbonden bent met een externe server, vooral niet als u bezig bent met het herstellen van een belangrijke service.

Er is ook staart -Fmet een hoofdletter F. Deze optie volgt de bestandsnaam en is beter bestand tegen logrotatie. Dit is handig wanneer het bestand opnieuw kan worden aangemaakt door logroteren tijdens uw diagnose.

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

Filter tijdens het kijken zonder de livestream te verliezen.

Je kunt een bestand volgen en tegelijkertijd filteren. Om naar een specifieke fout te zoeken:

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

De optie --regelgebufferd verhindert grep Het zorgt ervoor dat regels te lang in de wachtstand blijven staan. Zonder dit filter zou je kunnen denken dat er niets gebeurt, terwijl het filter in werkelijkheid het scherm blokkeert.

Voor eenvoudige diagnoses open ik vaak liever twee terminals: één met het volledige logbestand en één met het filter. Zo voorkom ik dat ik een waarschuwing mis die niet precies het woord bevat waarnaar ik zoek.

Wanneer is journalctl te verkiezen boven tail?

Bij recente distributies met systemd wordt er veel informatie verwerkt. journaalctlAls je op zoek bent naar logbestanden van een systemd-service, is journalctl vaak overzichtelijker dan tail op een bestand. /var/log.

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

Met -uJe richt je op een systemd-eenheid. Met -n 50Je toont de laatste 50 regels. Met -FJe volgt het nieuws live, net als bij Tails.

Als u een service opnieuw opstart, kunt u de twee benaderingen dus combineren:

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

Ik gebruik `tail` meestal als ik precies weet welk applicatiebestand ik moet monitoren. Voor een systemd-service, een opstartproces of een opstartfout gebruik ik meestal `journalctl`. Als je hier dieper op in wilt gaan, lees dan het artikel over journalctl en de logbestanden van de laatste opstart Deze bestelling is perfect afgerond.

Veel voorkomende fouten met staart

De eerste fout is het volgen van het verkeerde bestand. Voordat je vast komt te zitten met het staren naar een stil logbestand, controleer eerst de service en de geopende bestanden:

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

Tweede fout: het vergeten van de machtigingen. Op een server vereisen veel logbestanden toegang. sudoAls u een bericht heeft Toestemming geweigerdWijzig de bestandsrechten niet willekeurig. Start in plaats daarvan de leesbewerking opnieuw met sudo.

Derde fout: het verwarren van de afwezigheid van logbestanden met de afwezigheid van een probleem. Een applicatie kan elders schrijven, zijn logbestanden naar systemd sturen of alleen bepaalde foutniveaus loggen.

Om de status van de server in bredere zin te controleren, kunt u ook de falende services bekijken met behulp van systemd:

systemctl --failed
systemctl list-jobs

Als het probleem betrekking heeft op een netwerkpoort of een service die niet meer actief is, raadpleeg dan het artikel over netstat, ss en open poorten onder Linux Kan u ook helpen te controleren wat er daadwerkelijk wordt weergegeven.

Een eenvoudige methode voor diagnose zonder afleiding.

Als ik een service moet controleren die net is uitgevallen, gebruik ik een korte methode:

• Identificeer de betreffende service of het betreffende logbestand;
• toon de laatste paar regels met staart -n 50 Of journalctl -n 50 ;
• begin met volgen staart -f, staart -F Of journalctl -f ;
• reproduceer de problematische handeling;
• Noteer de exacte tijd en het bericht voordat u de configuratie wijzigt.

Dit laatste punt voorkomt dat je zomaar wat aan het prutsen bent. Het logbestand op het juiste moment uitlezen is beter dan drie keer opnieuw opstarten zonder te begrijpen wat er precies is gebeurd.

Voor referentiedocumentatie kunt u de GNU Coreutils-pagina raadplegen op staart en de systemd-pagina op journaalctl.

sudo apt update && sudo apt upgrade