Waar die skyfverbruik van ’n VPN-bediener vandaan kom en hoe om dit te beperk

Die tonnel hou op om verbindings te aanvaar, die diens herbegin twee keer, en daarna verskyn niks in sy log nie. Daardie stilte is die leidraad, want dit is die log wat die skyf vol gemaak het, en die daemon het nêrens om die fout te skryf waarvoor jy wag nie. Enige diens wat lank loop kan daardie toestand bereik, en om ’n gids met die naam logs te verwyder maak dit selde reg. Die blywende oplossing is om te weet watter stoor gegroei het, wie die retensie daarvan besit, en of die skrywer werklik die ruimte laat gaan het.

Vind die stoor wat gegroei het, en die tempo waarteen dit gegroei het

Begin met twee getalle wat maklik vergeet word: vry blokke en vry inodes. ’n Lêerstelsel kan oorvloedige ruimte rapporteer en tog ’n skryf weier omdat dit geen inodes oor het nie, wat gebeur wanneer ’n diens een lêer per sessie skep. Vra albei lesings op dieselfde volume, want die antwoorde kan op dieselfde middag verskil. Doen dit terwyl die gasheer gesond is, sodat die getalle normale werking beskryf eerder as ’n onderbreking.

df -h /var
df -i /var

Ken dan die groei aan ’n eienaar toe. Die joernaal se eie verbruiksyfer dek net die joernaal, en dit sal nooit ’n daemon sien wat na ’n pad uit sy konfigurasielêer skryf nie.

journalctl --disk-usage

Groei oor tyd sê meer as enige enkele lesing. ’n Ontfoutvlak wat aangelos is, ’n herprobeer-lus wat elke poging log, of ’n opname-lêer wat niemand gestop het nie, kan elkeen op een oomblik gewoon lyk en ’n uur later kommerwekkend. Neem een lesing, wag deur ’n besige tydperk, neem nog een en deel deur die interval. ’n Tempo wat jy kan noem, maak kapasiteit ’n besluit eerder as ’n brand.

Wat rotasie aan ’n oop lêer doen

’n Loglêer is ’n naam wat na ’n inode wys, en die ruimte kom eers terug wanneer die laaste oop handvatsel sluit. Hernoem die lêer en die skrywer bly dieselfde inode vol maak; verwyder dit en die skrywer bly ’n inode vol maak met glad geen naam nie. Daardie toestand is waarom ’ek het die lêer verwyder en die skyf het vol gebly’ lêerbeskrywers beskryf eerder as ’n stukkende lêerstelsel. Om die skrywer te herbegin, of ’n rotasiemodus te kies wat die lêer heropen, is wat die blokke werklik terugbring.

lsof +L1 | head

Beleid behoort aan die komponent wat die lêer skryf. Die joernaal dwing sy eie stoorlimiete uit sy konfigurasielêer af, terwyl ’n lêergebaseerde diens gewoonlik op logrotate staatmaak met óf ’n skepreël plus ’n heropeningssein óf ’n afkap-in-plek-modus wanneer die skrywer nie kan heropen nie. Bevestig die besluit sonder om iets te verander:

logrotate -d /etc/logrotate.conf

Waar die limiet hoort, en hoe groot dit moet wees

Plaas die beperking waar die skrywer opgestel is, nie by die monteerpunt nie. ’n Kwota op die hele volume beskerm die gasheer, maar sê niks oor watter diens eerste faal nie, en ’n globale opruimingskrips is geneig om die bewyse te verwyder wat die volgende voorval nodig het. ’n Joernaalbeperking, ’n rotasietelling met ’n maksimum grootte, en toepassingretensie begrens elkeen een produsent. Saam begrens hulle die totaal; alleen is elkeen ’n raaiskoot.

Bepaal daardie beperking uit die retensie wat jy kan verdedig, nie uit die vry ruimte wat beskikbaar is nie. As ’n hersiening ’n week se verbindingspogings nodig het, moet die joernaal ’n week teen die besigste verwagte tempo hou, en daardie tempo is die getal wat vroeër gemeet is.

Ontfoutlog is ’n tydelike modus met ’n aangetekende begintyd, nie ’n stoorplan nie. Hou die privaatheidsvraag binne dieselfde besluit, want verbindingslogboeke dra adresse en identifiseerders. Langer retensie is ook ’n databehandelingskeuse, en dit behoort deur iemand gemaak te word wat albei beperkings ken.

Verifieer die beperking ná ’n herbegin

’n Retensieverandering wat tot die volgende herbegin hou, is nie ’n verandering nie. Herbegin die skrywer, bevestig dat die nuwe limiet geld, en kontroleer dat rotasie daarna steeds loop. Vir die joernaal beantwoord een herbegin en een verbruiklesing albei vrae:

systemctl restart systemd-journald
journalctl --disk-usage

Vir ’n lêergebaseerde diens, hardloop die rotasietaak een keer met die hand en bevestig dat die lêer vervang is en die beskrywer heropen is. ’n Skrywer wat die ou handvatsel hou, slaag ’n oppervlakkige kontrole en faal die volgende keer wanneer die volume vol word. Hou die vry ruimte dop tydens die toets, want ’n lêer wat gekrimp het terwyl die ruimte nie teruggekeer het nie, beteken die ou inode word steeds gehou.

Vergelyk die volgende lesing met hierdie een

Kom ’n week later terug en vergelyk die groeitempo met die aangetekende een. ’n Ooreenstemmende tempo beteken die beperking hou en die werklading is stabiel; ’n verdubbelde tempo beteken iets het verander, en die nuttige vraag is wat. Lees eers die loginhoud vir herhaalde mislukkings, want ’n herprobeer-lus is beide ’n simptoom en ’n oorsaak van volume. Kontroleer dan vir enigiets nuut geaktiveer, insluitend ontfoutvlakke wat tydens ’n voorval aangeskakel en nooit afgeskakel is nie.

Hou rugsteune van dieselfde volume af, of aanvaar dat een vol skyf die rugsteun saamneem. ’n Kopie wat na die gasheer geskryf word wat dit beskerm, is nie ’n herstelplan nie, en sy retensie het sy eie antwoord nodig.

Skryf neer wat behou word, waar, vir hoe lank, en wie dit verwyder. Daardie sin is die lewering, en dit is die enigste deel van hierdie werk wat die volgende herbegin oorleef.