Grep onder Linux: een fout vinden in de logbestanden

Een cat /var/log/syslog op een actieve server geeft vooral één ding: te veel regels. Wanneer een service crasht of een fout terugkomt, zoek eerst naar de naam van de service, het tijdstip en het specifieke bericht. grep helpt om het lawaai te verminderen zonder de regels te verliezen die uitleggen wat er net voor gebeurde.

Deze methode werkt op een bestand onder /var/log net zo goed als op de uitvoer van journalctl. Het vervangt niet het volledige logboek: het dient om een betrouwbare startpunt te vinden en vervolgens rondom dat punt uit te breiden.

Tux zoekt een specifieke fout in Linux-logs met een vergrootglas — Zoek een specifieke fout en lees vervolgens de omliggende regels opnieuw.

Begin met een leesbare zoekopdracht

Voeg de regelnummers toe en negeer de hoofdletters als het programma Error, ERROR of error door elkaar haalt:

grep -n -i 'error' /var/log/mon-service.log

-n toont het regelnummmer. Het wordt nuttig wanneer je het bestand weer in less moet oppakken, twee zoekopdrachten moet vergelijken of het fragment in een ticket moet kopiëren. De aanhalingstekens voorkomen dat de shell speciale tekens in het patroon interpreteert. De grep-handleiding beschrijft de zoekopties en context.

-i zoekt zonder onderscheid tussen hoofdletters en kleine letters.
-n voegt het regelnummmer toe.
-F behandelt de tekst als een letterlijke string, handig voor een fout die ., [ of ? bevat.
-E activeert uitgebreide reguliere expressies.
-C 3 toont drie regels voor en na elke match.

Voor een exacte fout, geef de voorkeur aan -F. Een IP-adres, een pad of een bericht met haakjes kan anders worden geïnterpreteerd als een reguliere expressie:

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

Behoud de regels die de fout uitleggen

Een gemarkeerde regel met ERROR geeft zelden de oorzaak alleen aan. Toon de context voordat je conclusies trekt:

grep -n -i -C 3 'error' /var/log/mon-service.log

grep -n -i -A 5 'failed' /var/log/mon-service.log

grep -n -i -B 5 'panic' /var/log/mon-service.log

-C 3 behoudt drie regels aan elke kant. -A toont alleen de volgende regels, -B alleen de voorgaande. Als er meerdere fouten op afstand zijn, scheidt grep de groepen met --. Deze scheidingstekens maken geen deel uit van het logboek.

Wanneer je meerdere symptomen kent, combineer ze dan met -E:

grep -n -i -E 'error|failed|timeout|refused' /var/log/mon-service.log

Deze opdracht retourneert ook berichten die niet noodzakelijkerwijs met jouw incident te maken hebben. Voeg daarna de naam van het proces, de poort of het verzoek-ID toe in plaats van willekeurig de lijst met zoektermen te verlengen.

Filter journalctl voordat je grep gebruikt

Met systemd, begin met het beperken van het logboek tot de eenheid en de periode van het incident. Dit voorkomt dat je berichten van andere services door elkaar haalt:

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

Vervang nginx door de echte naam van de eenheid, bijvoorbeeld postgresql, docker of jouw applicatieservice. Als het incident volgt op een herstart, voeg dan -b toe om bij de huidige opstart te blijven. De journalctl-handleiding beschrijft ook de filters per eenheid en periode. Onze gids over journalctl en de logs van de laatste opstart gaat verder in op deze filter.

Voer geen zoekopdracht over jaren van logs uit voordat je de tijd van het probleem heeft beperkt. Een fout die om 14:12 werd gezien, verdient een korte tijdspanne rondom 14:12, en vervolgens een bredere lezing als er geen oorzaak zichtbaar is.

Volg de service tijdens het reproduceren

Voor een reproduceerbaar probleem, open een tweede terminal en kijk alleen naar de nieuwe regels:

journalctl -fu nginx

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

journalctl -f volgt het logboek in real-time. tail -F gaat ook door na een bestandrotatie, wat veiliger is dan tail -f op veel applicatielogs. De optie --line-buffered houdt de uitvoer leesbaar na de pipe naar grep.

Trigger vervolgens de foutieve actie slechts één keer: een HTTP-verzoek, een gecontroleerde herstart of een testverbinding. Als je meerdere tests tegelijk uitvoert, weet je niet meer welke regel tot welke test behoort. Voor een klassiek bestand kun je ook onze methode met tail bekijken.

Wanneer je een fout hebt gevonden, noteer dan de tijd, de eenheid of het betrokken proces, en de omliggende regels van het bericht. Dit is nuttiger dan een kopie-plak van duizend regels logs, en het voorkomt dat je een configuratie wijzigt voordat je de foutieve service hebt geïdentificeerd.