Hvor VPN-serverens diskvekst kommer fra, og hvordan du begrenser den

Tunnelen slutter å ta imot tilkoblinger, tjenesten starter på nytt to ganger, og deretter vises ingenting i loggen dens. Den stillheten er ledetråden, for det er loggen som fylte disken, og daemonen har ingen steder å skrive feilen du venter på. Enhver langvarig tjeneste kan nå den tilstanden, og det hjelper sjelden å slette en katalog som heter logs. Den varige løsningen er å vite hvilket lager som vokste, hvem som eier oppbevaringspolitikken, og om skriveren faktisk ga slipp på plassen.

Finn lageret som vokste, og raten det vokste med

Start med to tall som er lette å glemme: ledige blokker og ledige inoder. Et filsystem kan rapportere god plass og likevel nekte en skriving fordi det ikke har flere inoder igjen, noe som skjer når en tjeneste oppretter én fil per økt. Spør etter begge avlesningene på samme volum, for svarene kan være uenige samme ettermiddag. Gjør det mens verten er frisk, slik at tallene beskriver normal drift og ikke et avbrudd.

df -h /var
df -i /var

Tildel deretter veksten til en eier. Journalens eget forbrukstall dekker bare journalen, og det vil aldri se en daemon som skriver til en sti fra konfigurasjonsfilen sin.

journalctl --disk-usage

Vekst over tid sier mer enn noen enkelt avlesning. Et debug-nivå som ble stående på, en gjentakelsesløkke som logger hvert forsøk, eller en opptaksfil ingen stoppet: hver av dem kan se vanlig ut i ett øyeblikk og alarmerende en time senere. Ta én avlesning, vent gjennom en travel periode, ta en ny, og del på intervallet. En rate du kan oppgi gjør kapasitet til en beslutning i stedet for en brann.

Hva rotasjon gjør med en åpen fil

En loggfil er et navn som peker på en inode, og plassen kommer først tilbake når den siste åpne håndtaket lukkes. Gi filen nytt navn, og skriveren fortsetter å fylle samme inode; slett den, og skriveren fortsetter å fylle en inode helt uten navn. Den tilstanden er grunnen til at «jeg slettet filen, og disken forble full» beskriver filbeskrivelser og ikke et ødelagt filsystem. Å starte skriveren på nytt, eller velge en rotasjonsmodus som åpner filen på nytt, er det som faktisk gir blokkene tilbake.

lsof +L1 | head

Policyen tilhører komponenten som skriver filen. Journalen håndhever sine egne lagergrenser fra konfigurasjonsfilen sin, mens en filbasert tjeneste vanligvis stoler på logrotate, enten med en opprettelsesregel og et gjenåpningssignal eller med en modus som kutter på stedet når skriveren ikke kan gjenåpne. Bekreft beslutningen uten å endre noe først:

logrotate -d /etc/logrotate.conf

Hvor grensen hører hjemme, og hvor stor den bør være

Sett taket der skriveren er konfigurert, ikke ved monteringspunktet. En kvote på hele volumet beskytter verten, men sier ingenting om hvilken tjeneste som feiler først, og et globalt oppryddingsskript har en tendens til å slette bevisene neste hendelse trenger. Et journaltak, et rotasjonstall med en maksimal størrelse og oppbevaring på applikasjonsnivå begrenser hver sin produsent. Sammen begrenser de totalen; alene er hver en gjetning.

Dimensjoner taket ut fra oppbevaringen du kan forsvare, ikke fra den ledige plassen. Hvis en gjennomgang trenger en uke med tilkoblingsforsøk, må journalen holde en uke ved den travleste forventede raten, og den raten er tallet som ble målt tidligere.

Debug-loggføring er en midlertidig modus med et registrert starttidspunkt, ikke en lagerplan. Hold personvernspørsmålet inne i samme beslutning, for tilkoblingslogger bærer adresser og identifikatorer. Lengre oppbevaring er også et valg om databehandling, og det bør tas av noen som kjenner begge begrensningene.

Verifiser taket etter en omstart

En endring i oppbevaring som varer til neste omstart, er ikke en endring. Start skriveren på nytt, bekreft at den nye grensen gjelder, og sjekk at rotasjonen fortsatt kjører etterpå. For journalen svarer én omstart og én forbruksavlesning på begge spørsmålene:

systemctl restart systemd-journald
journalctl --disk-usage

For en filbasert tjeneste, kjør rotasjonsjobben én gang for hånd og bekreft at filen ble erstattet og filbeskrivelsen gjenåpnet. En skriver som beholder det gamle håndtaket, består en overfladisk kontroll og feiler neste gang volumet fylles. Følg med på ledig plass under testen, for en fil som krympet mens plassen ikke kom tilbake, betyr at den gamle inoden fortsatt holdes.

Sammenlign neste avlesning med denne

Kom tilbake etter en uke og sammenlign vekstraten med den registrerte. En tilsvarende rate betyr at taket holder og arbeidsbelastningen er stabil; en doblet rate betyr at noe endret seg, og det nyttige spørsmålet er hva. Les logginnholdet for gjentatte feil først, for en gjentakelsesløkke er både et symptom og en årsak til volum. Sjekk deretter for alt som nylig er slått på, inkludert debug-nivåer som ble slått på under en hendelse og aldri slått av.

Hold sikkerhetskopier utenfor samme volum, eller godta at én full disk tar kopien med seg. En kopi skrevet til verten den beskytter, er ikke en gjenopprettingsplan, og oppbevaringen trenger sitt eget svar.

Skriv ned hva som oppbevares, hvor, hvor lenge og hvem som fjerner det. Den setningen er leveransen, og den er den eneste delen av dette arbeidet som overlever neste omstart.