Výstup cat /var/log/syslog na aktivním serveru obvykle poskytuje pouze jednu věc: příliš mnoho řádků. Když služba selže nebo se objeví chyba, nejprve hledejte název služby, čas a přesnou zprávu. grep umožňuje snížit šum, aniž byste ztratili řádky, které vysvětlují, co se stalo těsně předtím.
Tato metoda funguje na souboru v /var/log i na výstupu z journalctl. Nenahrazuje celý žurnál: slouží k nalezení spolehlivého výchozího bodu, a poté k rozšíření kolem tohoto bodu.
Začněte s čitelným vyhledáváním
Přidejte čísla řádků a ignorujte velikost písmen, pokud program míchá Error, ERROR nebo error:
grep -n -i 'error' /var/log/mon-service.log-n zobrazuje číslo řádku. Stává se užitečným, když potřebujete pokračovat ve čtení souboru v less, porovnávat dvě vyhledávání nebo kopírovat úryvek do tiketu. Apostrofy zabraňují tomu, aby shell interpretoval speciální znaky v vzoru. Manuál pro grep podrobně popisuje možnosti vyhledávání a kontextu.
-ihledá bez rozlišování malých a velkých písmen.-npřidává číslo řádku.-Fzpracovává text jako literární řetězec, což je užitečné pro chybu obsahující.,[nebo?.-Eaktivuje rozšířené regulární výrazy.-C 3zobrazuje tři řádky před a po každém shodě.
Pro přesnou chybu upřednostněte -F. Adresa IP, cesta či zpráva s hranatými závorkami může být jinak interpretována jako regulární výraz:
grep -n -F 'connection refused [127.0.0.1:5432]' /var/log/mon-service.logUdržujte řádky, které vysvětlují chybu
Řádek označený ERROR málokdy naznačuje příčinu sám o sobě. Zobrazte kontext předtím, než provedete závěr:
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 uchovává tři řádky na každé straně. -A zobrazuje pouze následující řádky, -B pouze předchozí. Pokud se více chyb nachází daleko od sebe, grep odděluje skupiny pomocí --. Tento oddělovač není součástí žurnálu.
Když znáte více příznaků, spojte je pomocí -E:
grep -n -i -E 'error|failed|timeout|refused' /var/log/mon-service.logTento příkaz také vrací zprávy, které se nemusí nutně týkat vaší události. Poté přidejte název procesu, port nebo identifikátor dotazu, spíše než aby jste náhodně rozšiřovali seznam klíčových slov.
Filtrujte journalctl před použitím grep
Se systemd začněte tím, že omezíte žurnál na jednotku a období incidentu. Vyhnete se míchání zpráv z jiných služeb:
journalctl -u nginx --since '30 minutes ago' --no-pager
journalctl -u nginx --since '30 minutes ago' --no-pager | grep -n -i -C 2 'error'Nahraďte nginx skutečným názvem jednotky, například postgresql, docker nebo vaši aplikační službou. Pokud incident následuje po restartu, přidejte -b abyste zůstali v aktuálním spuštění. Manuál k journalctl také popisuje filtry podle jednotky a období. Náš průvodce o journalctl a žurnál z posledního spuštění podrobně popisuje tento filtr.
Nespouštějte vyhledávání po letech žurnálů, než vymezíte čas problému. Chyba viděná v 14:12 si zaslouží krátké okno kolem 14:12, poté širší přehled, pokud se žádná příčina neobjeví.
Sledujte službu během reprodukce
Pro reprodukovatelný problém otevřete druhý terminál a sledujte pouze nové řádky:
journalctl -fu nginx
tail -F /var/log/nginx/error.log | grep --line-buffered -i -E 'error|warn|failed'journalctl -f sleduje žurnál naživo. tail -F pokračuje také po rotaci souboru, což je bezpečnější než tail -f na mnoha aplikačních protokolech. Volba --line-buffered udržuje tok čitelný po přepojení na grep.
Pak vyvolejte akci, která selhává, pouze jednou: HTTP požadavek, kontrolovaný restart nebo testovací připojení. Pokud spustíte více testů najednou, nebudete vědět, která řádka patří k jakému pokusu. Pro sledování klasického souboru také můžete zkontrolovat naši metodu s tail.
Když najdete chybu, zaznamenejte čas, jednotku nebo dotčený proces a poté řádky kolem zprávy. To je užitečnější než kopírování a vložení tisíce řádků protokolů a zabraňuje to úpravě konfigurace, než identifikujete chybující službu.
n