Wprowadzenie do Systemd Journal

Wprowadzenie do Systemd Journal

SystemD jest obecnie system inicjowany przyjęty przez prawie wszystkie dystrybucje Linux, od Red Hat Enterprise Linux do Debian i Ubuntu. Jedną z rzeczy, które sprawiły, że Systemd był celem wielu krytyków, jest to, że stara się być czymś więcej niż prostym systemem init i próbuje ponownie wymienić niektóre podsystemy Linux.

Na przykład tradycyjny system rejestrowania używany w Linux Rsyslog, nowoczesna wersja tradycyjnej Syslog. SystemD wprowadził własny system rejestrowania: jest wdrażany przez demon, Journald, który przechowuje dzienniki w formacie binarnym w „Journal”, który może być zapytany przez Journalctl pożytek.

W tym samouczku poznamy niektóre parametry, których możemy użyć do modyfikacji Journald Zachowanie demona i niektóre przykłady, jak zapytać dziennik i sformatować wyniki wynikające z tych zapytań.

W tym samouczku się nauczysz:

  • Jak zmienić domyślne ustawienia Journalda
  • Jak Journald może współistnieć z Syslog
  • Jak zapytać dziennik i niektóre sposoby sformatowania wyjściowych zapytania

Zastosowane wymagania i konwencje oprogramowania

Wymagania oprogramowania i konwencje linii poleceń Linux
Kategoria Wymagania, konwencje lub wersja oprogramowania
System Rozkład Linuksa za pomocą SystemD (prawie wszystkie Do)
Oprogramowanie Nie jest potrzebne konkretne oprogramowanie
Inny Przywileje główne, aby (ostatecznie) zmienić konfiguracje domyślne
Konwencje # - Linux -commands do wykonania z uprawnieniami root bezpośrednio jako użytkownik root lub za pomocą sudo Komenda
$-Linux-commands, który ma zostać wykonany jako zwykły użytkownik niepewny

Plik konfiguracyjny Journalda

Zachowanie Journald Demon można zmodyfikować, zmieniając ustawienia w pliku konfiguracyjnym: /itp./Systemd/Journald.conf. Bezpośrednia modyfikacja tego pliku nie jest zalecana; Zamiast tego powinniśmy utworzyć oddzielne pliki konfiguracyjne zawierające parametry, które zamierzamy zmienić, zapisz je z .conf rozszerzenie i umieść je wewnątrz /itp./Systemd/Journald.conf.D informator.

Pliki umieszczone wewnątrz /itp./Systemd/Journald.conf.D katalog ma większe pierwszeństwo niż /itp./Systemd/Journald.conf: Są sortowane według nazwy w Zakon leksykograficzny i przeanalizowano w tej kolejności, wszystko po głównym pliku. W przypadku, gdy to samo ustawienie opcji istnieje w więcej niż jednym pliku, ostatnia, która będzie analizowana, będzie skuteczna.

/etc/systemd/Jourlnald.conf Plik domyślnie zawiera skomentowaną listę opcji wewnątrz [Dziennik] Stanza: Reprezentują wartości domyślne używane w czasie kompilacji (poniższa zawartość pochodzi z systemu Fedora):

[Journal] #Storage = Auto #Compress = Tak #uszczelnienie = tak #splitMode = uid #synCinterValsec = 5M #RATELIMITINTIRVALSEC = 30S #RATELIMITBURST = 10000 #SystemMaxuse = #SystemKeepfree = #SystemMaxFileSize = #SystemMaxFiles = 100 #RuntimeMaSuse = #RuntimeEpfree = #RuntimeMaxfileSize = #runtimeMaxFiles = 100 #maxEntentionSec = #maxfileSec = 1Month #ForwardToSysLog = no #doporttokmsg = no #ForwardToconsole = no #ForwardTowAll = Tak #tTypath =/dev/konsola #maxlevelStore = debug #MaxlevelsSlog = debeug #maxlevelkmsg = ogłoszenie # MaxlevelConsole = Informacje #Maxlevelwall = Emerg #linemax = 48k #readKMSg = Tak #audyt = tak 


Zobaczmy, jakie jest znaczenie niektórych z tych opcji i jak mogą one zmienić zachowanie Journald Demon.

Opcja „przechowywania”

Pierwszą opcją, którą napotykamy w pliku Składowanie. Ta opcja kontroluje miejsce przechowywania danych dziennika. Wartość domyślna używana w czasie kompilacji jest tutaj automatyczny, Ale można wybrać spośród:

  • lotny
  • uporczywy
  • automatyczny
  • nic

Jeśli używamy lotny Jako wartość tej opcji dane dziennika będą przechowywane tylko w pamięci pod /run/log/dziennik (/uruchomić jest TMPFS: jego zawartość jest przechowywana w pamięci), więc nie przetrwa systemu ponownego uruchomienia systemu.

Jeśli uporczywy Zamiast tego jest używane, dane z czasopisma będą przechowywane na dysku, poniżej /var/log/dziennik, który jest tworzony, jeśli nie istnieje. Jeśli z jakiegoś powodu dysk nie jest zapisany, jednak, /run/log/dziennik jest używany jako awarie.

automatyczny wartość dla Składowanie opcja, która tutaj jest używana jako domyślna, działa w zasadzie jak uporczywy w tym sensie, że gdy jest używany, dane z czasopisma są przechowywane pod /var/log/dziennik. Różnica polega na tym, że jeśli ścieżka nie istnieje, nie zostanie utworzona, a dzienniki będą przechowywane tylko w pamięci.

Wreszcie, jeśli nic Wartość jest używana, wszystkie przechowywanie jest wyłączone: podczas przekazywania do innych systemów rejestrowania, takich jak Syslog nadal będą działać, wszystkie otrzymane dane zostaną porzucone.

Opcja „kompresji”

Opcja „kompresja” kontroluje, czy dane przekraczają próg 512 bajty są ściśnięte przed przechowywaniem na dysku. Ta opcja akceptuje dwa typy wartości: a Boolean jak w powyższym przypadku (Tak) lub liczba, która ustawia sam próg kompresji. Jeśli dostarczone jest to ostatnie, kompresja jest aktywowana w sposób domyślnie. Wartość progowa jest domyślnie wyrażona w bajtach, ale K, M Lub G Zamiast tego można użyć sufiksów.

Opcja „ForwardTosysLog”

Jak już wspomniano, w erze przed systemem, dzienniki, w którym zarządzane przez Syslog system rejestrowania (Rsyslog Właściwie). Ten system rejestrowania jest w stanie przekazać dzienniki do wielu miejsc docelowych, takich jak pliki tekstowe, terminale, a nawet inne maszyny w sieci. SystemD zaimplementował własny system rejestrowania, który jest przedmiotem tego samouczka: Journald.

Oba systemy mogą współistnieć (jest to czasem konieczne, ponieważ Journald nie ma niektórych funkcji, takich jak scentralizowane rejestrowanie, Lub tylko dlatego, że my, jako administratorzy możemy polubić dzienniki, aby być przechowywane w plikach tekstowych zamiast w formacie binarnym, aby można je było manipulować za pomocą standardowych narzędzi Unix).

Ten ForwardTosyslog Opcja wymaga Boolean Wartość: jeśli jest ustawiona na Tak, Wiadomości zostaną przekazane do /run/systemd/journal/syslog gniazdo, gdzie można odczytać Syslog. To zachowanie można również ustawić na rozruchu za pośrednictwem Systemd.Journald.napastnik_to_syslog opcja.

Podobne opcje można użyć do przekazywania wiadomości do kmsg (Bufor dziennika jądra), do konsoli lub „ściany” (wysłany jako komunikaty dziennika do zalogowanych użytkowników). Tylko ten ostatni jest ustawiony Tak domyślnie.

Zapytanie dziennika

Narzędzie, których możemy użyć do zbadania dzienników systemu i zapytania o czasopismo Systemd Journalctl. Jeśli polecenie jest wywoływane bez dalszych parametrów, wyświetlana jest cała zawartość dziennika. Na szczęście można wdrożyć kilka strategii w celu filtrowania dzienników. Zobaczmy niektóre z nich.

Filtrowanie wiadomości według jednostek

Jedna z najbardziej przydatnych opcji, do których możemy przejść Journalctl Jest -u, która jest krótką wersją --jednostka. Dzięki tej opcji możemy filtrować zawartość czasopisma, aby tylko wiadomości z określonych SystemD-Unit przekazany jako zwracany argument opcji. Na przykład, aby wyświetlać tylko wiadomości pochodzące z NetworkManager.praca Jednostka, możemy uruchomić:

$ Journalctl -u NetworkManager-Dzienniki zaczynają się od środa 2020-07-01 21:47:23 Cest, koniec na sobotę 2020-07-25 15:26:59 Cest. -- 01 lipca 21:48:07 ERU Systemd [1]: Rozpoczęcie menedżera sieci… 01 lipca 21:48:07 ERU NetworkManager [1579]: [1593632887.7408] NetworkManager (wersja 1.22.10-1.FC32) zaczyna… (po raz pierwszy) 01 lipca 21:48:07 ERU NetworkManager [1579]: [1593632887.7413] Odczyt Config:/etc/NetworkManager/NetworkManager.Conf 01 lipca 21:48:07 ERU Systemd [1]: Rozpoczęcie menedżera sieci. 

Ponadto konkretna opcja jest poświęcona filtrowaniu tylko komunikatów jądra: -k, która jest krótką formą --Dmesg.

Filtrowanie dzienników według daty

Jeśli chcemy filtrować wiadomości przechowywane w czasopiśmie według daty, możemy użyć dwóch dedykowanych opcji: -S (Krótkie dla --od) I -U (Krótkie dla --dopóki). Obie opcje akceptują datę w formacie YYYY-MM-DD HH: MM: SS. Część „czasu” daty można pominąć, a w takim przypadku 00:00:00 zakłada się. Załóżmy, że chcemy filtrować dzienniki, zaczynając od bieżącej daty; Uruchomilibyśmy następujące polecenie:

$ Journalctl-Since 2020-07-25 


W celu dalszego ograniczenia dzienników z czasem 16:04:21 Do 16:04:26:

$ Journalctl--Since "2020-07-25 16:04:21"-Until "2020-07-25 16:04:26" 

Istnieje również seria aliasów: można je używać zamiast zwykłych dat:

Strunowy Oznaczający
"Wczoraj" 00:00:00 dnia przed obecnym
"Dzisiaj" obecny dzień
"jutro" Dzień po bieżącym
"Teraz" aktualny czas

Wyświetlanie tylko najnowszych dzienników

Jeśli uruchomimy Journalctl polecenie z -F (--podążać) Opcja, możemy wizualizować tylko najnowsze otrzymane dzienniki i nadal obserwować, ponieważ są do niej dołączone nowe dzienniki (to w zasadzie jak połączenie ogon z -F opcja). Z drugiej strony, jeśli chcemy po prostu wizualizować koniec dziennika, możemy użyć -mi opcja (--Pager-End).

Formatowanie wyjścia JournalCtl

Wyjście, które otrzymujemy podczas korzystania Journalctl można łatwo sformatować za pomocą dedykowanej opcji: -o, lub jego długa wersja, --wyjście. Podczas korzystania z tej opcji możemy określić szereg „stylów”. Wśród (wielu) innych:

  • krótki
  • gadatliwy
  • JSON-PETTY

krótki Format jest domyślnie: Jedna linia na wpis jest wyświetlana w wyjściu podobnym do tradycyjnego syslog:

01 lipca 21:48:07 ERU Systemd [1]: początkowe menedżer sieci… 

gadatliwy Zamiast tego format sprawia, że ​​wszystkie pola wpisu zostaną wyświetlone:

Środa 2020-07-01 21:48:07.603130 CEST [s=d61cdf3710e84233bda460d931ebc3bb;i=6be;b=1c06b8c553624a5f94e1d3ef384fb50d;m=2e82666;t=5a966922b0155;x=6668aad5e895da03] PRIORITY=6 _BOOT_ID=1c06b8c553624a5f94e1d3ef384fb50d _MACHINE_ID=afe15f1a401041f4988478695a02b2bf _HOSTNAME=eru SYSLOG_FACILITY=3 SYSLOG_IDENTIFIER=systemd _UID=0 _GID= 0 _transport = Journal _cap_effective = 3fffffffff Code_file = src/Core/Job.c Code_line = 574 COD_FUNC = JOB_LOG_BEGIN_STATUS_MESSAGE JOB_TYPE = Start Message_id = 7D4958E842DA4A758F6C1CDC7B36DCC5 _PID = 1 _COMM = Systemd _Exe =/usr/lib/Systemd/Systemd _SySteMd_CGroup.zakres _systemd_unit = init init.zakres _Systemd_Slice =-.Slice _Selinux_context = System_U: System_r: init_t: S0 _CMDLINE =/usr/lib/systemd/Systemd-Switched-Root--System--Deserialize 34 Komunikat = początkowe menedżer sieci… Job_id = 243 Unit = NetworkManager = NetworkManager.Service Invoction_id = 6416439e51ff4543a76bded5984c6cf3 _source_realtime_timestamp = 1593632887603130 


JSON-PETTY Format wyświetla wpisy jako JSON obiekty w sposób, który można czytać. W tym formacie wpisy są oddzielone nową linią:

„__REALTIME_TIMESTAMP”: „1593632887603541”, „Priorytet”: „6”, „_systemd_unit”: „init init”: „init init.zakres ”,„ _systemd_cgroup ”:"/init.zakres ”,„ _uid ”:„ 0 ”,„ _comm ”:„ Systemd ”,„ _Systemd_Slice ”:"-.slice", "_CAP_EFFECTIVE" : "3fffffffff", "_BOOT_ID" : "1c06b8c553624a5f94e1d3ef384fb50d", "_SELINUX_CONTEXT" : "system_u:system_r:init_t:s0", "__CURSOR" : "s=d61cdf3710e84233bda460d931ebc3bb;i=6be;b=1c06b8c553624a5f94e1d3ef384fb50d; m = 2e82666; t = 5a966922b0155; x = 6668aad5e895da03 ”,„ _hostname ”:„ erU ”,„ _PID ”:„ 1 ”,„ Message_id ”:„ 7d4958e842da4a758f6c1cdc7b36dcc5 ”,„ Code_d_id ”:„ 7d4958e842Da4a758f6c1cdc7b36dcc5 ”,„ Code_ Code_D_ID ” Początkowa menedżer sieci… ”,„ _exe ”:„/usr/lib/systemd/systemd ”,„ __monotonic_timestamp ”:„ 48768614 ”,„ _Transport ”:„ Journal ”,„ syslog_facility ”:„ 3 ”,„ jednostka ”:" NetworkManager.serwis ”,„ Job_id ”:„ 243 ”,„ Job_type ”:„ start ”,„ _gid ”:„ 0 ”,„ kod_file ”:„ src/core/job.c "," _machine_id ":" AFE15F1A401041F4988478695A02B2BF "," _CMDLINE ":"/usr/lib/Systemd/Systemd--Switched-Root--System--Deserialize 34 ",„ Syslog_identifier ”:„ Systemd ”,„ kod ”: „574”, „Invocation_id”: „6416439e51ff4543a76bded5984c6cf3”, „_source_realtime_timestamp”: „1593632887603130” 

Wnioski

W tym samouczku się zbliżyliśmy Journald Demon systemowy, który implementuje dziennik rejestrowania. Ten system rejestrowania ma być używany zamiast syslog, który był tradycyjnym systemem używanym w Linux. W wielu dystrybucjach, z jakiegoś powodu dwa systemy nadal współistnieją.

Widzieliśmy, co to jest Journald plik konfiguracyjny i jakie jest znaczenie niektórych ważnych opcji, które można użyć do modyfikowania jego zachowania, i dowiedzieliśmy się, jak możemy zapytać o czasopismo SystemD z Journalctl pożytek. Jeśli chcesz dowiedzieć się więcej Journald I Journalctl. Proponuję przeczytać odpowiednie instrukcje (Man Journald.conf I Man Journalctl są poleceniami, których szukasz).

Powiązane samouczki Linux:

  • Zaawansowane rejestrowanie i audyt w systemie Linux
  • Rzeczy do zainstalowania na Ubuntu 20.04
  • Linux Pliki konfiguracyjne: Top 30 Najważniejsze
  • Rzeczy do zrobienia po zainstalowaniu Ubuntu 20.04 Focal Fossa Linux
  • Pobierz Linux
  • Wprowadzenie do automatyzacji, narzędzi i technik Linuksa
  • Rzeczy do zrobienia po zainstalowaniu Ubuntu 22.04 JAMMY Jellyfish…
  • Czy Linux może uzyskać wirusy? Badanie podatności Linuksa…
  • Najlepszy Linux Distro dla programistów
  • Rzeczy do zainstalowania na Ubuntu 22.04