Varifrån VPN-serverns diskökning kommer och hur du begränsar den

Tunneln slutar ta emot anslutningar, tjänsten startar om två gånger och sedan visas ingenting i dess logg. Den tystnaden är ledtråden, för det är loggen som fyllde disken och daemonen har ingenstans att skriva felet du väntar på. Vilken långvarig tjänst som helst kan nå det tillståndet, och att radera en katalog som heter logs löser det sällan. Den hållbara lösningen är att veta vilket lager som växte, vem som äger dess bevarandepolicy och om skrivaren verkligen släppte utrymmet.

Hitta lagret som växte, och takten det växte med

Börja med två tal som är lätta att glömma: lediga block och lediga inoder. Ett filsystem kan rapportera gott om plats och ändå neka en skrivning eftersom det inte har fler inoder kvar, vilket händer när en tjänst skapar en fil per session. Fråga efter båda avläsningarna på samma volym, för svaren kan gå isär samma eftermiddag. Gör det medan värden är frisk, så att talen beskriver normal drift och inte ett avbrott.

df -h /var
df -i /var

Tilldela sedan ökningen till en ägare. Journalens egen förbrukningssiffra täcker bara journalen, och den kommer aldrig att se en daemon som skriver till en sökväg från sin konfigurationsfil.

journalctl --disk-usage

Ökning över tid säger mer än någon enskild avläsning. En debug-nivå som lämnades på, en återförsöksslinga som loggar varje försök, eller en inspelningsfil som ingen stoppade: var och en kan se vanlig ut i ett ögonblick och alarmerande en timme senare. Ta en avläsning, vänta igenom en hektisk period, ta en till och dela med intervallet. En takt du kan ange gör kapacitet till ett beslut i stället för en brand.

Vad rotation gör med en öppen fil

En loggfil är ett namn som pekar på en inode, och utrymmet kommer först tillbaka när det sista öppna handtaget stängs. Byt namn på filen och skrivaren fortsätter fylla samma inode; radera den och skrivaren fortsätter fylla en inode helt utan namn. Det tillståndet är anledningen till att ”jag raderade filen och disken förblev full” beskriver filbeskrivningar och inte ett trasigt filsystem. Att starta om skrivaren, eller välja ett rotationsläge som öppnar filen igen, är det som faktiskt ger tillbaka blocken.

lsof +L1 | head

Policyn tillhör komponenten som skriver filen. Journalen upprätthåller sina egna lagergränser från sin konfigurationsfil, medan en filbaserad tjänst vanligtvis förlitar sig på logrotate, antingen med en skapanderegel och en återöppningssignal eller med ett läge som kortar av på plats när skrivaren inte kan öppna igen. Bekräfta beslutet utan att ändra något först:

logrotate -d /etc/logrotate.conf

Var gränsen hör hemma, och hur stor den bör vara

Sätt taket där skrivaren är konfigurerad, inte vid monteringspunkten. En kvot på hela volymen skyddar värden men säger ingenting om vilken tjänst som fallerar först, och ett globalt städskript tenderar att radera bevisen nästa incident behöver. Ett journaltak, ett rotationstal med en maximal storlek och bevarande på applikationsnivå begränsar var sin producent. Tillsammans begränsar de totalen; var för sig är varje en gissning.

Dimensionera taket utifrån det bevarande du kan försvara, inte utifrån det lediga utrymmet. Om en granskning behöver en vecka av anslutningsförsök måste journalen hålla en vecka vid den mest trafikerade förväntade takten, och den takten är talet som mättes tidigare.

Debug-loggning är ett tillfälligt läge med en registrerad starttid, inte en lagerplan. Håll integritetsfrågan inom samma beslut, för anslutningsloggar bär adresser och identifierare. Längre bevarande är också ett val om datahantering, och det bör fattas av någon som känner till båda begränsningarna.

Verifiera taket efter en omstart

En ändring av bevarandet som varar till nästa omstart är ingen ändring. Starta om skrivaren, bekräfta att den nya gränsen gäller och kontrollera att rotationen fortfarande körs efteråt. För journalen besvarar en omstart och en förbrukningsavläsning båda frågorna:

systemctl restart systemd-journald
journalctl --disk-usage

För en filbaserad tjänst, kör rotationsjobbet en gång för hand och bekräfta att filen ersattes och filbeskrivningen öppnades igen. En skrivare som behåller det gamla handtaget klarar en ytlig kontroll och fallerar nästa gång volymen fylls. Håll koll på det lediga utrymmet under testet, för en fil som krympte medan utrymmet inte kom tillbaka betyder att den gamla inoden fortfarande hålls.

Jämför nästa avläsning med denna

Kom tillbaka efter en vecka och jämför ökningstakten med den registrerade. En matchande takt betyder att taket håller och att belastningen är stabil; en fördubblad takt betyder att något ändrades, och den nyttiga frågan är vad. Läs först loggens innehåll efter upprepade fel, för en återförsöksslinga är både ett symptom och en orsak till volym. Kontrollera sedan allt som nyligen slagits på, inklusive debug-nivåer som slogs på under en incident och aldrig slogs av.

Håll säkerhetskopior utanför samma volym, eller acceptera att en full disk tar kopian med sig. En kopia skriven till värden den skyddar är ingen återställningsplan, och dess bevarande behöver sitt eget svar.

Skriv ned vad som bevaras, var, hur länge och vem som tar bort det. Den meningen är leveransen, och den är den enda delen av detta arbete som överlever nästa omstart.