Logboeken: het enige dat groeit zonder dat iemand het besloot
Alles wat je schijf vult heb jij erbij gezet. Behalve logboeken. En gaat er iets stuk, dan versnelt het schrijven: logboeken groeien het hardst juist wanneer je er het minst naar kunt kijken.
AtlasPVE ·
Dit artikel beantwoordt
- proxmox logbestanden gegroeid
- proxmox journal vulde de schijf
- proxmox logrotate
- proxmox var log opruimen
- proxmox schijf loopt vol oorzaak
Het meeste van wat je schijf vult heb jij erbij gezet: virtuele machines, back-ups, installatiebeelden. Elk daarvan was een beslissing.
Logboeken zijn anders. Ze groeien omdat het systeem draait. Niemand heeft ooit gezegd "laat dit bestand groter worden".
De groei is traag maar zonder grens
Een logbestand groeit misschien een paar kilobyte per dag. Dat valt maandenlang niemand op. Een jaar later is het nog steeds klein.
Maar het heeft geen plafond. En groei zonder plafond wordt, hoe traag ook, een probleem als je lang genoeg wacht.
De vermenigvuldiger die niemand verwacht: een storing versnelt het schrijven
Hier zit het eigenlijke punt van dit artikel.
Een gezond systeem schrijft weinig. Geeft een controle bij elke uitvoering een fout, dan valt er bij elke uitvoering een regel in hetzelfde bestand. Voor een taak die elke vijftien minuten draait zijn dat zesennegentig regels per dag, en het houdt niet op.
Het logboek groeit dus het hardst precies wanneer je er het minst naar kunt kijken: terwijl een storing loopt.
En de ergste versie daarvan
Er komt een probleem, de logboeken versnellen, de schijf loopt vol. De volle schijf veroorzaakt nieuwe problemen. De nieuwe problemen leveren meer logboeken op.
Vanaf dat punt wordt het lastiger de oorspronkelijke storing te vinden, want de meeste fouten op je scherm zijn niet het gevolg van het eerste probleem maar van de volle schijf.
De regel: alles wat schrijft hoort een plafond te hebben
"We ruimen het later op" is geen plan. Wat nodig is, is een mechanische grens die werkt zonder dat iemand het hoeft te onthouden.
Die regel geldt niet alleen voor systeemlogboeken: ze geldt voor elk bestand dat je diensten, geplande taken en verzamelaars voortbrengen.
Twee fouten bij het opzetten van rotatie
Eén: de regel breekt op een bestand dat er niet is. Sommige bestanden ontstaan pas als de bijbehorende functie gebruikt wordt. De regel moet zo geschreven zijn dat ze geen fout geeft als een bestand ontbreekt; anders legt een functie die je nooit gebruikt de hele rotatie stil.
Twee: de verkeerde rotatiemethode. Het bestand hernoemen en de schrijvende dienst een "open opnieuw"-signaal sturen is de gebruikelijke methode, maar dat werkt alleen als er een langlevende dienst is. Is de schrijver een kortlopende taak die telkens opent en sluit, dan is er niemand om te seinen; dan is kopiëren en het bestand ter plekke legen de juiste methode.
Beide zijn stille storingen: de regel staat er, het bestand groeit door, en niemand merkt dat de regel niet werkt.
En de vraag van de reeds geïnstalleerde machine
Schrijf je een rotatieregel alleen in het installatiescript, dan bereikt ze de machines die vóór het bestaan van de regel zijn geïnstalleerd nooit. Die machines draaien er jarenlang zonder.
Juist is de regel bij elke start te schrijven: zo krijgen oudere installaties hem wanneer ze naar een nieuwe versie gaan.
Wat Atlas doet
Dit hele artikel komt voort uit een meting die Atlas aan zichzelf deed, dus het hoort eerlijk verteld te worden.
Atlas draait met rootrechten op de machine van de klant en schrijft naar meerdere logbestanden: de wachtersamenvatting elke vijftien minuten, de uitvoer van geplande updates bij elke uitvoering, zijn eigen zelfupdateverslag. Er is gemeten en geen ervan werd geroteerd, want de installatie schreef nergens een rotatieregel. Op een draaiende machine had het wachterlogboek in tweeëndertig dagen honderdtachtig kilobyte bereikt en er was geen mechanisme om het te verkleinen.
Het getal lijkt klein en die dag was het geen probleem. Het probleem was dat de groei onbegrensd was, plus de hierboven beschreven versnelling. De logboeken van geplande updates vangen bij elke uitvoering de hele uitvoer van de pakketbeheerder op, wat per uitvoering in de megabytes kan lopen.
Nu wordt de regel geschreven, en beide bovenstaande vallen zijn bewust behandeld: ontbrekende bestanden worden geduld, en de rotatie gebruikt de methode kopiëren en dan legen, omdat de schrijvers kortlopende processen uit een geplande taak zijn.
En de regel wordt bij de start geschreven, niet in het installatiescript. De reden is precies de vraag hierboven: zodat eerder geïnstalleerde machines de regel ook krijgen wanneer ze naar een nieuwe versie gaan.
Bronnen
De eigen documentatie van Proxmox. In het Engels, en die heeft over dit onderwerp het laatste woord.