Systemd-logs bekijken en manipuleren met Journalctl

Systeem- en procesregistratie zijn slechts twee van de meest cruciale voordelen van systemd. Wanneer logs verspreid zijn over het systeem, meerdere applicaties beslaan en door verschillende processen en daemons worden afgehandeld, kan het een uitdaging zijn om ze te interpreteren. Systemd biedt een gecentraliseerde oplossing voor het beheren van alle kernel- en userland-proceslogs in een verzamelmedium dat bekendstaat als een journal. Meer informatie over systemd vindt u in onze handleiding over het beheren van systemd-services en -units met systemctl. Alle berichten die door services, initrd, kernels, enz. in een journal worden gegenereerd, worden afgehandeld door de journal-daemon. Het doel van deze gids is om te illustreren hoe u de gegevens van het journal kunt openen en manipuleren met behulp van journalctl.

Basisprincipe

Ongeacht waar een bericht vandaan komt, is een van de belangrijkste doelen van systemd om het beheer ervan te centraliseren. Aangezien veel van de opstartprocessen en een groot deel van het servicebeheer worden afgehandeld door het systemd-proces, moet de manier waarop de logs worden verzameld en geraadpleegd worden gestandaardiseerd. Journald verzamelt gegevens uit alle beschikbare bronnen in één allesomvattende tool en slaat deze op in een binair formaat. Hierdoor zijn de gegevens direct beschikbaar voor dynamische en eenvoudige manipulatie.

Deze aanpak heeft verschillende belangrijke voordelen. Door een centrale plek te hebben om alle gegevens te verzamelen, kunnen beheerders filteren en alleen de gegevens weergeven die ze nodig hebben. Men kan bijvoorbeeld opstartgegevens bekijken van drie systeemstarts geleden. Het kan ook betekenen dat vermeldingen van gerelateerde services opeenvolgend worden gelogd, waardoor een communicatieprobleem tussen deze services effectiever kan worden opgespoord.

Dankzij de binaire opslag kunnen gegevens in verschillende uitvoerformaten worden weergegeven, afhankelijk van de behoeften van de gebruiker op dat moment. Een dagelijks logboek kan bijvoorbeeld worden bekeken in een standaard syslog-indeling. Maar als u serviceonderbrekingen in de vorm van een grafiek wilt analyseren, kan de vermelding worden uitgevoerd als een JSON-object, waardoor het bruikbaar is met een grafische service. Wanneer u van formaat moet veranderen op basis van situationele vereisten, is er geen conversie nodig omdat de gegevens binair zijn en niet in platte tekst naar de schijf worden geschreven.

Afhankelijk van de behoeften kunt u het systemd-journal implementeren met een bestaande syslog of kan het de functionaliteit vervangen. Systemd kan zelfs bestaande loggingmechanismen aanvullen. Zo kunnen bijvoorbeeld van meerdere services op een enkel systeem de verzamelde gegevens worden verweven op een enkel systeem met het systemd-journal.

De systeemtijd instellen

Systemd geeft resultaten standaard weer in lokale tijd, een voordeel van binaire journal-logging in de manier waarop logbestanden kunnen worden bekeken. Als alternatief kunnen ze in UTC worden bekeken. Daarom is het belangrijk om ervoor te zorgen dat de tijdzone correct is ingesteld voordat u aan de slag gaat met de journal-logging. Hiervoor is systemd uitgerust met een tool genaamd timedatectl. We beginnen met te kijken welke tijdzones beschikbaar zijn door een lijst weer te geven met de optie list-timezones:

Na het vinden van de tijdzone die overeenkomt met de locatie van uw server, kan de tijdzone worden ingesteld met de optie set-timezone:

Om te testen en te controleren of de tijdzone nu correct wordt weergegeven, kunt u het timedatectl-commando afzonderlijk gebruiken of door ‘status:’ toe te voegen

De eerste regel geeft de lokale tijd weer. Deze regel moet de juiste tijd voor uw lokale regio bevatten.

Algemene logboekweergave

Met het commando journalctl kunt u de logs bekijken die de journald-daemon heeft verzameld. Wanneer u journalctl gebruikt, wordt elke journal-vermelding van het systeem op het scherm weergegeven, waarbij de oudste vermeldingen bovenaan staan. De volledige lijst met gegevens zal echter tienduizenden regels lang zijn.

Degenen die standaard syslog-logging hebben gebruikt, zullen het formaat bekend vinden, maar het is belangrijk om in gedachten te houden dat deze verzameling gegevens uit vele bronnen is opgenomen, in tegenstelling tot de syslog-methode. De logs bevatten het vroege opstartproces, de initrd en de kernel, evenals de standaardfouten van applicaties.

Nu de lokale tijd is ingesteld, beginnen alle vermeldingen met tijdstempels in de lokale tijd, en dit is beschikbaar voor elk logboek dat momenteel op het systeem is opgeslagen, waarbij alle logica wordt weergegeven met behulp van deze nieuwe informatie. Je bent echter niet beperkt tot de lokale tijd. Met de –utc-vlag kun je tijdstempels ook in UTC weergeven:

Logboek filteren op tijd

Het hebben van zoveel gegevens is fantastisch, maar erdoorheen kammen en het kunnen opnemen, om nog maar te zwijgen van het mentaal verwerken ervan, kan een ontmoedigende taak zijn. Met dit in gedachten komen we bij het belangrijkste deel van de journalctl-functie: filteren.

Logboeken weergeven van de huidige opstart

Als je op zoek bent naar de gegevens in het logboek van de laatste herstart, kun je de journalctl-functie gebruiken met een -b-vlag. Dit toont alle relevante logboekinformatie van de meest recente herstart van je systeem. Deze opdracht stelt je in staat om de informatie te vinden en te beheren die het meest relevant is voor de huidige werkomgeving:

Als de lezer ervoor kiest om niet elke afzonderlijke vermelding te evalueren, toont journalctl meer dan een dag aan opstartsessies die in journalctl worden weergegeven met handige 'Reboot'-scheidingstekens. Dit helpt om informatie van verschillende opstartsessies logisch te scheiden voor beoordeling:

Informatie over eerdere opstartsessies

Hoewel het weergeven van informatie over de huidige opstart meestal het meest nuttig is, zijn er situaties waarin informatie over eerdere opstartsessies nuttig kan zijn. Journal slaat informatie op van meerdere eerdere opstartsessies, zodat journalctl de informatie voor elke tijdsperiode eenvoudig kan weergeven.

Bepaalde distributies schakelen het opslaan van eerdere opstartinformatie uit, terwijl andere dit standaard hebben ingeschakeld. Het inschakelen van de persistente opstartinformatie kan worden bereikt door een map te maken voor de opslag van het logboek door het volgende te typen:

Als alternatief kun je het configuratiebestand van het logboek op de volgende manier bewerken:

Door de optie Storage= in te stellen op “persistent” onder de sectie [Journal] wordt persistente logboekregistratie ingeschakeld:

Zodra dit is ingeschakeld, stelt journalctl bepaalde opdrachten beschikbaar die je helpen deze opstartsessies aan te duiden als verdelingseenheden. Om de opstartsessies te bekijken die in journald zijn geregistreerd, kun je de optie –list-boots gebruiken via journalctl:

Zoals geïllustreerd, wordt elke opstart op een eigen regel weergegeven, waarbij de eerste kolom de eerdere opstartsessies weerspiegelt in volgorde van oudst naar meest recent. Als een meer absolute referentie nodig is, bevat de tweede kolom de opstartidentificatie. Daarna worden er twee tijdspecificaties weergegeven. Informatie uit de eerste of de tweede kolom kan worden gebruikt om de logboekinformatie van de specifieke opstart weer te geven. Je kunt bijvoorbeeld de -b-vlag gebruiken met de relatieve opstartpointer -1 om informatie te bekijken van de op één na meest recente herstart:

Op dezelfde manier kan de boot-id uit de tweede kolom ook op deze manier worden gebruikt:

Tijdsvensters

Het bekijken van boots op id is één optie, maar het is vaak nuttiger om te kunnen verwijzen naar eerdere boots via een tijdsvenster in het verleden dat niet noodzakelijkerwijs overeenkomt met specifieke boots. Dit is bijvoorbeeld relevant in een situatie waarin men werkt met langdurig draaiende servers die niet vaak opnieuw worden opgestart. Het filteren van tijdslimieten kan worden gedaan met willekeurige tijdslimieten. Dit toont alleen informatie over de reboots die binnen een specifiek tijdsvenster vallen. De parameters van dit venster worden aangeduid met de opties –since en –until. Er zijn verschillende formaten beschikbaar voor tijdsopties. Het absolute tijdwaardeformaat is als volgt:

Dus als u alle boots wilt zien sinds 10 januari 2015 om 17:15 uur, typt u de volgende opdracht:

Als een van de componenten wordt weggelaten, zijn er ingebouwde standaardwaarden. Bovendien, als een datum wordt weggelaten, wordt standaard de huidige datum gebruikt. Als de tijdscomponent ontbreekt, is middernacht de standaardwaarde (00:00:00). Als u de seconden weglaat uit de tijdscomponent, worden deze standaard ingesteld op het beginpunt van die minuut (00):

Het journaal begrijpt tijdgerelateerde snelkoppelingen zoals „today”, „tomorrow”, „yesterday” en „now”. Woorden als „ago”, in combinatie met de voorafgaande kwalificaties „-” en „+”, kunnen worden gebruikt om een opdracht in de vorm van een zin te construeren:

Als u op de hoogte bent gesteld van een onderbroken service die om 9:00 uur begon en u wilt de journaallogs controleren tot een uur geleden, dan kunt u dat als volgt doen:

Zoals u ziet, is het definiëren van een flexibel tijdsvenster voor het bekijken van de gewenste vermeldingen heel eenvoudig.

Filteren op berichtinteresse

Naast het filteren van het journaal op tijdsbeperkingen, kunnen de gegevens ook worden gefilterd op basis van de gewenste servicecomponent. Systemd biedt verschillende methoden om dit te doen.

Op unit

De meest nuttige filterparameter is waarschijnlijk die voor de gewenste unit. Om op unit te filteren, kan de optie -u worden gebruikt. Als u bijvoorbeeld alle logs wilt zien die betrekking hebben op de Nginx-unit, typt u de volgende opdracht:

In de praktijk wilt u dit waarschijnlijk koppelen aan een tijdsfilter om de relevante regels weer te geven. Als u de bovenstaande service wilt controleren en wilt zien hoe deze vandaag heeft gepresteerd, kunt u het volgende doen:

Dit is vooral handig wanneer u gebruikmaakt van de mogelijkheid van het journaal om records van meerdere units samen te voegen, met name samenwerkende units. Als het Nginx-proces is verbonden met een PHP-FPN-unit voor dynamische inhoudsverwerking, kunnen de vermeldingen in chronologische volgorde worden samengevoegd door beide units op te geven:

Dit kan enorm helpen bij het waarnemen van programma-interactie en maakt het debuggen van systemen in plaats van individuele processen eenvoudiger.

Op groeps-ID, proces of gebruiker

Veel services starten een groot aantal sub-processen (child-processen) om specifiek werk uit te voeren. Als de ID van een specifiek proces beschikbaar is, kan er ook worden gefilterd door het veld _PID op te geven. Als de gewenste PID 8088 is, kan het volgende worden gedaan:

Mogelijk wilt u ook vermeldingen zien die zijn gelogd door een specifieke groep of een specifieke gebruiker. Dit kan worden bereikt door de filters _GID en _UID te gebruiken. Als een webserver onder de gebruiker www-data draait, kan het volgende de benodigde ID vinden:

Met behulp van die ID kunt u vervolgens de gefilterde journaalresultaten bekijken:

Systemd stelt veel velden beschikbaar voor filterdoeleinden. Sommige velden worden door journald toegepast op basis van informatie die tijdens het loggen van het systeem is verzameld, terwijl andere worden doorgegeven vanuit het proces dat momenteel wordt gelogd.

Een pre-kwalificatie van _PID geeft aan dat de informatie is verzameld van het systeem op het moment van loggen. Het journaal registreert en indexeert de PID automatisch tijdens het logproces om de filtermogelijkheid later beschikbaar te maken. Om meer te weten te komen over de beschikbare journaalvelden, kun je typen:

We zullen een aantal hiervan later in deze gids bespreken, maar voor nu zullen we ingaan op enkele andere nuttige opties met betrekking tot deze velden. Als je alle beschikbare waarden voor een specifiek journaalveld wilt zien, kun je de optie -F gebruiken. Als je wilt zien wat het systemd-journaal heeft voor groeps-ID's, kan het volgende worden gedaan:

Dit kan helpen bij het construeren van filters door een volledige lijst te geven van waarden die het groeps-ID-veld van het journaal heeft opgeslagen.

Op componentpad

Filteren kan ook worden uitgevoerd door een padlocatie op te geven. Als het pad naar een uitvoerbaar bestand verwijst, worden vermeldingen in journalctl weergegeven als ze betrekking hebben op dat uitvoerbare bestand. Als het interessante uitvoerbare bestand 'bash' is, kun je typen:

Hoewel dit soms niet mogelijk is, kan het, als de unit van het uitvoerbare bestand beschikbaar is, een duidelijkere en informatievere methode voor filteren opleveren.

Kernelberichten weergeven

De kernelberichten, die doorgaans in de dmesg-output te vinden zijn, kunnen ook uit het journaal worden opgehaald. Om alleen deze berichten weer te geven, gebruiken we de vlaggen -k of -dmesg als onderdeel van ons commando:

Berichten van de huidige boot worden standaard weergegeven, maar eerdere boots kunnen worden gespecificeerd met behulp van de eerder genoemde selectievlag. Als je op zoek bent naar berichten van vijf boots geleden, levert het typen van dit de benodigde resultaten op:

Op prioriteit

Systeembeheerders filteren vaak bij voorkeur op prioriteit. Logs met een lage prioriteit zijn vaak nuttig om te bekijken, maar kunnen ook verwarrend zijn en veel afleiding bevatten, waardoor ze tijdens de analyse minder goed te verwerken zijn. Het gebruik van de optie -p in journalctl geeft alleen berichten van een specifieke prioriteit weer, waarbij alle andere prioriteiten worden weggefilterd. Als je vermeldingen van het foutniveau of hoger wilt weergeven, voer dan het volgende in:

Dat commando retourneert alle berichten die zijn aangeduid als errors, alert, emergency of critical, waarbij het journaal de standaard syslog-berichtniveaus gebruikt. Prioriteitsniveaus zijn gedefinieerd op basis van een numerieke waarde, gerangschikt van hoog naar laag:

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

Elk van de bovenstaande is uitwisselbaar te gebruiken met de optie -p. Als je een van de hierboven beschreven prioriteiten selecteert, worden alle prioriteiten op dat niveau en hoger gefilterd.

De weergave in het journaal aanpassen

Naast het gebruik van filtering voor de selectie van vermeldingen, hebben we andere methoden om de uitvoer aan te passen, zodat de weergave van journalctl aansluit op onze behoeften.

Uitvoer afkappen/uitvouwen

We kunnen de weergave van onze uitvoer aanpassen door in te stellen of journalctl de gegevens verkleint of uitvouwt. Standaard toont journalctl de volledige vermelding, waarbij langere vermeldingen naar de rechterkant van het scherm doorlopen. Je kunt de vermeldingen in hun geheel bekijken door met de pijl-rechts-toets te scrollen. Een gebruiker kan er de voorkeur aan geven de uitvoer af te kappen, waarbij een weglatingsteken wordt weergegeven op de regels die anders van het scherm zouden lopen. Hiervoor kan een –no-full optie worden gebruikt:

Als alternatief kun je de weergave ook zo instellen dat alles wordt getoond, ongeacht de lengte of de aanwezigheid van niet-afdrukbare tekens, door de vlag -a te gebruiken:

Uitvoer naar standaarduitvoer

Journalctl toont de uitvoer standaard in een pager, maar als u de gegevens wilt bewerken met tekstbewerkingsprogramma's, heeft u waarschijnlijk de uitvoer naar een standaarduitvoeroptie nodig. Dit kunt u bereiken met de optie –no-pager:

Afhankelijk van de behoeften van de gebruiker kan dit worden omgeleid naar een bestand op de schijf of naar een verwerkingsprogramma.

Uitvoerformaten

Gegevens zijn altijd gemakkelijker te analyseren wanneer ze in een beter leesbaar formaat worden gepresenteerd. Het logboek biedt meerdere opties voor weergave met behulp van de parameter -o, gevolgd door een specifiek aangeduid formaat.

Als u de logboekvermeldingen in een JSON-formaat wilt uitvoeren, kunt u dat op de volgende manier doen:

Deze strategie is vooral handig bij het gebruik van analyseprogramma's. Het json-pretty-formaat kan beter zijn voor het weergeven van de datastructuren voordat u deze doorgeeft aan de JSON-verwerker:

Er zijn verschillende formaten die u kunt gebruiken voor de weergave:

• cat: Toont alleen het berichtveld zelf.
• export: Een binair formaat dat geschikt is voor overdracht of back-ups.
• json: Standaard JSON met één vermelding per regel.
• json-pretty: JSON geformatteerd voor betere menselijke leesbaarheid
• json-sse: JSON-geformatteerde uitvoer verpakt om compatibel te zijn met server-sent events
• short: De standaard syslog-stijl uitvoer
• short-iso: Het standaardformaat aangevuld met ISO 8601-tijdstempels.
• short-monotonic: Het standaardformaat met monotone tijdstempels.
• short-precise: Het standaardformaat met precisie in microseconden
• verbose: Toont elk beschikbaar logboekveld voor de vermelding, inclusief de velden die normaal gesproken intern verborgen zijn.

De bovenstaande opties maken het mogelijk om het logboek in uw voorkeursformaat weer te geven.

Actieve procesbewaking

Het logboek biedt toegang tot het bewaken van actieve of recente activiteiten zonder dat u daar een ander hulpprogramma voor nodig heeft. U kunt dit doen met het journalctl-commando met een 'tail'-functie.

• Recente logboeken weergeven

Het gebruik van de optie -n (die net zo werkt als het commando tail -n) maakt het mogelijk om een bepaald aantal records weer te geven:

Het aantal vermeldingen dat u wilt laten weergeven, kan worden gespecificeerd met een specifiek getal na de parameter -n:

• De logboeken volgen

U kunt de logboeken ook actief volgen terwijl ze naar het systeem worden geschreven met de vlag -f. Dit werkt op dezelfde manier als het commando tail -f:

Logboekonderhoud

Logboeken nemen ruimte in beslag. Dit is de moeite waard om te onderzoeken, mogelijk om enkele van de oudere logboeken te wissen om ruimte vrij te maken.

Huidig schijfgebruik opzoeken

De vlag –disk-usage kan helpen bepalen hoeveel ruimte de logbestanden momenteel op de schijf innemen:

Oude logboeken verwijderen

Met systemd versie 218 (en latere versies) kunt u het logboek op twee verschillende manieren verkleinen. De eerste is de optie –vacuum-size. Hiermee kunt u het logboek verkleinen door de gewenste grootte aan te geven. Met andere woorden, oudere vermeldingen worden uit het logboek verwijderd totdat de ingenomen ruimte overeenkomt met de gevraagde parameter:

De optie –vacuum-time can de ingenomen ruimte van het logboek verkleinen door een uiterste tijdstip aan te geven; alle vermeldingen van vóór dat tijdstip worden verwijderd, terwijl de vermeldingen die na het opgegeven tijdstip zijn gemaakt, worden behouden. Als u alleen de vermeldingen van het afgelopen kalenderjaar wilt bewaren, kunt u het volgende gebruiken:

Logboekgroei beperken

U kunt ook de hoeveelheid ruimte die het logboek in beslag neemt beperken. Dit doet u door het bestand /etc/systemd.journald.conf te bewerken. De groei van het logboek kan worden beperkt met een van de volgende methoden:

• SystemMaxUse=: Geeft de maximale schijfruimte aan die het logboek mag gebruiken in permanente opslag.
• SystemKeepFree=: Geeft aan hoeveel ruimte er vrij moet blijven wanneer de logboekentiteiten worden toegevoegd aan de permanente opslag.
• SystemMaxFileSize=: Specificeert hoe groot de journaalbestanden mogen worden voordat ze worden geroteerd in permanente opslag.
• RuntimeMaxUse=: Specificeert hoeveel schijfruimte mag worden gebruikt in vluchtige opslag (binnen het /run-bestandssysteem).
• RuntimeKeepFree=: Bij het schrijven van gegevens naar vluchtige opslag geeft deze functie de hoeveelheid ruimte aan die moet worden gereserveerd voor ander gebruik (binnen het /run-bestandssysteem).
• RuntimeMaxFileSize=: Geeft aan hoeveel ruimte een individueel logboekjournaal in beslag mag nemen op vluchtige opslag (binnen het /run-bestandssysteem) voordat het moet worden geroteerd.

Deze opties kunnen allemaal helpen om het opslagverbruik door het journaal te beheersen. Een belangrijk feit om op te merken is dat de opties SystemMaxFileSize en RuntimeMaxFileSize zich richten op gearchiveerde bestanden om de gestelde limieten te bereiken. Dit is een belangrijk feit om in gedachten te houden bij het interpreteren van het aantal bestanden na vacuum-bewerkingen.

Conclusie

Het is duidelijk dat het systemd-journaal een ongelooflijk nuttig hulpmiddel is om te gebruiken, waarbij het merendeel van de voordelen voortkomt uit het gecentraliseerde karakter van de logs’ en de omvangrijke hoeveelheid geregistreerde metadata. Van de uitgebreide functies van het journaal kan worden geprofiteerd door het gebruik van de journalctl-opdracht, wat een eenvoudigere methode bevordert om relationele debugging van applicatiecomponenten uit te voeren, evenals uitgebreide systeemanalyse.

Veel computerplezier!