Waar de schijfgroei van een VPN-server vandaan komt en hoe je die begrenst

De tunnel accepteert geen verbindingen meer, de dienst start twee keer opnieuw en daarna verschijnt er niets in het log. Die stilte is de aanwijzing, want het log heeft de schijf gevuld en de daemon heeft nergens om de fout te schrijven waarop je wacht. Elke langdurig draaiende dienst kan in die toestand komen, en een map met de naam logs verwijderen lost het zelden op. De duurzame oplossing is weten welk archief groeide, wie het bewaarbeleid bezit en of de schrijver de ruimte echt heeft vrijgegeven.

Vind het archief dat groeide, en de snelheid waarmee het groeide

Begin met twee getallen die makkelijk vergeten worden: vrije blokken en vrije inodes. Een bestandssysteem kan veel ruimte melden en toch een schrijfactie weigeren omdat er geen inodes meer over zijn, wat gebeurt wanneer een dienst één bestand per sessie aanmaakt. Vraag beide uitlezingen op hetzelfde volume, want de antwoorden kunnen dezelfde middag nog van elkaar afwijken. Doe het terwijl de host gezond is, zodat de getallen normale werking beschrijven en geen storing.

df -h /var
df -i /var

Wijs de groei daarna toe aan een eigenaar. Het eigen verbruikscijfer van het journal dekt alleen het journal, en het zal nooit een daemon zien die naar een pad uit zijn configuratiebestand schrijft.

journalctl --disk-usage

Groei over tijd zegt meer dan welke enkele meting dan ook. Een debug-niveau dat aan bleef staan, een herhaallus die elke poging logt, of een capture-bestand dat niemand stopte: elk ervan kan op één moment gewoon lijken en een uur later alarmerend. Neem één meting, wacht een drukke periode af, neem er nog een en deel door het interval. Een snelheid die je kunt benoemen maakt van capaciteit een beslissing in plaats van een brand.

Wat rotatie met een open bestand doet

Een logbestand is een naam die naar een inode wijst, en de ruimte komt pas terug wanneer de laatste open handle sluit. Hernoem het bestand en de schrijver blijft dezelfde inode vullen; verwijder het en de schrijver blijft een inode vullen zonder enige naam. Die toestand is de reden dat ‘ik heb het bestand verwijderd en de schijf bleef vol’ bestandsdescriptors beschrijft en geen kapot bestandssysteem. De schrijver herstarten, of een rotatiemodus kiezen die het bestand opnieuw opent, is wat de blokken echt teruggeeft.

lsof +L1 | head

Het beleid hoort bij het onderdeel dat het bestand schrijft. Het journal handhaaft zijn eigen opslaglimieten vanuit zijn configuratiebestand, terwijl een bestandsgebaseerde dienst meestal op logrotate vertrouwt, met een aanmaakregel plus een heropensignaal of met een modus die ter plaatse afkapt wanneer de schrijver niet opnieuw kan openen. Bevestig de beslissing eerst zonder iets te wijzigen:

logrotate -d /etc/logrotate.conf

Waar de limiet hoort, en hoe groot die moet zijn

Zet de limiet waar de schrijver is geconfigureerd, niet op het koppelpunt. Een quotum op het hele volume beschermt de host, maar zegt niets over welke dienst als eerste faalt, en een globaal opschoonscript heeft de neiging het bewijs te verwijderen dat het volgende incident nodig heeft. Een journallimiet, een rotatieaantal met een maximale grootte en bewaring op applicatieniveau begrenzen elk één producent. Samen begrenzen ze het totaal; apart is elk een gok.

Bepaal die limiet op basis van de bewaring die je kunt verdedigen, niet van de vrije ruimte. Als een review een week aan verbindingspogingen nodig heeft, moet het journal een week vasthouden bij de drukste verwachte snelheid, en die snelheid is het eerder gemeten getal.

Debug-logging is een tijdelijke modus met een vastgelegde starttijd, geen opslagplan. Houd de privacyvraag in dezelfde beslissing, want verbindingslogs dragen adressen en identificatoren. Langere bewaring is ook een keuze in gegevensverwerking, en die moet worden genomen door iemand die beide beperkingen kent.

Verifieer de limiet na een herstart

Een bewaringswijziging die tot de volgende herstart standhoudt, is geen wijziging. Herstart de schrijver, bevestig dat de nieuwe limiet geldt en controleer dat de rotatie daarna nog draait. Voor het journal beantwoorden één herstart en één verbruiksmeting beide vragen:

systemctl restart systemd-journald
journalctl --disk-usage

Voor een bestandsgebaseerde dienst voer je de rotatietaak één keer met de hand uit en bevestig je dat het bestand is vervangen en de descriptor opnieuw geopend. Een schrijver die de oude handle vasthoudt, slaagt voor een oppervlakkige controle en faalt de volgende keer dat het volume volloopt. Let tijdens de test op de vrije ruimte, want een bestand dat kromp terwijl de ruimte niet terugkwam, betekent dat de oude inode nog wordt vastgehouden.

Vergelijk de volgende meting met deze

Kom na een week terug en vergelijk de groeisnelheid met de vastgelegde. Een overeenkomende snelheid betekent dat de limiet standhoudt en de belasting stabiel is; een verdubbelde snelheid betekent dat er iets veranderd is, en de nuttige vraag is wat. Lees eerst de loginhoud op herhaalde fouten, want een herhaallus is zowel een symptoom als een oorzaak van volume. Controleer daarna alles wat nieuw is aangezet, inclusief debug-niveaus die tijdens een incident zijn aangezet en nooit uitgezet.

Houd back-ups buiten hetzelfde volume, of accepteer dat één volle schijf de kopie meeneemt. Een kopie die naar de host wordt geschreven die hij beschermt, is geen herstelplan, en de bewaring ervan heeft een eigen antwoord nodig.

Schrijf op wat bewaard blijft, waar, hoe lang en wie het verwijdert. Die zin is het resultaat, en het is het enige deel van dit werk dat de volgende herstart overleeft.