Zarządzanie logami w Linuksie: polecenia journalctl dla logów systemd

Poziom: Początkujący
Szacowany czas: ~20 minut
Cel: Nauczyć się wyszukiwać, filtrować i zarządzać logami systemu oraz usług, wykorzystując logi Linuksa do rozwiązywania problemów i utrzymania dostępności serwera.

Wprowadzenie

Niezawodne zarządzanie logami w Linuksie jest niezbędne do utrzymania dostępności serwera i przeprowadzania diagnostyki serwera Linux. Podczas administrowania serwerami WWW trzeba szybko analizować logi systemowe za pomocą journalctl, aby znaleźć źródłową przyczynę problemu. Systemd (system init i menedżer usług większości współczesnych dystrybucji Linuksa) zbiera logi systemowe (ogólne zapisy operacji systemowych i zdarzeń w skali całego systemu). Pojedynczy log (zapis zdarzeń zachodzących w systemie operacyjnym lub aplikacji) jest zbierany przez Systemd-journald (usługę systemową, która zbiera i przechowuje dane logów) i zapisywany w dzienniku (Journal) (binarnych danych logów generowanych i zarządzanych przez systemd-journald). Do przeglądania tych danych służy Journalctl (narzędzie wiersza poleceń do wyszukiwania i wyświetlania logów systemd). Ten poradnik koncentruje się na użyciu poleceń journalctl do wyszukiwania, filtrowania i zarządzania logami systemd w journalctl. Po jego ukończeniu będziesz swobodnie poruszać się w wierszu poleceń i skutecznie korzystać z logów Linuksa do rozwiązywania problemów.

Wymagania wstępne

Przed rozpoczęciem upewnij się, że spełnione są następujące warunki:

• System operacyjny: Ubuntu 20.04/22.04/24.04 LTS, Debian 11/12/13 lub AlmaLinux/Rocky 8/9/10
• Wymagania sprzętowe i sieciowe: brak (ten poradnik korzysta z podstawowych narzędzi wiersza poleceń)
• Dostęp: dostęp sudo lub root do serwera
• Wymagana wiedza: podstawowa obsługa wiersza poleceń Linuksa

Krok 1: Zarządzanie logami w Linuksie: logi nietrwałe i trwałe

Domyślnie niektóre systemy konfigurują dziennik tak, aby używał logów nietrwałych (logów przechowywanych wyłącznie w pamięci RAM i tracone po ponownym uruchomieniu). Do skutecznego zarządzania logami w Linuksie potrzebne są logi trwałe (logi zapisywane na dysku i zachowywane po restarcie), dzięki którym można badać awarie także po ponownym uruchomieniu systemu.

Wykonaj poniższe polecenie, aby sprawdzić konfigurację przechowywania:

sudo grep -i 'storage' /etc/systemd/journald.conf

Oczekiwany wynik:

#Storage=auto

Powinieneś zobaczyć wynik wskazujący, czy ustawienie przechowywania to auto, persistent czy volatile. Zakomentowana linia #Storage=auto oznacza, że używane jest domyślne zachowanie auto.

W Ubuntu 24.04 i Debianie 13 katalog /var/log/journal już istnieje, a trwałe logowanie działa bez dodatkowej konfiguracji. Jeśli katalogu brakuje (na przykład w świeżej instalacji AlmaLinux), a chcesz wymusić trwałe logowanie, utwórz ten katalog i uruchom ponownie system logowania systemd (katalogiem zarządza usługa systemd-journald):

sudo mkdir -p /var/log/journal
sudo systemctl restart systemd-journald

W systemach AlmaLinux/RHEL należy dodatkowo przenieść (flush) logi z nietrwałej lokalizacji /run/log/journal do nowego trwałego magazynu na dysku:

sudo journalctl --flush

Nie powinieneś zobaczyć żadnego wyniku. Potwierdza to, że usługa została pomyślnie uruchomiona ponownie i od teraz będzie zapisywać dane trwałe na dysku.

Krok 2: Podstawowe polecenia journalctl dla logów systemd

Aby wyświetlić wszystkie dostępne wpisy, użyj polecenia domyślnego.

Wykonaj poniższe polecenie:

sudo journalctl

Oczekiwany wynik:

May 20 10:00:00 server systemd[1]: Started Logging Service.
May 20 10:00:01 server kernel: Linux version 5.15.0-101-generic...

Powinieneś zobaczyć stronicowaną listę wszystkich logów systemd na serwerze. Naciśnij q, aby zamknąć przeglądarkę stronicującą (pager).

Aby skutecznie analizować logi za pomocą journalctl, rzadko potrzebujesz czytać wszystko od początku. Możesz odwrócić kolejność wyników, aby najpierw widzieć najnowsze wpisy, używając opcji -r.

Wykonaj poniższe polecenie:

sudo journalctl -r

Oczekiwany wynik:

May 23 20:00:00 server sshd[1234]: Accepted publickey for user from 192.168.1.50...
May 23 19:59:58 server systemd[1]: Session 4 created for user.

Najnowsze wpisy logów powinny pojawić się u góry ekranu. To kluczowa technika szybkiej analizy logów za pomocą journalctl po incydencie.

Krok 3: Jak sprawdzić logi usługi

Często trzeba zdiagnozować konkretną jednostkę (unit) (obiekt, którym systemd potrafi zarządzać), na przykład jednostkę usługi (service unit) (typ jednostki sterujący usługą, taką jak nginx lub sshd). Użyj opcji -u, aby sprawdzić logi usługi, np. serwera WWW nginx.

Wykonaj poniższe polecenie (zakładając, że usługa jest zainstalowana, np. poleceniem sudo apt install nginx -y lub sudo dnf install nginx -y):

sudo journalctl -u nginx

Oczekiwany wynik:

May 23 18:00:00 server systemd[1]: Starting A high performance web server and a reverse proxy server...
May 23 18:00:01 server systemd[1]: Started A high performance web server and a reverse proxy server.

Powinieneś zobaczyć wyłącznie wpisy generowane przez usługę nginx. Pozwala to oddzielić błędy ruchu WWW od innych zdarzeń systemowych działających w tle. Jeśli usługa nie jest zainstalowana, zobaczysz jedynie -- No entries --.

Aby sprawdzić logi demona SSH, nazwa jednostki zależy od dystrybucji.

W Ubuntu/Debianie wykonaj:

sudo journalctl -u ssh

W AlmaLinux/RHEL/Rocky wykonaj:

sudo journalctl -u sshd

Oczekiwany wynik:

May 23 19:50:00 server sshd[1234]: Invalid user admin from 10.0.0.5 port 55432
May 23 19:55:00 server sshd[1235]: Accepted publickey for root from 10.0.0.2 port 44322

Powinieneś zobaczyć próby uwierzytelnienia oraz zdarzenia demona SSH.

Krok 4: Filtrowanie logów w journalctl według czasu i typu

Przy dużych ilościach danych potrzebne jest filtrowanie logów (zawężanie wyniku do wpisów spełniających określone kryteria). Filtrowanie logów w journalctl według czasu jest niezwykle przydatne, gdy awaria wystąpiła w znanym momencie.

Aby zobaczyć komunikaty wygenerowane od ostatniego uruchomienia systemu, sprawdzamy logi rozruchu (zapisy zdarzeń występujących podczas uruchamiania systemu).

Wykonaj poniższe polecenie:

sudo journalctl -b

Oczekiwany wynik:

May 23 08:00:00 server kernel: Linux version 5.15.0-101-generic...
May 23 08:00:00 server kernel: Command line: BOOT_IMAGE=/boot/vmlinuz...

Wynik powinien zaczynać się od pierwszego zdarzenia bieżącej sekwencji rozruchu.

Do filtrowania logów w journalctl na podstawie czasu użyj opcji --since i --until.

Wykonaj poniższe polecenie:

sudo journalctl --since "1 hour ago"

Oczekiwany wynik:

May 23 19:00:00 server cron[567]: (root) CMD (/usr/local/bin/backup.sh)
May 23 19:05:00 server sudo[580]: user : TTY=pts/0 ; PWD=/home/user ; USER=root ; COMMAND=/bin/ls

Powinieneś zobaczyć wszystkie zdarzenia z ostatnich 60 minut.

Aby wyświetlić logi jądra (komunikaty generowane przez jądro Linuksa, zazwyczaj dotyczące sprzętu i sterowników), użyj opcji -k.

Wykonaj poniższe polecenie:

sudo journalctl -k

Oczekiwany wynik:

May 23 08:00:00 server kernel: e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex
May 23 08:00:01 server kernel: IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

Powinieneś zobaczyć niskopoziomowe komunikaty jądra, przydatne przy diagnozowaniu problemów ze sprzętem lub sterownikami.

Krok 5: Filtrowanie według priorytetu

Każdy wpis ma priorytet (poziom ważności przypisany do komunikatu logu). Poziomy sięgają od Debug (najniższy priorytet, używany do szczegółowych informacji diagnostycznych) do Error (priorytet wskazujący awarię usługi lub procesu). Często sprawdzanym poziomem jest Warning (priorytet wskazujący potencjalne problemy, które nie są jeszcze błędami).

Do filtrowania logów w journalctl według priorytetu użyj opcji -p.

Wykonaj poniższe polecenie, aby wyświetlić wyłącznie błędy:

sudo journalctl -p err

Oczekiwany wynik:

May 23 10:15:20 server systemd[1]: Failed to start Custom Application Service.
May 23 14:30:00 server sshd[1122]: error: kex_exchange_identification: Connection closed by remote host

Powinieneś zobaczyć zwięzłą listę zawierającą tylko komunikaty na poziomie error, bez zwykłych operacji.

Wykonaj poniższe polecenie, aby wyświetlić ostrzeżenia i błędy:

sudo journalctl -p warning

Oczekiwany wynik:

May 23 10:15:15 server systemd-udevd[330]: vda: Process '/usr/bin/unshare -m /usr/bin/snap auto-import --mount=/dev/vda' failed with exit code 1.
May 23 10:15:20 server dhcpcd[400]: eth0: no IPv6 Routers available

Powinieneś zobaczyć zarówno ostrzeżenia, jak i błędy, co daje szerszy obraz potencjalnych problemów. W świeżo zainstalowanym systemie często pojawiają się rutynowe ostrzeżenia usług takich jak multipathd, irqbalance, dhcpcd czy udev, a nie krytyczne awarie usług. Dokładny wynik w dużej mierze zależy od konfiguracji i środowiska Twojego systemu.

Krok 6: Jak monitorować logi Linuksa w czasie rzeczywistym

Podczas wprowadzania zmian w konfiguracji lub odtwarzania problemu najlepiej monitorować logi Linuksa w czasie rzeczywistym. Użyj opcji -f (follow).

Wykonaj poniższe polecenie:

sudo journalctl -f

Oczekiwany wynik:

May 23 20:05:00 server sudo[2001]: user : TTY=pts/1 ; PWD=/ ; USER=root ; COMMAND=/bin/bash
May 23 20:05:00 server su[2002]: (to root) user on pts/1
May 23 20:05:00 server su[2002]: pam_unix(su:session): session opened for user root by user(uid=1000)

Powinieneś zobaczyć najnowsze wpisy logów, a terminal pozostanie aktywny i będzie wyświetlał nowe zdarzenia w miarę ich występowania. Naciśnij Ctrl+C, aby zakończyć.

Aby monitorować logi demona SSH w czasie rzeczywistym, nazwa jednostki zależy od dystrybucji.

W Ubuntu/Debianie wykonaj:

sudo journalctl -u ssh -f

W AlmaLinux/RHEL/Rocky wykonaj:

sudo journalctl -u sshd -f

Oczekiwany wynik:

May 23 20:10:15 server sshd[2100]: Connection from 192.168.1.100 port 45678
May 23 20:10:17 server sshd[2100]: Accepted publickey for admin from 192.168.1.100 port 45678
May 23 20:10:17 server sshd[2100]: pam_unix(sshd:session): session opened for user admin by (uid=0)

Powinieneś na żywo zobaczyć próby uwierzytelnienia SSH w momencie ich wystąpienia.

Krok 7: Miejsce na dysku i rotacja logów

Dziennik systemd z czasem może znacznie urosnąć. Archiwizowanie i usuwanie starych logów w celu zaoszczędzenia miejsca nazywa się rotacją logów. Możesz sprawdzić, ile miejsca zajmuje obecnie dziennik systemd.

Wykonaj poniższe polecenie:

sudo journalctl --disk-usage

Oczekiwany wynik:

Archived and active journals take up 200.0M in the file system.

Powinieneś zobaczyć wynik wskazujący łączną ilość miejsca zajmowanego przez pliki logów.

Aby ręcznie przeprowadzić rotację logów i zwolnić miejsce na dysku, możesz wyczyścić dane (vacuum) według czasu lub rozmiaru.

Wykonaj poniższe polecenie, aby zachować tylko ostatnie 500 MB danych:

sudo journalctl --vacuum-size=500M

Oczekiwany wynik:

Vacuuming done, freed 0B of archived journals from /var/log/journal.

Powinieneś zobaczyć wynik wskazujący, że stare pliki zostały usunięte, aż łączny rozmiar spadł poniżej 500 MB.

Weryfikacja

Aby upewnić się, że konfiguracja logowania działa poprawnie, a trwałe przechowywanie jest aktywne:

1. Sprawdź, czy utworzono lokalizację przechowywania logów:

   ls -ld /var/log/journal

   Powinieneś zobaczyć katalog należący do użytkownika root. W zależności od dystrybucji grupą może być systemd-journal lub root (obie wartości są prawidłowe).

2. Potwierdź, że journald jest uruchomiony:

   sudo systemctl status systemd-journald

   Usługa powinna mieć status active (running).

Rozwiązywanie problemów

Jeśli podczas zarządzania logami napotkasz trudności, sprawdź poniższe typowe scenariusze:

• Puste logi usługi (-- No entries --): Upewnij się, że usługa jest rzeczywiście zainstalowana i uruchomiona. Sprawdź także, czy używasz właściwej nazwy jednostki dla swojej dystrybucji (np. ssh w Debianie/Ubuntu a sshd w RHEL/AlmaLinux).
• Brak katalogu /var/log/journal: W niektórych systemach (jak AlmaLinux) trzeba ręcznie utworzyć ten katalog i uruchomić ponownie usługę logowania, aby włączyć logi trwałe. Jeśli pominiesz ten krok, logi pozostaną w pamięci nietrwałej (/run/log/journal).
• Odmowa dostępu (Permission denied): Jeśli nie możesz czytać logów bez sudo, upewnij się, że Twój użytkownik należy do grupy systemd-journal lub adm (sudo usermod -aG systemd-journal $USER).

Cofanie zmian

Jeśli chcesz wyłączyć trwałe logowanie i wrócić do logów nietrwałych (na przykład aby zaoszczędzić miejsce na dysku):

1. Usuń katalog trwałego przechowywania:

   sudo rm -rf /var/log/journal

2. Uruchom ponownie usługę logowania, aby odtworzyć nietrwały magazyn w /run/log/journal:

   sudo systemctl restart systemd-journald

Podsumowanie

To wszystko. Znasz już podstawy zarządzania logami w Linuksie. Dzięki właściwym poleceniom journalctl możesz sprawnie poruszać się po logach systemd, stosować filtry i zarządzać miejscem na dysku. Niezależnie od tego, czy musisz analizować logi za pomocą journalctl po awarii, czy tylko sprawdzić stan usługi, opanowanie journalctl to kluczowy krok w utrzymaniu zdrowej infrastruktury.

Wersja dokumentu: 1.0
Ostatnia aktualizacja: maj 2026
Właściciel: Zespół dokumentacji technicznej