Grep w systemie Linux: znajdowanie błędów w logach

Wykonanie cat /var/log/syslog na aktywnym serwerze przynosi głównie jedną rzecz: zbyt wiele linii. Kiedy usługa zawodzi lub pojawia się błąd, najpierw szukaj nazwy usługi, godziny oraz precyzyjnego komunikatu. grep pozwala zredukować szum, nie tracąc linii, które wyjaśniają, co się stało tuż przed.

Ta metoda działa na pliku w /var/log, jak również na wyjściu z journalctl. Nie zastępuje pełnego dziennika: służy do znalezienia wiarygodnego punktu startowego, a następnie rozszerzenia wokół tego punktu.

Zacznij od czytelnego wyszukiwania

Dodaj numery linii i ignoruj wielkość liter, jeśli program miesza Error, ERROR lub error:

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

-n wyświetla numer linii. Staje się przydatne, gdy musisz przeglądać plik w less, porównywać dwa wyszukiwania lub kopiować fragment do zgłoszenia. Apostrofy zapobiegają interpretacji specjalnych znaków w wzorze przez powłokę. Podręcznik grep szczegółowo opisuje opcje wyszukiwania i kontekstu.

• -i wyszukuje bez rozróżniania wielkości liter.
• -n dodaje numer linii.
• -F traktuje tekst jako dosłowny ciąg znaków, przydatny dla błędu zawierającego ., [ lub ?.
• -E włącza rozszerzone wyrażenia regularne.
• -C 3 wyświetla trzy linie przed i po każdym dopasowaniu.

Aby uzyskać dokładny błąd, preferuj -F. Adres IP, ścieżka lub komunikat z nawiasami mogą być inaczej interpretowane jako wyrażenie regularne:

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

Zachowaj linie wyjaśniające błąd

Linia oznaczona ERROR rzadko wskazuje przyczynę sama w sobie. Wyświetl kontekst przed skonkludowaniem:

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 zachowuje trzy linie po każdej stronie. -A wyświetla tylko następujące linie, -B tylko poprzednie. Jeśli kilka błędów jest daleko od siebie, grep oddziela grupy za pomocą --. Ten separator nie jest częścią dziennika.

Gdy znasz kilka objawów, połącz je za pomocą -E:

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

To polecenie także zwraca komunikaty, które niekoniecznie dotyczą Twojego zdarzenia. Następnie dodaj nazwę procesu, port lub identyfikator żądania, zamiast randomowo wydłużać listę słów kluczowych.

Filtruj journalctl przed użyciem grep

Wraz z systemd, zacznij od ograniczenia dziennika do jednostki i okresu zdarzenia. Unikniesz mieszania wiadomości z innych usług:

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

Zastąp nginx rzeczywistą nazwą jednostki, na przykład postgresql, docker lub Twoją usługą aplikacyjną. Jeśli zdarzenie miało miejsce po ponownym uruchomieniu, dodaj -b, aby pozostać na bieżącym uruchomieniu. Podręcznik journalctl opisuje również filtry według jednostki i okresu. Nasz przewodnik dotyczący journalctl i dzienników ostatnich uruchomień szczegółowo opisuje ten filtr.

Nie prowadź wyszukiwania na lata dzienników, zanim nie określisz godziny problemu. Błąd dostrzegnięty o 14:12 zasługuje na krótkie okno wokół 14:12, a później szersze przeglądanie, jeśli żadne przyczyny się nie pojawiają.

Obserwuj usługę podczas reprodukcji

Dla problemu, który można powtórzyć, otwórz drugie terminal i obserwuj tylko nowe linie:

journalctl -fu nginx

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

journalctl -f śledzi dziennik na żywo. tail -F kontynuuje również po rotacji pliku, co jest bezpieczniejsze niż tail -f dla wielu dzienników aplikacji. Opcja --line-buffered utrzymuje strumień czytelny po przekazaniu do grep.

Następnie uruchom jednorazowo działanie, które zawodzi: żądanie HTTP, kontrolowane ponowne uruchomienie lub testowe połączenie. Jeśli uruchomisz wiele testów jednocześnie, nie będziesz wiedzieć, która linia należy do którego testu. Aby śledzić klasyczny plik, możesz również zapoznać się z naszą metodą z tail.

Kiedy znajdziesz błąd, zanotuj godzinę, jednostkę lub dotknięty proces, a następnie linie wokół komunikatu. To bardziej przydatne niż skopiowanie tysiąca linii dzienników i unika modyfikacji konfiguracji przed zidentyfikowaniem wadliwej usługi.

n