Linux als server

Eén van de zaken die met de komst van systemd een jaar of twee geleden voor veel verwarring heeft gezorgd, is systemd-journald, ookwel aangeduid als journald. In het verleden was er rsyslog (of een variant daarop) dat zorgdroeg voor logging van berichten. Nu is naast rsyslog ook ineens journald en ondertussen zit de beheerder met zijn handen in het haar en is niet altijd duidelijk waar nu de logberichten teruggevonden kunnen worden. Dit artikel verschaft duidelijkheid!

De systemd-journald service was ontworpen om logging meer direct aan de services te koppelen. De gedachte is dat systemd toch zorgdraagt voor het opstarten en beheer van services en dat het daarom net zo goed ook de logging voor zijn rekening kan nemen. Het resultaat van deze gedachtengang is vaak positief: door systemctl status te typen, gevolgd door de naam van om het even welke service zie je meteen de laatste berichten die betreffende deze service gelogd zijn. Listing 1 laat een voorbeeld zien.

Listing 1: De integratie tussen systemd en journald zorgt dat je eenvoudig log-informatie ziet.

**********************start listing***************

[root@localhost secret]# systemctl status httpd

● httpd.service – The Apache HTTP Server

   Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled; vendor preset: disabled)

   Active: active (running) since Tue 2017-01-10 09:26:53 EST; 2 days ago

     Docs: man:httpd(8)

           man:apachectl(8)

  Process: 60960 ExecStop=/bin/kill -WINCH ${MAINPID} (code=exited, status=0/SUCCESS)

 Main PID: 61039 (httpd)

   Status: “Total requests: 3; Current requests/sec: 0; Current traffic:   0 B/sec”

   CGroup: /system.slice/httpd.service

           ├─61039 /usr/sbin/httpd -DFOREGROUND

           ├─61040 /usr/sbin/httpd -DFOREGROUND

           ├─61041 /usr/sbin/httpd -DFOREGROUND

           ├─61042 /usr/sbin/httpd -DFOREGROUND

           ├─61043 /usr/sbin/httpd -DFOREGROUND

           ├─61044 /usr/sbin/httpd -DFOREGROUND

           ├─61045 /usr/sbin/httpd -DFOREGROUND

           └─61123 /usr/sbin/httpd -DFOREGROUND

Jan 10 09:26:53 localhost.localdomain systemd[1]: Starting The Apache HTTP Se…

Jan 10 09:26:53 localhost.localdomain httpd[61039]: AH00558: httpd: Could not…

Jan 10 09:26:53 localhost.localdomain systemd[1]: Started The Apache HTTP Ser…

Hint: Some lines were ellipsized, use -l to show in full.

**********************eind listing***************

Zoals je in listing 1 kunt zien, bevindt de log informatie zich op de laatste paar regels. Je ziet dus standaard alleen informatie over de meest recente events. Wil je meer details, dan moet je te rade gaan in het journal zelf.

Het journald journal is een in-memory log van recente events. Dat betekent dat het standaard nergens opgeslagen wordt, al is het vrij eenvoudig daar iets aan te doen: type mkdir /var/log/journal, gevolgd door systemctl restart systemd-journald en je journal zal vanaf nu ook op schijf opgeslagen worden. Houdt echter wel met één ding rekening: dit journal wordt standaard en automatisch geroteerd. Dat betekent dat berichten die over een in /etc/systemd/journal.conf in te stellen houdbaarheidsdatum gaan, automatisch opgeruimd worden. De gedachten hierachter is dat je niet wilt dat je systeem automatisch volloopt met log berichten en op deze wijze wordt voor je opgeruimd.

Waar journald vooral in uitblinkt, is de uitgebreidheid waarmee gelogd wordt en de filtering mogelijkheden die er zijn door gebruik te maken van het journalctl commando. Zoals alles in moderne Linux distributies, komt dit journalctl commando met een uitstekende bash-completion, hetgeen betekent dat je eenvoudig toegang krijgt tot de uitgebreide opties die de opdracht biedt door herhaaldelijk op de Tab-toets te drukken. Wat denk je bijvoorbeeld van journalctl –since “1 hour ago”, wat je keurig de berichten zal laten zien die in het afgelopen uur gelogd zijn. De korte samenvatting van de grote hoeveelheid opties is dat als je je kunt indenken dat een bepaalde filteringoptie handig is, deze is waarschijnlijk wel ingebakken in het commando.

Er is echter één ding dat je wel goed in de gaten moet houden: alles wat gelogd wordt door systemd-journald wordt niet automatisch opgeslagen in een logbestand. En dat betekent dat je na elke reboot een nieuw journal krijgt. Maar zoals je hierboven hebt kunnen lezen, is dat vrij eenvoudig op te lossen.

Nog nut voor syslog en aanverwanten?

In de UNIX oertijd is syslog uitgevonden. In de loop der tijd zijn daar verschillende vernieuwingspogingen op losgelaten en tegenwoordig is rsyslog de standaard syslog implementatie. Rsyslog is modulair en dat maakt het eenvoudig voor beheerders om gebruik te maken van aparte modules om op een slimmere wijze te bepalen wat precies naar de log bestanden weggeschreven moet worden.

Rsyslog werkt met een configuratiebestand /etc/rsyslog.conf (en soms een directory met daarbij behorende snapin files met de naam /etc/rsyslog.d). Hierin wordt op basis van facilities, priorities en destinations aangegeven wat waar onder welke omstandigheden weggeschreven moet worden. Het resultaat is een aantal logbestanden dat weggeschreven wordt in de /var/log directory.

De syslog standaard is heel lang geleden verzonnen en met de introductie daarvan is een aantal facilities in het leven geroepen. Dit zijn de dingen (vaak daemons) waarover gelogd moet worden. Zo is er bijvoorbeeld cron voor cron, kern voor de kernel, authpriv voor alles wat te maken heeft met authenticatie en nog veel meer. Wat vooral interessant is, zijn de facilities die er niet zijn. Moderne services, zoals web servers of FTP servers, hebben bijvoorbeeld geen facility.

Het gebrek aan facilities voor sommige services heeft ertoe geleid dat in een (r)syslog omgeving niet elke service ook gebruik maakt van rsyslog om zorg te dragen voor de logging. Sommige services, zoals bijvoorbeeld de Apache web server, denken dat ze het zelf beter kunnen en dragen om die reden zelf zorg voor het wegschrijven van log bestanden. Het nadeel daarvan is dat als iedere service zijn eigen logging regelt, er geen enkele wijze van standaardisatie is en het risico ontstaat dat berichten verloren gaan. Gewoon, omdat de gecentraliseerde logging niet goed geregeld is.

Waar systemd-journald ervoor zorgt dat de log niet op de schijf wordt opgeslagen en daarnaast automatisch geroteerd wordt, maakt rsyslogd gebruik van logrotate. Eigenlijk heeft logrotate niets met rsyslog te maken, maar is het een set slimme scripts die ingezet kan worden om elk willekeurig bestand in de gaten te houden. Bij overschrijding van een bepaalde grootte of ouderdom zal logrotate het bestand afsluiten en een nieuw bestand openen. Maar logrotate wordt vooral ingezet om de grootte van bestanden die door rsyslog aangemaakt worden te beperken.

Integratie

Een enkele, moderne Linux distributie maakt uitsluitend gebruik van systemd-journald. De meeste distributies gebruiken beiden. Hierbij vindt ook integratie plaats, voornamelijk van systemd-journald naar rsyslog toe. Dit zorgt ervoor dat een samenvatting van de logberichten automatisch weggeschreven wordt in de logbestanden die onder de auspiciën van rsyslog vallen. Rsyslog maakt hiervoor gebruik van een input module, die de beheerder vervolgens in staat stelt te bepalen waar de systemd-journald berichten opgeslagen worden.

De reden dat veel distributies van beiden gebruik maken, heeft niet alleen te maken met het voorzien in een flexibele overgang. De mogelijkheden om remote te loggen, zijn in rsyslog momenteel beter ontwikkeld dan het geval is in systemd-journald. In rsyslog is het heel eenvoudig om ervoor te zorgen dat alle logberichten doorgestuurd worden naar een centrale log server. In systemd-journald is deze functionaliteit nog in ontwikkeling. De verwachting is dat binnen afzienbare tijd ook systemd-journal gecentraliseerde logservers kan aanbieden. Als dat eenmaal het geval is, wordt de noodzaak om nog gebruik te maken van rsyslog een stuk kleiner. Daarom is het aannemelijk dat in de toekomst systemd-journald de enige service zal zijn die zorgdraagt voor het gecentraliseerd opslaan van logbestanden.