Stelt u zich eens voor hoe het zou zijn als een kritieke dienst enkele minuten geleden het loodje zou leggen, en u werd opgeroepen om de dag te redden. Je probeert de service te herstarten, maar hij geeft niet op. Er zijn geen foutmeldingen, maar wat nog belangrijker is, geen sporen van wat hij deed voordat hij besloot te sterven. Honderd en één oorzaken gaan door je hoofd, en je realiseert je dat er geen manier is om te weten in welke richting je moet gaan. Misschien kun je de server helemaal opnieuw opstarten. Heel misschien.
Dit scenario is een van de vele waarin logging je te hulp kan schieten. Gewoonlijk houdt een draaiend stuk software een verslag bij van belangrijke activiteiten voor het nageslacht in een bestand. Alles kan in een logbestand worden bewaard omdat het ontwikkelaars en systeembeheerders helpt om achteraf te weten wat er met een bepaald stuk software is gebeurd. Logbestanden worden ook gebruikt door beveiligingsgeoriënteerde personen om de toegang tot bepaalde bronnen te controleren. In netwerken of messaging, leggen log files de tijd vast waarop berichten zijn verzonden of ontvangen voor latere referentie.
Log files, per definitie, blijven in omvang toenemen, afhankelijk van de frequentie en de verbositeit waarmee ze worden bijgewerkt. Om hun doel te dienen, worden ze gewoonlijk geopend in append-modus en bevatten ze tijdstempels om te helpen bij troubleshooting en forensisch onderzoek. Dit levert echter een probleem op, omdat grote bestanden het werken met logbestanden omslachtig maken, zowel voor het systeem als voor de menselijke reviewer. Om de logbestanden houdbaar te houden, worden ze gerouleerd. Simpel gezegd: een nieuw bestand wordt geopend terwijl het oudere wordt gesloten en ofwel bewaard ofwel verwijderd, afhankelijk van de voorkeur van het ontwerp. Dit voorkomt dat logbestanden hele partities vullen en systemen op hun knieën dwingen. Misschien heb je de logrotatie al eens aan het werk gezien op een systeem in de buurt. Kijk naar de data op de boot.log
bestanden.
In dit geval, als aan een specifieke voorwaarde is voldaan, wordt het huidige bestand hernoemd door er een datum aan toe te voegen om het te identificeren en te volgen, en wordt een nieuw bestand met de oorspronkelijke naam geopend, klaar om binnenkomende logberichten te ontvangen.
Loggen in Linux (rsyslogd)
Zoals je zou verwachten, is loggen in Linux systemen, zoals de CentOS 7 server die ik ter illustratie gebruik, afhankelijk van een daemon om het loggen te vergemakkelijken. Rsyslogd
is de naam van de betrouwbare oude service en het is open-source. Eigenlijk is het niet zo oud. Het is een verbeterde versie van de oorspronkelijke syslog
daemon, en het bezit de mogelijkheid om logs snel te verwerken en door te sturen naar elke locatie in een IP netwerk. Naast syslog
en rsyslog
, is er syslog-ng
, dat nog een andere daemon is voor het afhandelen van logs. De standaard log handler hangt af van de distro die men kiest. Rsyslog
is standaard aanwezig in veel op Red Hat gebaseerde distro’s. Voer het volgende commando uit om de aanwezigheid en versie ervan op uw systeem te controleren:
rsyslogd -v
Als het een daemon is, kunt u controleren of hij actief is door systemd
als volgt in te zetten:
systemctl status rsyslogd
Als, het om wat voor reden dan ook niet draait, kunt u het starten via systemd
.
Logrotate
Logrotate
is een Linux-hulpprogramma waarvan de kernfunctie is om – wacht even – logs te roteren. Als het niet is geïnstalleerd als onderdeel van de standaard OS-installatie, kan het eenvoudig worden geïnstalleerd door het volgende uit te voeren:
yum install logrotate
Het binaire bestand kan worden gevonden op /bin/logrotate
.
Door de installatie van logrotate
, wordt een nieuw configuratie bestand geplaatst in de /etc/
directory om het algemene gedrag van het hulpprogramma te regelen wanneer het draait. Ook wordt er een map gemaakt voor service-specifieke snap-in configuratiebestanden voor op maat gemaakte logrotatieverzoeken. Hierover later meer.
Dagelijkse cron job
Er wordt dagelijks een cron
job uitgevoerd die het hulpprogramma start. Dit wordt bereikt door een oproep naar het hulpprogramma in de standaard cron
map voor dagelijkse jobs te plaatsen. Hoewel de details van de aanroep buiten het bestek van dit artikel vallen, volstaat het te zeggen dat de aanroep gewoon een Bash script is dat de logrotate
binary uitvoert, en het systeem vertelt wat het moet doen in geval van een fout.
Standaard locatie van logbestanden
Logs op een Linux systeem kunnen overal worden geplaatst waar de permissies dat toestaan. Echter, omdat ze voortdurend veranderen in grootte en inhoud, schrijft de Bestandssysteem Hiërarchie per definitie voor dat ze in de /var/log/
directory worden bewaard.
De schermafbeelding hieronder is een blik op de inhoud van mijn /var/log
directory.
Configuratie bestanden en voorbeelden
/etc/logrotate.conf
Het eerste bestand om op te letten met betrekking tot de functie van logrotate
is logrotate.conf
. Dit config bestand bevat de richtlijnen voor hoe log bestanden standaard geroteerd moeten worden. Als er geen specifieke set richtlijnen is, handelt het hulpprogramma volgens de richtlijnen in dit bestand.
Hieronder staat een voorbeeld van de inhoud van het configuratiebestand.
Laten we een paar van de directieven doorlopen om een gevoel te krijgen voor de flexibiliteit van logrotate. De auteur van het hulpprogramma heeft vriendelijk genoeg commentaar toegevoegd om een beginner op weg te helpen. Je zou ook de
man
pagina kunnen bekijken voor een diepere duik. De directievenweekly
dateext
compress
create
, enrotate 4
stellen dat de logbestanden wekelijks moeten worden geroteerd, dat de rotatiedatum wordt gebruikt als het identificatiesuffix van de geroteerde bestanden, dat de geroteerde bestanden moeten worden gecomprimeerd, dat een nieuw bestand moet worden aangemaakt om binnenkomende logs te ontvangen, en dat niet meer dan vier logs moeten worden bewaard. Met andere woorden, het vijfde nieuwste logboek moet worden verwijderd. Merk ook op dat op mijn systeem, door de aanwezigheid van de#
voor decompress
directive, compressie standaard is uitgeschakeld.
Ook is er een directive om een bepaalde map op te nemen: /etc/logrotate.d
. Deze map wordt gebruikt voor pakket-specifieke log rotatie verzoeken. Pakketten die ontworpen zijn om voordeel te halen uit logrotate
zetten configuratiebestanden in deze map. Deze modulariteit is in overeenstemming met de Linux geest en verbetert de uitbreidbaarheid van het hulpprogramma. De configuratiebestanden bevatten gelijksoortige directieven en aangepaste logbestanden waar van toepassing. Je kunt ook je eigen configuratiebestand maken om elk logbestand van je keuze te behandelen. Geef het bestand een naam, voeg het te verwerken logbestand toe, en plaats het in deze directory. Tenslotte zijn er richtlijnen voor logbestanden zonder eigenaarspakket, zoals wtmp
en andere systeemlogbestanden. De man
pagina is gevuld met meer directieven, en voor gebruikers die meer specifieke rotatie noden hebben, raad ik sterk aan om die eens te bekijken.
/etc/logrotate.d
Helaas heb ik al veel gesproken over de /etc/logrotate.d
directory, dus zonder veel omhaal laat ik u de inhoud van deze directory zien om de eerder gedeelde ideeën thuis te brengen.
En voor de goede orde, laten we eens kijken naar het Samba configuratie bestand.
Kun je zien hoezeer het lijkt op logrotate.conf
? Voordat ik het doek voor dit stuk open trek, laten we eerst een paar van de richtlijnen in dit bestand doorlopen:
/var/log/samba/*
– Het logbestand dat gedraaid moet worden. In dit geval is dat elk logbestand in de Samba logboekdirectory.
notifempty
– Richtlijn die zegt dat het bestand niet moet worden geroteerd als het leeg is.
olddir /var/log/samba/old
– Locatie om oude geroteerde logboeken op te slaan.
missingok
– Stopt logrotate
met het gooien van een fout als het logbestand ontbreekt.
copytruncate
– Sluit het logbestand niet af. Maak een kopie, dat zal het geroteerde, hernoemde bestand zijn, en truncate dan het logbestand tot nul
Kunt u raden wat de sharedscripts
directive doet? U hoeft niet te raden – raadpleeg de man
pagina.
Wrapping up