Analiza logów w praktyce: journalctl, /var/log i filtrowanie zdarzeń
Nauczysz się zawężać logi według czasu, usługi, priorytetu i tekstu oraz łączyć informacje z journala i plików w katalogu /var/log.
Wróć do listy lekcji1. Krótka teoria
Skuteczna analiza logów nie polega na czytaniu tysięcy wpisów od początku. Najpierw trzeba określić przybliżony czas problemu, usługę i objaw, a potem stopniowo zawężać wynik. Systemd journal przechowuje ustrukturyzowane zdarzenia, które można filtrować przez journalctl. Opcja -u wybiera jednostkę, --since i --until ograniczają czas, -p wybiera priorytet, a -b wskazuje uruchomienie systemu. Priorytety obejmują między innymi warning, err, crit i emerg. W Rocky Linux klasyczne logi mogą znajdować się w /var/log/messages, /var/log/secure oraz podkatalogach konkretnych usług. Do plików przydają się tail, less i grep. Wyszukiwanie powinno uwzględniać kontekst: samo słowo „error” nie wykryje każdego problemu, a pojedynczy wpis bez czasu i sąsiednich linii może prowadzić do błędnego wniosku. Rotacja logów powoduje, że starsze dane mogą znajdować się w plikach z numerem lub rozszerzeniem kompresji. Analizę warto prowadzić od objawu do dowodu: zanotować czas, odtworzyć problem, obserwować nowe wpisy i porównać komunikaty różnych warstw systemu.
2. Przykłady komend
journalctl --since "30 minutes ago"
Pokazuje zdarzenia z ostatnich 30 minut.
$ journalctl --since "30 minutes ago"
journalctl --since "2026-06-19 10:00" --until "2026-06-19 10:15"
Ogranicza dziennik do konkretnego przedziału czasu.
$ journalctl --since "2026-06-19 10:00" --until "2026-06-19 10:15"
journalctl -u crond -p warning -b
Pokazuje ostrzeżenia i poważniejsze wpisy crond z bieżącego uruchomienia.
$ journalctl -u crond -p warning -b
journalctl -f
Obserwuje nowe wpisy w journalu na żywo.
$ journalctl -f
sudo tail -n 50 /var/log/messages
Pokazuje 50 ostatnich linii ogólnego logu systemowego.
$ sudo tail -n 50 /var/log/messages
sudo less /var/log/secure
Pozwala wygodnie przeglądać log zdarzeń uwierzytelniania.
$ sudo less /var/log/secure
sudo grep -i "failed" /var/log/secure
Wyszukuje słowo failed bez rozróżniania wielkości liter.
$ sudo grep -i "failed" /var/log/secure
sudo grep -n -C 2 "error" /var/log/messages
Pokazuje numery linii oraz dwie linie kontekstu wokół dopasowania.
$ sudo grep -n -C 2 "error" /var/log/messages
ls -lh /var/log
Pokazuje pliki logów wraz z ich rozmiarami i datami.
$ ls -lh /var/log3. Zadanie praktyczne
sudo journalctl -f. W drugim terminalu wykonaj bezpieczną akcję generującą wpis, na przykład sudo systemctl status crond, i sprawdź, czy pojawiło się powiązane zdarzenie. Zakończ obserwację klawiszami Ctrl+C. Potem wyświetl logi z ostatnich 15 minut, ogranicz je do usługi crond i porównaj wynik z journalctl -u crond -p warning --since "15 minutes ago". Na końcu sprawdź listę plików w /var/log i, bez modyfikowania danych, wyszukaj w dostępnym logu wpisy zawierające „failed” wraz z kontekstem.
4. Typowe błędy
- Czytanie całego dziennika bez ograniczenia czasu, usługi lub liczby wpisów.
- Zakładanie, że każdy problem zawiera dosłowne słowo error.
- Ignorowanie znacznika czasu i kolejności zdarzeń.
- Wyciąganie wniosku z pojedynczej linii bez sprawdzenia kontekstu.
- Mylenie braku uprawnień do odczytu logu z brakiem wpisów.
- Pomijanie rotowanych plików podczas szukania starszego zdarzenia.
- Usuwanie lub czyszczenie logów przed zakończeniem diagnozy.
5. Podsumowanie
Analizę logów prowadź od czasu i objawu do coraz dokładniejszych filtrów. journalctl filtruje zdarzenia według jednostki, czasu, uruchomienia systemu i priorytetu. W /var/log korzystaj z tail, less i grep, zachowując kontekst wpisów. Logi są dowodem diagnostycznym, dlatego nie należy ich usuwać przed wyjaśnieniem problemu.