O Systemd-Journald słów kilka – EuroLinux Sp. z o.o.

Od kilku lat każdy administrator systemów Linuxowych jest niemalże katowany potężną dawką informacji dotyczących Systemd. Zaczęło się oczywiście od szeroko omawianej zmiany pierwszego procesu startowanego przez jądro Linux oraz powiązanej z nią krytyką. Na szczęście dzisiejsze negatywne opinie w większym stopniu dotyczą raczej szeregu problemów, które to rozwiązanie wprowadziło oraz faktu, iż Systemd ma tendencję […]

Od kilku lat każdy administrator systemów Linuxowych jest niemalże katowany potężną dawką informacji dotyczących Systemd. Zaczęło się oczywiście od szeroko omawianej zmiany pierwszego procesu startowanego przez jądro Linux oraz powiązanej z nią krytyką. Na szczęście dzisiejsze negatywne opinie w większym stopniu dotyczą raczej szeregu problemów, które to rozwiązanie wprowadziło oraz faktu, iż Systemd ma tendencję do „wchłaniania” kolejnych niezależnych elementów systemu. Nie przedłużając, chciałbym pokazać jeden z przydatniejszych mechanizmów, jaki Systemd wprowadził, a który niewątpliwie przyczynił się do jego sukcesu. Artykuł ten będzie traktował o Journald.

Nakreślenie problemów związanych z logowaniem

Jednym ze znanych wszystkim problemów z logami tekstowymi jest ich format. Niestety ze względu na swoją specyfikę i ustawienia oraz serwisy działające na systemie, będą miały różne formaty logów. Jest to jeden z kilku powodów, które powodują, iż praktycznie wszystkie serwisy logują do odizolowanych plików.

Wyciąganie informacji z logów komplikuje się jeszcze bardziej, gdy aplikacje nie używają standardowych bibliotek oraz nie przestrzegają praktycznie żadnej konwencji (mieszany format logów dla tego samego priorytetu, brak priorytetów/tagów, mieszanie formatów czy nawet języków dla tej samej wiadomości – to tylko niektóre problemy). Jest to jedno z najczęściej napotykanych wyzwań przy wdrażaniu jednego z naszych produktów – rozwiązania EuroLog. Wymaga to z reguły stworzenia dedykowanego rozwiązania pozwalającego na poprawne parsowanie logów, co z kolei umożliwia ich analizę i wynikającą z niej prezentację danych.

W tym wypadku wina leży często także po stronie zamawiającego, który na żadnym etapie nie określił (z reguły niefunkcjonalnego) wymagania co do produktu, jakim jest logowanie oraz związane z nim atrybuty, choćby takie jak format, sposób lub standard logowania. W przypadku Journald mamy do czynienia z ustrukturyzowanymi logami, które z natury są dużo bardziej czytelne.

Innym problemem z logowaniem może być start usługi systemowej zbierającej logi. W starszych systemach uruchamia się ona późno (w stosunku do startu samego systemu), co utrudnia lub uniemożliwia zbieranie logów z wydarzeń, które miały miejsce przed jej startem. Journald będąc częścią systemu inicjalizującego, startuje niemal równo z systemem, rozwiązując częściowo ten problem.

Następnym zagadnieniem jest szybkość logowania i odczytów logów. Dzięki ich strukturyzacji oraz binarnemu formatowi Journald jest szybki oraz, co nie mniej istotne, ułatwia filtrowanie i przeszukiwanie logów. Niemniej ten stan rzeczy ma też swoich krytyków. Dla przykładu Linus Torvalds w szerszej wypowiedzi na temat Systemd udzielonej serwisowi technologicznemu ZDNet, powiedział:

... I think some of the design details are insane (I dislike the binary logs, for example), but those are details, not big issues.

Co w luźnym tłumaczeniu oznacza:

... Sądzę, że niektóre szczegóły projektu są szalone (dla przykładu nie podoba mi się binarny format logów), ale są to detale, a nie wielkie problemy.

Ostatnim zagadaniem, które pozwolę sobie szerzej opisać, jest zgodność Journald z syslogiem. W większości dystrybucji Journald działa wraz z syslogiem w sposób zupełnie przezroczysty dla administratora. Aplikacje mają zarówno możliwość tradycyjnego pisania do /dev/log w formacie sysloga, jak i odwoływania się bezpośrednio do API Journald. Co więcej, Journald może przekazywać wiadomości do sysloga. Pozwala to na zaadaptowanie tego rozwiązania bez konieczności zmiany w aplikacjach czy serwisach. Warstwa ta moim skromnym zdaniem jest kluczem do sukcesu Journald.

Po tym krótkim wstępnie pozwolę sobie w punktach wymienić najważniejsze zalety i wady Journald.

Do zalet należy zaliczyć:

Ustawienia Journald

Plikiem konfiguracyjnym Journald jest /etc/systemd/journald.conf. Domyślna konfiguracja jest definiowana przez dostawcę dystrybucji na etapie kompilacji Systemd. Pozwolę sobie omówić kilka wybranych parametrów.

Do najważniejszych należą:

Storage=“{volatile,persistent,auto,none}” – domyślną wartością jest auto. „Volatile” – logi trzymane są tylko w pamięci. „Persistent” – preferowanie zapisywania logów na dysku w katalogu /var/log/journal. Katalog ten zostanie automatycznie stworzony, jeśli istnieje taka konieczność. „Auto” – logi trzymane są na dysku, jeśli odpowiednie katalogi istnieją. „None” – wyłącza logowanie (logi są zrzucane (drop) zupełnie jak pakiety w firewallu), jednak wszystkie ustawienia przekazywania (forward) logów nadal działają.
Compress={yes,no} – włączenie kompresji logów zapisywanych na dyskach.
{System,Runtime}{MaxFileSize,MaxUse,KeepFree}= – ustawienia maksymalnych rozmiarów przetrzymywanych dzienników. Opcje zaczynające się od „system” dotyczą plików zapisywanych na dysku, a te zaczynające się od „runtime” dotyczą plików trzymanych w pamięci.
SyncIntervalSec= – interwał pomiędzy synchronizacją (zapisem) logów na dysk. Po synchronizacji pliki journal wchodzą w stan OFFLINE. Journald automatycznie synchronizuje logi, jeśli dostanie wiadomość z priorytetem – CRIT, ALERT lub EMERG.
FowardTo{SysLog,KMsg,Console,Wall}= – ustawia przekazywanie logów do sysloga, buforu jądra, konsoli lub wysyła je w trybie wall do wszystkich zalogowanych użytkowników. Domyślnie przekazywanie zarówno do sysloga, jak i do zalogowanych użytkowników (wall) jest włączone.
MaxLevel{Store,Syslog,KMsg,Console,Wall}= – ustawia maksymalny priorytet wiadomości, które będą przekazywane. Przyjmuje zarówno wartości nazwy priorytetu („emerg”;„alert”;„crit”…), jak i wartości liczbowe (0..7).

Krótki przewodnik po journalctl

Podstawową komendą używaną do zapytań Journald jest journalctl. Domyślne wywołanie journalctl pokaże cały plik dziennika od najstarszego wydarzenia.

[root@Normandy ~]# journalctl-- Logs begin at Wed 2019-02-27 15:35:16 CET, end at Tue 2019-03-05 16:53:35 CET. --Feb 27 15:35:16 Normandy systemd-journal[2803]: Permanent journal is using 8.0M (max allowed 4.0G, trying....

By odwrócić kolejność wypisywania, można użyć przełącznika -r. W ten sposób na początku dostaniemy najnowsze wpisy.

[root@Normandy ~]# journalctl -r-- Logs begin at Wed 2019-02-27 15:35:16 CET, end at Tue 2019-03-05 16:55:01 CET. --Mar 05 16:55:01 Normandy systemd[1]: Removed slice User Slice of pcp.

By ograniczyć liczbę wyświetlanych zdarzeń, należy użyć opcji -n lub --lines=.
Przykładowo systemctl -u sshd -l 1 -r zwróci nam ostatnie zdarzenie, które zostało zalogowane dla serwisu sshd.

[root@Normandy ~]# journalctl -u sshd -n 1-- Logs begin at Wed 2019-02-27 15:35:16 CET, end at Tue 2019-03-05 17:13:34 CET. --Mar 05 16:33:28 Normandy systemd[1]: Started OpenSSH server daemon.

Jak wspomniałem wcześniej, logi Journald są trzymane w formacie strukturyzowanym. By zobaczyć ich strukturę, należy użyć przełącznika -o lub --output, który ustawia format wypisywanych danych, a następnie wybrać format verbose. Journald wspiera wiele wyjść. Do najważniejszych formatów należą: short (domyślny), verbose,json,json-pretty i cat.

Używając journalctl -o verbose -n 1 dostaniemy wyjście pozwalające zobaczyć, jak wyglądają poszczególne pola naszego loga:

[root@Normandy ~]# journalctl -o verbose -n 1-- Logs begin at Wed 2019-02-27 15:35:16 CET, end at Tue 2019-03-05 17:34:29 CET. --Tue 2019-03-05 17:34:29.025389 CET [s=a62625be54cb48c59c83855f632b0bc8;i=41e7;b=7bd20dcf114648c0b17ddf6dd55dd504;m=9929ea05;t=5835b72741770; PRIORITY=6 _SYSTEMD_SLICE=system.slice _MACHINE_ID=d83e252f8d4a4e838692e59dbf0d7a9f _HOSTNAME=Normandy SYSLOG_FACILITY=3 _TRANSPORT=syslog SYSLOG_IDENTIFIER=chronyd _COMM=chronyd _EXE=/usr/sbin/chronyd _CMDLINE=/usr/sbin/chronyd _SYSTEMD_CGROUP=/system.slice/chronyd.service _SYSTEMD_UNIT=chronyd.service _SELINUX_CONTEXT=system_u:system_r:chronyd_t:s0 _UID=992 _GID=987 _CAP_EFFECTIVE=2000400 MESSAGE=Selected source 91.212.242.20 _BOOT_ID=7bd20dcf114648c0b17ddf6dd55dd504 SYSLOG_PID=5411 _PID=5411 _SOURCE_REALTIME_TIMESTAMP=1551803669025389

Jednym z najczęściej stosowanych pól, po których filtrujemy logi, jest \_COMM, który pozwala wyszukać logi interesującego nas serwisu. W tym celu należy wykonać:

[root@Normandy ~]# journactl _COMM=chronyd

Inną opcją, z reguły dającą takie same rezultaty, jest użycie przełącznika -u lub --unit=.

Ustawienie trwałego zapisu logów Journald

Journald w większości dystrybucji domyślnie działa tylko w pamięci operacyjnej systemu. Z reguły jednak chcielibyśmy, by logi (pliki dziennika) były dostępne także po restarcie maszyny czy w przypadku awarii naszego systemu. W tym celu należy utworzyć katalog /var/log/journal.

mkdir /var/log/journal

Następnie nadajemy mu odpowiednie prawa dostępu. Zwróćmy uwagę na ustawienie flagi SETGID.

chown root:systemd-jorunal /var/log/journalchmod 2755 /var/log/journal

Na samym końcu należy dosłownie zasygnalizować (wysyłając sygnał) procesom systemd-journal.

W tym celu użyjemy jednego z dwóch nietypowych sygnałów zdefiniowanych w standardzie POSIX.1-1990. Mowa o sygnałach SIGUSR1 i SIGUSR2. Sposób reakcji na nie jest definiowany przez twórcę programu. Więcej na ten temat można znaleźć w man 7 signal. Natomiast w przypadku systemd-journald:

1. Sygnał SIGUSR1 jest żądaniem, by dane z /run/ (pamięci operacyjnej) zostały zapisane/zrzucone (flush) do /var/log/journal (domyślna ścieżka), by uczynić je trwałymi.
2.SIGUSR2 jest żądaniem natychmiastowej rotacji plików dziennika.

Teraz już wiedząc, co robimy, możemy wykonać następującą komendę:

killall -USR1 systemd-journald

Ustawienie trwałego zapisu logów Journald w pliku journald.conf

Innym sposobem na stworzenie trwałych zapisów logów, jest edytowanie lub dodanie linii:

Storage=persistent

do wcześniej opisanego pliku /etc/systemd/journald.conf. Następnie należy wykonać:

sudo systemctl restart systemd-journald

Journald w tym momencie sam stworzy wymagane katalogi.

Uważnym czytelnikom chciałbym pokazać pewną ciekawostkę, którą opisuje poniższy listening.

Alex@Normandy:~$ getfacl /var/log/journal/getfacl: Removing leading '/' from absolute path names# file: var/log/journal/# owner: root# group: systemd-journal# flags: -s-user::rwxgroup::r-xgroup:adm:r-xgroup:wheel:r-xmask::r-xother::r-xdefault:user::rwxdefault:group::r-xdefault:group:adm:r-xdefault:group:wheel:r-xdefault:mask::r-xdefault:other::r-xAlex@Normandy:~$ sudo rm -rf /var/log/journal/Alex@Normandy:~$ sudo systemctl restart systemd-journaldAlex@Normandy:~$ getfacl /var/log/journal/getfacl: Removing leading '/' from absolute path names# file: var/log/journal/# owner: root# group: rootuser::rwxgroup::r-xother::r-x

Niestety odpowiednie ACL-ki oraz uprawnienia zostaną przypisane dopiero po restarcie maszyny.

Podziękowania

Jak zwykle chciałbym podziękować za czas poświęcony na czytanie naszego bloga. Zachęcam do jego regularnego odwiedzania lub zapisu na newsletter, gdyż każdego miesiąca publikujemy kilka równie ciekawych co ten lub nawet ciekawszych tekstów stricte technicznych.

Powiązane manuale

man journalctl
man journald.conf
man systemd-journald
man systemd.journal-fields
man 7 signal

O Systemd-Journald słów kilka – EuroLinux Sp. z o.o. | EuroLinux (2024)