Systemd naplók megtekintése és kezelése a Journalctl segítségével

Rendszer- és folyamatnaplózás csupán kettő a legfontosabb előnyei közül a systemd-nek. Ha a naplófájlok szét vannak szórva a rendszerben, több alkalmazásra terjednek ki, és különböző folyamatok és démonok kezelik őket, az értelmezésük kihívást jelenthet. A systemd központosított megoldást kínál az összes kernel- és felhasználói szintű folyamatnapló kezelésére egy napló (journal) néven ismert gyűjtőhelyen. További információt a systemd-ről a a systemd szolgáltatások és egységek systemctl segítségével történő kezeléséről szóló útmutatónkban olvashat. A szolgáltatások, az initrd, a kernelek stb. által generált összes üzenetet a naplóban a journal démon kezeli. Ennek az útmutatónak a célja annak bemutatása, hogyan lehet hozzáférni és kezelni a napló adatait a journalctl használatával.

Alapvető kiindulópont

Függetlenül attól, hogy egy üzenet honnan származik, a systemd egyik elsődleges törekvése, hogy lehetővé tegye a kezelésük központosítását. Mivel a rendszerindítási folyamatok nagy részét és a szolgáltatáskezelés jelentős részét a systemd folyamat végzi, a naplók összeállításának és elérésének módját szabványosítani kell. A journald az összes elérhető forrásból származó adatot egyetlen átfogó eszközbe gyűjti, és bináris formátumban tárolja azokat. Ez lehetővé teszi, hogy az adatok könnyen elérhetők legyenek a dinamikus és egyszerű kezeléshez.

Ez a megközelítés számos kulcsfontosságú előnnyel jár. Azzal, hogy van egy központi hely az összes adat összegyűjtésére, a rendszergazdák szűrhetik és csak a szükséges adatokat jeleníthetik meg. Például megtekinthetők a három rendszerindítással ezelőtti indítási adatok. Ez jelentheti a kapcsolódó szolgáltatások bejegyzéseinek egymás utáni naplózását is, és hatékonyabban nyomon követhető a köztük lévő kommunikációs probléma.

A bináris tárolásnak köszönhetően az adatok többféle kimeneti formátumban is megjeleníthetők, a felhasználó aktuális igényeitől függően. Például egy napi napló megtekinthető szabványos syslog formátumban. De ha a szolgáltatáskimaradások trendjeit grafikon formájában szeretné ábrázolni, a bejegyzés kimenete lehet egy JSON objektum, így használhatóvá válik egy grafikonkészítő szolgáltatással. Ha a helyzetnek megfelelően formátumot kell váltania, nincs szükség konverzióra, mivel az adatok binárisak, és nem egyszerű szövegként íródnak a lemezre.

Az igényektől függően a systemd naplót bevezetheti egy meglévő syslog mellé, vagy akár fel is válthatja annak funkcióját. A systemd akár ki is egészítheti a meglévő naplózási mechanizmusokat. Például egyetlen rendszeren futó több szolgáltatás összesített adatai összefonódhatnak egyetlen rendszeren a systemd naplóval.

A rendszeridő beállítása

A systemd alapértelmezés szerint a helyi idő szerint jeleníti meg az eredményeket, ami a bináris naplózás egyik előnye a naplóbejegyzések megtekinthetőségét illetően. Alternatív megoldásként UTC-ben is megtekinthetők. Ezért fontos megbizonyosodni arról, hogy az időzóna helyesen van-e beállítva, mielőtt elkezdené a naplózást. Ehhez a systemd egy timedatectl nevű eszközzel van felszerelve. Kezdjük azzal, hogy megnézzük, milyen időzónák használhatók, a list-timezones opcióval megjelenítve a listát:

Miután megtalálta a szervere helyének megfelelő időzónát, az időzónát a set-timezone opcióval állíthatja be:

Annak tesztelésére és ellenőrzésére, hogy az időzóna most már megfelelően jelenik-e meg, használhatja a timedatectl parancsot önmagában vagy a 'status' hozzáadásával:

Az első sor a helyi időt mutatja. Ennek a sornak a helyi régiónak megfelelő helyes időt kell tartalmaznia.

Általános naplóbejegyzések megtekintése

A journalctl parancs lehetővé teszi a journald démon által összegyűjtött naplók megtekintését. A journalctl használatakor a rendszer minden naplóbejegyzése megjelenik a képernyőn, a legrégebbi bejegyzésekkel a tetején. A teljes adatlista azonban több tízezer sor hosszú lesz.

Azok, akik használtak már szabványos syslog naplózást, ismerősnek fogják találni a formátumot, de fontos észben tartani, hogy a syslog módszerrel ellentétben ez az adatösszeállítás számos forrásból származik. A naplók tartalmazni fogják a korai rendszerindítási folyamatot, az initrd-t és a rendszermagot, valamint az alkalmazások szabványos hibaüzeneteit is.

Most, hogy a helyi idő be van állítva, minden bejegyzés helyi idő szerinti időbélyeggel fog kezdődni, és ez a rendszeren jelenleg tárolt összes naplóhoz elérhető, így az összes logika ezen új információk használatával jelenik meg. Azonban nem vagy a helyi időhöz kötve. A –utc jelző használatával az időbélyegeket UTC-ben is megjelenítheted:

Napló szűrése idő szerint

Fantasztikus, hogy ennyi adat áll rendelkezésre, de ezek átfésülése és befogadása, nem is beszélve a mentális feldolgozásukról, ijesztő feladat lehet. Ezt szem előtt tartva elérkeztünk a journalctl funkció legfontosabb részéhez: a szűréshez.

Naplók megjelenítése a jelenlegi rendszerindításból

Ha a legutóbbi újraindításból származó adatokat keresed a naplóban, használhatod a journalctl funkciót a -b jelzővel. Ez megjeleníti a rendszer legutóbbi újraindításából származó összes vonatkozó naplóinformációt. Ez a parancs lehetővé teszi a jelenlegi munkakörnyezet szempontjából legfontosabb információk megtalálását és kezelését:

Ha a felhasználó úgy dönt, hogy nem értékeli ki az egyes bejegyzéseket külön-külön, a journalctl több mint egy napnyi rendszerindítást fog mutatni, amelyek kényelmes „Reboot” elválasztókkal jelennek meg a journalctl-ben. Ez segít logikailag elkülöníteni a különböző rendszerindítási munkamenetekből származó információkat az áttekintéshez:

Korábbi rendszerindítások információi

Baur a jelenlegi rendszerindítási információk megjelenítése általában a leghasznosabb, vannak olyan helyzetek, amikor a korábbi rendszerindítások információi is hasznosnak bizonyulnak. A Journal több korábbi rendszerindítás adatait is elmenti, így a journalctl könnyen meg tudja jeleníteni az információkat bármely időszakra vonatkozóan.

Bizonyos disztribúciók letiltják a korábbi rendszerindítási információk mentését, míg másoknál ez alapértelmezés szerint engedélyezve van. A tartós rendszerindítási információk engedélyezése a napló tárolására szolgáló könyvtár létrehozásával érhető el, a következő beírásával:

Alternatív megoldásként a következő módon szerkesztheted a journal konfigurációs fájlját:

A Storage= opció „persistent” értékre állítása a [Journal] szakasz alatt engedélyezi a tartós naplózást:

Miután ez engedélyezve van, a journalctl elérhetővé tesz bizonyos parancsokat, amelyek segítenek ezeket a rendszerindításokat felosztási egységként megjelölni. A journald-ben rögzített rendszerindítások megtekintéséhez használhatod a –list-boots opciót a journalctl-en keresztül:

Amint az ábrán látható, minden rendszerindítás külön sorban szerepel, ahol az első oszlop a korábbi rendszerindításokat tükrözi a legrégebbitől a legújabbig. Ha abszolútabb hivatkozásra van szükség, a második oszlop tartalmazza a rendszerindítás azonosítóját. Ezután két időmegjelölés látható. Az első vagy a második oszlopból származó információk használhatók az adott rendszerindítás naplóinformációinak megjelenítésére. Például használhatod a -b jelzőt a -1 relatív rendszerindítás-mutatóval a legutóbbi előtti újraindítás információinak megtekintéséhez:

Hasonlóképpen, a második oszlopból származó rendszerindítási azonosító is használható ilyen módon:

Időablakok

A rendszerindítások azonosító (ID) alapján történő megtekintése egy lehetőség, de gyakran hasznosabb, ha a korábbi indításokra egy múltbeli időablak alapján hivatkozhatunk, amely nem feltétlenül igazodik konkrét indításokhoz. Ez például olyan helyzetben releváns, amikor hosszú ideje futó szerverekkel dolgozunk, amelyeket nem indítanak újra gyakran. Az időkorlátok szűrése tetszőleges időkorlátokkal végezhető el. Ez csak a meghatározott időablakba eső újraindításokról jelenít meg információkat. Ennek az ablaknak a paramétereit a –since és –until opciókkal jelöljük. Az időopciókhoz számos formátum áll rendelkezésre. Az abszolút időérték formátuma a következő:

Tehát, ha a 2015. január 10. 17:15 óta történt összes rendszerindítást szeretné látni, írja be a következő parancsot:

Ha bármelyik összetevőt elhagyja, beépített alapértelmezések lépnek életbe. Továbbá, ha a dátum marad ki, az aktuális dátum lesz az alapértelmezett. Ha az idő összetevő hiányzik, akkor az éjfél az alapértelmezett (00:00:00). Ha a másodperceket hagyja le az idő összetevőről, azok az adott perc kezdőpontjára (00) fognak alapértelmezés szerint beállni:

A journal képes megérteni az idővel kapcsolatos rövidítéseket, mint például a „today”, „tomorrow”, „yesterday” és „now”. Az „ago” szót a megelőző „-” és „+” minősítőkkel együtt használva mondatszerű parancsokat hozhatunk létre:

Ha értesítést kapott egy 9:00-kor kezdődő szolgáltatáskimaradásról, és szeretné ellenőrizni a journal naplóit egy órával ezelőttiig, ezt a következőképpen teheti meg:

Amit látható, a kívánt bejegyzések megtekintéséhez szükséges rugalmas időablak meghatározása rendkívül egyszerű.

Szűrés a minket érdeklő üzenetek szerint

A journal időkorlátok szerinti szűrésén kívül az adatok a minket érdeklő szolgáltatás-összetevő alapján is szűrhetők. A Systemd erre számos módszert kínál.

Unit szerint

Vitathatatlanul a leghasznosabb szűrési paraméter a minket érdeklő unit (egység) szerinti szűrés. A unit szerinti szűréshez a -u opció használható. Ha például az Nginx unitra vonatkozó összes naplót szeretné látni, írja be a következő parancsot:

A valóságban ezt érdemes egy időszűrővel párosítani a releváns sorok megjelenítéséhez. Ha ellenőrizni szeretné a fenti szolgáltatást és annak mai teljesítményét, a következőt teheti:

Ez különösen hasznos, ha kihasználja a journal azon képességét, hogy több – különösen együttműködő – unitból gyűjtse össze a rekordokat. Ha az Nginx folyamat egy PHP-FPN unit-hoz kapcsolódik a dinamikus tartalomfeldolgozáshoz, a bejegyzések időrendi sorrendben összefésülhetők mindkét unit megadásával:

Ez nagyban segíthet a programok közötti interakciók észlelésében, és megkönnyíti a rendszerek hibakeresését az egyes folyamatok helyett.

Csoportazonosító (GID), folyamat vagy felhasználó szerint

Sok szolgáltatás számos alfolyamatot (gyermekfolyamatot) indít el egy-egy konkrét feladat elvégzésére. Ha egy adott folyamat azonosítója (ID) rendelkezésre áll, a szűrés a _PID mező megadásával is elvégezhető. Ha a keresett PID a 8088, a következőket teheti:

Előfordulhat az is, hogy egy bizonyos csoport vagy felhasználó által naplózott bejegyzéseket szeretne látni. Ez a _GID és _UID szűrők használatával érhető el. Ha egy webszerver a www-data felhasználó alatt fut, a következő paranccsal megtalálhatja a szükséges azonosítót:

Ezt az azonosítót használva megtekintheti a megfelelő journal-eredményeket:

Systemd számos mezőt tesz elérhetővé szűrési célokra. Egyes mezőket a journald alkalmaz a rendszerből a naplózás időpontjában gyűjtött információk alapján, míg másokat az éppen naplózott folyamat ad át.

A _PID előtag azt jelzi, hogy az információ a naplózás időpontjában került összegyűjtésre a rendszerből. A journal automatikusan rögzíti és indexeli a PID-et a naplózási folyamat során, hogy a szűrési lehetőség később elérhető legyen. Az elérhető journal mezők megismeréséhez beírhatja a következőt:

Ezek közül néhánnyal később foglalkozunk ebben az útmutatóban, de most érintünk néhány más hasznos opciót, amelyek ezekre a mezőkre vonatkoznak. Ha egy adott journal mező összes elérhető értékét szeretné látni, használhatja a -F opciót. Ha látni szeretné, hogy a systemd journal milyen csoportazonosítókkal (group ID) rendelkezik, a következőt teheti:

Ez segíthet a szűrők összeállításában azáltal, hogy megadja a journal csoportazonosító (group ID) mezője által tárolt értékek teljes listáját.

Összetevő elérési útja alapján

A szűrés egy elérési út megadásával is elvégezhető. Ha az elérési út egy futtatható fájlra mutat, a journalctl bejegyzései akkor jelennek meg, ha érintik az adott futtatható fájlt. Ha a keresett futtatható fájl a „bash”, a következőt írhatja be:

Bár ez néha nem lehetséges, ha a futtatható fájl egysége (unit) elérhető, az egy tisztább és informatívabb módszert nyújthat a szűrésre.

Rendszermag (kernel) üzenetek megjelenítése

A kernel üzenetek, amelyek általában a dmesg kimenetében találhatók, a journalból is lekérhetők. Ahhoz, hogy csak ezek az üzenetek jelenjenek meg, a -k vagy a -dmesg jelzőket használjuk a parancs részeként:

Alapértelmezés szerint az aktuális rendszerindítás (boot) üzenetei jelennek meg, de a korábbi indítások is megadhatók a korábban említett kiválasztási jelző használatával. Ha az öt indítással ezelőtti üzeneteket keresi, a következő beírásával megkapja a szükséges eredményeket:

Prioritás alapján

A rendszeradminisztrátorok gyakran előnyben részesítik a prioritás szerinti szűrést. Az alacsony prioritású naplók, bár gyakran hasznosak, zavaróak lehetnek és sok felesleges információt tartalmazhatnak, ami megnehezíti az elemzést. A journalctl -p opciójának használatával csak a megadott prioritású üzenetek jelennek meg, kiszűrve az összes többi prioritást. Ha a hiba (error) szintű vagy annál magasabb bejegyzéseket szeretné megjeleníteni, írja be a következőt:

Ez a parancs visszaadja az összes hiba (error), riasztás (alert), vészhelyzet (emergency) vagy kritikus (critical) jelölésű üzenetet, mivel a journal a szabványos syslog üzenetküldési szinteket használja. A prioritási szintek egy numerikus érték alapján vannak meghatározva, a legmagasabbtól a legalacsonyabbig rangsorolva:

• 0: emerg
• 1: alert
• 2: crit
• 3: err
• 4: warning
• 5: notice
• 6: info
• 7: debug

A fentiek bármelyike felcserélhetően használható a -p opcióval. A fent vázolt prioritások bármelyikének kiválasztása kiszűri az összes prioritást az adott szinten és a felette lévő szinteken.

A megjelenítés módosítása a Journalban

A bejegyzések kiválasztására szolgáló szűrés mellett más módszereink is vannak a kimenet módosítására, a journalctl megjelenítésének az igényeinkhez való igazítására.

Kimenet csonkolása/kiterjesztése

A kimenet nézetét úgy állíthatjuk be, hogy szabályozzuk, hogy a journalctl zsugorítsa vagy kibontsa az adatokat. A journalctl alapértelmezése a teljes bejegyzés megjelenítése, a hosszabb bejegyzéseket a képernyő jobb szélére futtatva. A bejegyzéseket teljes egészében a jobb nyíl gombbal görgetve tekintheti meg. A felhasználó dönthet úgy is, hogy inkább csonkolja a kimenetet, három ponttal jelölve azokat a sorokat, amelyek egyébként lefutnának a képernyőről. Ehhez a –no-full opció használható:

Alternatív megoldásként a -a jelző használatával azt is engedélyezheti, hogy a kijelző mindent megjelenítsen, függetlenül a hossztól vagy a nem nyomtatható karakterek jelenlététől:

Kimenet a szabványos kimenetre (Standard Out)

A journalctl alapértelmezés szerint egy lapozóba (pager) jeleníti meg a kimenetet, de ha szövegszerkesztő eszközökkel szeretné módosítani az adatokat, valószínűleg a szabványos kimenetre (standard output) van szüksége. Ezt a –no-pager opcióval érheti el:

A felhasználó igényeitől függően ez átirányítható egy lemezen lévő fájlba vagy egy feldolgozó segédprogramba.

Kimeneti formátumok

Az adatokat mindig könnyebb elemezni, ha könnyebben emészthető formátumban jelennek meg. A napló (journal) többféle megjelenítési lehetőséget kínál a -o minősítővel, amelyet egy konkrétan meghatározott formátum követ.

Ha a naplóbejegyzéseket JSON formátumban szeretné exportálni, azt a következő módon teheti meg:

Ez a stratégia különösen hasznos elemző segédprogramok használatakor. A json-pretty formátum jobban megjelenítheti az adatszerkezeteket, mielőtt átadná azokat a JSON-feldolgozónak:

Számos formátumot használhat a megjelenítéshez:

• cat: Csak magát az üzenetmezőt (message) jeleníti meg.
• export: Átvitelre vagy biztonsági mentésre alkalmas bináris formátum.
• json: Szabványos JSON, soronként egy bejegyzéssel.
• json-pretty: Jobb emberi olvashatóságra formázott JSON
• json-sse: JSON formátumú kimenet, amely kompatibilis a szerver által küldött eseményekkel (server-sent events)
• short: Az alapértelmezett syslog stílusú kimenet
• short-iso: Az alapértelmezett formátum kiegészítve az ISO 8601 szerinti valós idejű időbélyegekkel.
• short-monotonic: Az alapértelmezett formátum monoton időbélyegekkel.
• short-precise: Az alapértelmezett formátum mikroszekundumos pontossággal
• verbose: Megjeleníti a bejegyzéshez elérhető összes naplómezőt, beleértve azokat is, amelyek általában belsőleg rejtve vannak.

A fenti opciók lehetővé teszik, hogy a napló az Ön által preferált formátumban jelenjen meg.

Aktív folyamatfigyelés

A napló lehetővé teszi az aktív vagy a közelmúltbeli tevékenységek figyelését anélkül, hogy más eszközt kellene bevonnia. Ezt a journalctl paranccsal és egy „tail” funkcióval teheti meg.

• Legutóbbi naplók megjelenítése

A -n opció használata (amely pontosan úgy működik, mint a tail -n parancs) lehetővé teszi bizonyos számú rekord megjelenítését:

A megjeleníteni kívánt bejegyzések száma a -n minősítő után megadott konkrét számmal határozható meg:

• A naplók követése

A -f jelzővel aktívan is követheti a naplókat, amint azok a rendszerbe íródnak. Ez szintén ugyanúgy működik, mint a tail -f parancs:

A napló karbantartása

A naplók helyet foglalnak. Érdemes megvizsgálni ezt a kérdést, esetleg a régebbi naplók törlésével helyet szabadíthat fel.

Aktuális lemezhasználat lekérdezése

A –disk-usage jelző segíthet azonosítani, hogy a naplózás jelenleg mennyi helyet foglal el a lemezen:

Régi naplók törlése

A systemd 218-as (és az azt követő) verzióitól kezdve kétféleképpen csökkentheti a napló méretét. Az egyik a –vacuum-size opció. Ez a méret megadásával képes csökkenteni a naplót. Más szóval, a régebbi bejegyzések addig törlődnek a naplóból, amíg az elfoglalt hely el nem éri a kért paramétert:

A –vacuum-time opció egy határidő megadásával csökkentheti a napló helyfoglalását: az ezen túli bejegyzések törlődnek, míg a megadott időpont után létrehozottak megmaradnak. Ha csak az elmúlt naptári év bejegyzéseit szeretné megtartani, a következőt használhatja:

A napló növekedésének korlátozása

Azt is korlátozhatja, hogy a napló mennyi helyet foglaljon el. Ezt az /etc/systemd.journald.conf fájl szerkesztésével érheti el. A napló növekedése a következő módszerek bármelyikével korlátozható:

• SystemMaxUse=: Azt a maximális lemezterületet jelöli, amelyet a napló a tartós tárhelyen használhat.
• SystemKeepFree=: Azt jelöli, hogy mennyi szabad helyet kell hagyni, amikor a naplóbejegyzések hozzáadásra kerülnek a tartós tárhelyen.
• SystemMaxFileSize=: Meghatározza, hogy a naplófájlok mekkorára növekedhetnek a tartós tárhelyen történő rotációig.
• RuntimeMaxUse=: Meghatározza, hogy mennyi lemezterület használható fel az illékony tárhelyen (a /run fájlrendszeren belül).
• RuntimeKeepFree=: Amikor adatokat ír az illékony tárhelyre, ez a funkció jelzi azt a helymennyiséget, amelyet más célokra kell fenntartani (a /run fájlrendszeren belül).
• RuntimeMaxFileSize=: Azt jelzi, hogy egy egyes napló mekkora helyet foglalhat el az illékony tárhelyen (a /run fájlrendszeren belül), mielőtt rotálásra kerülne.

Ezek a beállítások mind segíthetnek a napló tárhelyfogyasztásának szabályozásában. Fontos megjegyezni, hogy a SystemMaxFileSize és a RuntimeMaxFileSize opciók az archivált fájlokat célozzák meg a megadott korlátok eléréséhez. Ezt a tényt fontos szem előtt tartani a fájlok számának értelmezésekor a vacuuming (tisztítási) műveletek után.

Összegzés

Nyilvánvaló, hogy a systemd napló egy rendkívül hasznos eszköz, amelynek előnyei leginkább a naplók központosított jellegéből és a rögzített metaadatok hatalmas mennyiségéből származnak. A napló kiterjedt funkciói a journalctl parancs használatával aknázhatók ki, ami egyszerűbb módszert kínál az alkalmazáskomponensek összefüggéseinek hibakeresésére, valamint a kiterjedt rendszerelemzésre.

Kellemes számítógépezést!