Jak używać polecenia journalctl do przeglądania logów systemowych w Linux

Journalctl to centralne narzędzie wiersza poleceń do przeglądania i zarządzania dziennikami systemowymi w nowoczesnych systemach Linux opartych na systemd. Narzędzie zastępuje tradycyjny model wielu rozproszonych plików tekstowych w katalogu /var/log jednolitym, ustrukturyzowanym interfejsem do binarnego dziennika zarządzanego przez usługę systemd-journald.

Zamiast przekopywać się przez wiele plików w /var/log, zyskujesz jedno narzędzie do filtrowania, sortowania i wyszukiwania zdarzeń po wielu kryteriach, co radykalnie przyspiesza diagnozowanie problemów i analizę historii.

Logi w dzienniku obejmują zarówno informacje o systemie operacyjnym, jak i usługach oraz aplikacjach. Każdy wpis jest wzbogacony o metadane (m.in. PID, jednostkę systemd, użytkownika, identyfikator maszyny), co ułatwia precyzyjne filtrowanie. Poniżej znajdziesz praktyczny przegląd pracy z journalctl — od podstaw, przez zaawansowane filtry i formatowanie, po zarządzanie miejscem oraz integracje.

Podstawowe pojęcia i architektura systemd-journald

Aby w pełni wykorzystać journalctl, warto poznać mechanikę działania systemd-journald. To usługa zbierająca i przechowująca dzienniki z wielu źródeł w binarnej, indeksowanej strukturze, zamiast w rozproszonych plikach tekstowych (np. /var/log/syslog, /var/log/messages). Format binarny zapewnia szybkie wyszukiwanie, integralność danych oraz bogate metadane dołączane automatycznie przez journald.

Do każdego wpisu trafiają m.in. PID, _SYSTEMD_UNIT, _UID, _HOSTNAME i wiele innych pól. Ta informacja kontekstowa umożliwia analizy nie tylko po treści komunikatu, ale również po atrybutach procesu czy użytkownika.

Logi mogą być przechowywane w pamięci (/run/log/journal/, tryb volatile) lub na dysku (/var/log/journal/, tryb persistent). Tryb volatile czyści się po restarcie; persistent zachowuje historię. W wielu dystrybucjach domyślne ustawienie Storage=auto przełącza się na trwałe logowanie, jeśli istnieje katalog /var/log/journal/.

Podstawowe polecenia i funkcjonalność journalctl

Najprostsze uruchomienie to journalctl bez argumentów (cała historia, od najstarszych), zwykle z pagerem less. W praktyce warto od razu zawężać dane filtrami, bo objętość logów bywa ogromna.

Poniżej znajdziesz skrót najważniejszych przełączników i ich zastosowań:

• -u/–unit – logi wybranej usługi systemd, np. journalctl -u nginx.service;
• -n – ograniczenie do ostatnich N wpisów, np. -n 50;
• -f/–follow – podgląd na żywo (jak tail -f), idealny do debugowania w czasie rzeczywistym;
• -b/–boot – logi z bieżącego uruchomienia; z -b -1 zobaczysz poprzedni boot; --list-boots wyświetla listę rozruchów;
• –since/–until – zakres czasu, obsługuje daty ISO i określenia względne (np. "yesterday", "1 hour ago");
• -p/–priority – filtrowanie po poziomie ważności (np. -p err);
• -g/–grep – wyszukiwanie po treści (MESSAGE) wyrażeniem regularnym;
• -k/–dmesg – tylko komunikaty jądra (kernel);
• -o/–output – format wyjścia (np. json, verbose, cat).

Zaawansowane filtrowanie logów według czasu

Najczęściej używanym mechanizmem jest zakres czasu: --since i --until. Działa zarówno z datą absolutną (ISO 8601), jak i względną (np. "yesterday", "-2 days"). Przykłady: journalctl --since "2023-01-01", journalctl --since "yesterday" --until "today".

Wygodne są też formy względne: --since "-1 hour", --since "2 days ago", --since "3 weeks ago". Łącz filtry czasu z -u i -p, by błyskawicznie zawęzić wyniki do najistotniejszych zdarzeń.

Filtrowanie według priorytetów i poziomów komunikatów

Systemd-journald zachowuje poziomy zgodne z syslog. Poniżej znajdziesz je w kolejności od najpoważniejszych do najmniej istotnych:

• emerg (0) – awaria, system nieużywalny;
• alert (1) – pilny alert wymagający natychmiastowej reakcji;
• crit (2) – błąd krytyczny;
• err (3) – błąd;
• warning (4) – ostrzeżenie;
• notice (5) – zdarzenie znaczące, ale normalne;
• info (6) – informacja;
• debug (7) – komunikaty diagnostyczne.

-p filtruje od wskazanego poziomu wzwyż (np. -p err pokaże err/crit/alert/emerg). Możesz też użyć zakresu FROM..TO, np. -p "warning..notice".

Zaawansowane filtrowanie według pól metadanych

Każdy wpis ma wiele pól, po których można filtrować w formie FIELD=VALUE. To niezwykle skuteczna technika precyzyjnego zawężania wyników.

Najczęściej używane pola i ich zastosowania:

• _PID – identyfikator procesu, np. journalctl _PID=1234;
• _UID – identyfikator użytkownika (audyt, śledzenie działań), np. _UID=1000;
• _GID – identyfikator grupy;
• _COMM – nazwa polecenia/programu (np. _COMM=bash);
• _HOSTNAME – filtr po hoście (gdy centralizujesz logi z wielu maszyn);
• _SYSTEMD_UNIT – jednostka systemd (równoważne efektowi -u).

Operatory logiczne i złożone zapytania

Wiele filtrów różnych pól łączy się domyślnie jako AND (log musi spełniać wszystkie warunki), np. journalctl _SYSTEMD_UNIT=nginx.service _PID=5678.

Wielokrotne użycie tego samego pola łączy się jako OR, np. _SYSTEMD_UNIT=nginx.service _SYSTEMD_UNIT=php-fpm.service. Operator OR między różnymi polami uzyskasz separatorem +, np. journalctl _SYSTEMD_UNIT=nginx.service + _PID=1234.

Wyszukiwanie i filtrowanie według treści

-g/--grep filtruje po treści pola MESSAGE przy użyciu wyrażeń regularnych, np. journalctl -g "error". To najszybsza droga, gdy pamiętasz fragment błędu, ale nie wiesz, kiedy i gdzie się pojawił.

Przykład wyrażeń: journalctl --grep="Failed (password|login)" wyszuka zdarzenia „Failed password” lub „Failed login”. Łącz z czasem, priorytetem i metadanymi, by uzyskać maksymalnie celne wyniki.

Formatowanie i prezentacja wyników

Domyślny format to „short”. W wielu scenariuszach warto dobrać inny format wyjścia opcją -o/--output. Poniżej porównanie najpopularniejszych formatów:

Możesz zawęzić zakres wyświetlanych pól: journalctl -u nginx -o json --output-fields=MESSAGE,_PID,PRIORITY. To prosty sposób na redukcję szumu i objętości danych.

Praktyczne scenariusze i przypadki użycia

Poniżej zebrano typowe scenariusze, w których journalctl realnie skraca czas diagnozy:

• diagnoza niedziałającej usługi – journalctl -u nazwa_usługi oraz -b po restarcie szybko pokażą błąd startu i jego kontekst;
• monitoring w czasie rzeczywistym – journalctl -f lub -f -p warning pozwalają reagować na pojawiające się ostrzeżenia i błędy bez zwłoki;
• analiza bezpieczeństwa (loginy/SSH) – journalctl SYSLOG_IDENTIFIER=sshd lub -u ssh.service, z filtrem czasu i treści (np. --since "1 hour ago" | grep -i "fail") do wykrywania ataków brute-force.

Zarządzanie przestrzenią dyskową i optymalizacja

Regularna kontrola i przycinanie archiwów dziennika zapobiega zapełnieniu dysku. Najpierw sprawdź zajętość: journalctl --disk-usage. Gdy potrzeba, użyj narzędzi „odchudzających”:

• –vacuum-size=ROZMIAR – usuwa najstarsze wpisy, aż całkowity rozmiar spadnie poniżej limitu, np. sudo journalctl --vacuum-size=1G;
• –vacuum-time=OKRES – usuwa wpisy starsze niż podany czas, np. sudo journalctl --vacuum-time=1month;
• –vacuum-files=N – ogranicza liczbę plików archiwum do N (przydatne w precyzyjnym sterowaniu rotacją).

Trwałe limity ustawisz w /etc/systemd/journald.conf. Oto kluczowe opcje i przykłady:

Trwałe przechowywanie logów i konfiguracja

Jeśli katalog /var/log/journal/ nie istnieje, journald używa RAM (/run/log/journal/), a logi giną po restarcie. Aby włączyć trwałość, utwórz katalog i zrestartuj usługę: sudo mkdir -p /var/log/journal/, następnie sudo systemctl restart systemd-journald. Alternatywnie, ustaw Storage=persistent w /etc/systemd/journald.conf i zrestartuj usługę.

Po włączeniu trybu persistent nowe logi trafią na dysk, a historia z poprzednich uruchomień będzie dostępna do analiz i audytu.

Zaawansowane funkcje i integracja z innymi narzędziami

Strukturalne formaty (np. -o json) ułatwiają integracje z ELK, Splunk, Datadog. Logi w JSON możesz przetwarzać narzędziami takimi jak jq, wysyłać strumieniowo lub archiwizować do analityki.

Przykładowy pipeline: journalctl -u nginx.service -o json | jq -r '.MESSAGE' | grep -i "error" | wc -l policzy błędy z usługi nginx.

--verify sprawdza integralność dziennika (przy włączonym Forward Secure Sealing). To krytyczna funkcja dla środowisk o podwyższonych wymaganiach bezpieczeństwa, zapewniająca, że wpisy nie były modyfikowane post factum.

Monitorowanie jądra (kernel) i komunikaty diagnostyczne

-k/--dmesg filtruje wyłącznie komunikaty jądra, co odpowiada dmesg, ale z zaletą metadanych journald. Przykłady: journalctl -k, journalctl -k --since "1 hour ago".

Komunikaty jądra są pierwszym miejscem poszukiwań przy niestabilności, błędach I/O, OOM czy problemach sterowników. Pozwalają szybko wskazać źródło awarii sprzętu lub niskopoziomowych błędów systemowych.

Najlepsze praktyki i rekomendacje dotyczące użytkowania

W codziennej pracy sprawdzają się poniższe zasady:

• proaktywne monitorowanie – śledź ostrzeżenia i błędy w czasie rzeczywistym, np. journalctl -p warning -f, aby wychwytywać problemy, zanim uderzą w użytkowników;
• opanowanie złożonych filtrów – łącz -u, -p, --since/--until i pola metadanych, by błyskawicznie docierać do sedna problemu;
• limity przestrzeni – skonfiguruj journald.conf (np. SystemMaxUse, SystemKeepFree) zgodnie z profilem systemu, by uniknąć zapełnienia dysku;
• interpretacja kontekstu – czytaj logi „ze zrozumieniem” (kiedy, przez co, na jakich uprawnieniach), nie tylko pojedyncze linie;
• integracja z monitoringiem – włącz zbieranie i alertowanie w systemach typu Prometheus/Grafana lub SIEM, by automatycznie wykrywać anomalie.