journalctl w praktyce – jak znaleźć przyczynę awarii usługi

Przez /

Kiedy usługa przestaje działać, najgorsze co można zrobić to przewijać tysiące linii logów bez planu. journalctl daje bardzo dobre możliwości filtrowania, ale największa korzyść pojawia się dopiero wtedy, gdy zawężamy problem krok po kroku: do konkretnej jednostki, uruchomienia systemu, czasu i poziomu błędu.

Poniżej pokazuję sposób pracy, którego używam najczęściej podczas diagnostyki usług systemd.

1. Logi konkretnej usługi

journalctl -u nginx
journalctl -u sshd
journalctl -u minio

Parametr -u wybiera konkretną jednostkę systemd. To prawie zawsze lepszy start niż wyświetlanie całego journala.

Jeżeli problem pojawił się po ostatnim restarcie serwera, od razu dodaj -b:

journalctl -u nginx -b

2. Ostatnie wpisy bez przewijania całej historii

journalctl -u nginx -n 50
journalctl -u nginx -n 100 --no-pager

-n ogranicza liczbę wpisów, a --no-pager wyłącza przeglądanie przez less. Jest to wygodne zwłaszcza przy kopiowaniu wyniku do zgłoszenia lub skryptu diagnostycznego.

3. Zakres czasu – najważniejszy filtr podczas awarii

Jeżeli wiesz, że problem zaczął się około 10:30, nie analizuj logów z całego dnia.

journalctl -u nginx --since "2026-10-07 10:20" --until "2026-10-07 10:45"
journalctl -u nginx --since "30 minutes ago"
journalctl -u nginx --since today

Zawężenie czasu często od razu pokazuje pierwszą przyczynę, a nie tylko późniejsze skutki awarii.

4. Booty – kiedy problem pojawia się po restarcie

journalctl --list-boots
journalctl -b
journalctl -b -1
journalctl -u myapp -b -1

-b -1 oznacza poprzednie uruchomienie systemu. Jest bardzo przydatne, kiedy po restarcie wszystko już działa, ale chcemy sprawdzić, co wydarzyło się przed rebootem.

5. Filtrowanie po priorytecie

Journal używa poziomów zgodnych z syslog. Możemy wyświetlić tylko błędy i zdarzenia krytyczne:

journalctl -p err -b
journalctl -u nginx -p warning..emerg -b

To dobry filtr pomocniczy, ale nie należy polegać wyłącznie na nim. Nie każda aplikacja oznacza ważny komunikat poprawnym poziomem priorytetu.

6. Follow – obserwacja logów na żywo

journalctl -u nginx -f
journalctl -u myapp -f -n 20

Tryb -f działa podobnie do tail -f. Używam go podczas restartu usługi albo odtwarzania błędu, aby od razu zobaczyć nowy komunikat.

7. Wyszukiwanie komunikatu

W nowszych środowiskach można korzystać z wbudowanego filtrowania lub połączyć journalctl z grepem. Najbardziej uniwersalny wariant wygląda tak:

journalctl -u nginx -b --no-pager | grep -i error
journalctl -u myapp --since "1 hour ago" --no-pager | grep -Ei "error|fail|timeout|denied"

To rozwiązanie jest proste, ale trzeba pamiętać, że słowo „error” może nie występować w najważniejszym komunikacie. Najpierw warto zobaczyć kilkadziesiąt linii przed i po awarii.

8. Logi procesu, użytkownika i kernela

journalctl _PID=12345
journalctl _UID=1001
journalctl -k -b

-k ogranicza wynik do komunikatów kernela z bieżącego bootu. Przydaje się np. podczas problemów z dyskiem, interfejsem sieciowym, OOM killerem czy sterownikiem.

9. Przydatny format wyjścia

journalctl -u nginx -o short-iso
journalctl -u nginx -o json-pretty
journalctl -u nginx --since today -o cat

Do ręcznej analizy najczęściej wybieram short-iso, ponieważ dokładny timestamp jest czytelny i łatwo go porównać z logami aplikacyjnymi. JSON jest przydatny wtedy, gdy wynik ma być dalej przetwarzany.

10. Mój prosty schemat diagnostyczny

  • sprawdzam systemctl status usługa
  • wyświetlam journalctl -u usługa -b -n 100
  • ustalam dokładny czas pierwszego błędu
  • zawężam wynik przez --since i --until
  • jeśli trzeba, sprawdzam poprzedni boot przez -b -1
  • dopiero potem szukam błędów w konfiguracji, zależnościach lub zasobach systemowych

Najcenniejszy wpis w logu często znajduje się kilka sekund przed lawiną kolejnych błędów. Szukaj pierwszej przyczyny, nie ostatniego komunikatu.

11. Przykład: usługa nie wstaje po zmianie konfiguracji

systemctl status myapp
journalctl -u myapp -b -n 80 --no-pager
journalctl -u myapp --since "10 minutes ago" -o short-iso

Jeżeli w logach widzimy błąd składni, timeout do bazy lub odmowę dostępu do pliku, dalsza diagnostyka staje się znacznie prostsza. W przypadku problemu z uprawnieniami warto połączyć analizę journala z materiałami Uprawnienia DAC oraz Mechanizmy kontroli dostępu MAC.

Podsumowanie

journalctl nie jest tylko zamiennikiem dla tail -f. Największą wartość daje możliwość łączenia filtrów: jednostka, boot, czas i priorytet. Gdy podczas awarii trzymasz się takiego schematu, journal staje się narzędziem do szybkiego znalezienia przyczyny zamiast ogromnym magazynem komunikatów.

Przewijanie do góry