De unde vine creșterea discului unui server VPN și cum o limităm

Tunelul nu mai acceptă conexiuni, serviciul repornește de două ori, iar apoi nu mai apare nimic în jurnalul său. Acea tăcere este indiciul, pentru că jurnalul a umplut discul și daemonul nu are unde scrie eroarea pe care o așteptați. Orice serviciu de lungă durată poate ajunge în acel stadiu, iar ștergerea unui director numit logs rareori îl repară. Soluția durabilă este să știți ce depozit a crescut, cine deține politica de păstrare și dacă scriitorul a eliberat într-adevăr spațiul.

Găsiți depozitul care a crescut și rata cu care a crescut

Începeți cu două numere ușor de uitat: blocuri libere și inode-uri libere. Un sistem de fișiere poate raporta mult spațiu și totuși refuza o scriere pentru că nu mai are inode-uri, ceea ce se întâmplă când un serviciu creează un fișier pe sesiune. Cereți ambele citiri pe același volum, pentru că răspunsurile pot fi contradictorii în aceeași după-amiază. Faceți asta cât timp gazda este sănătoasă, ca numerele să descrie funcționarea normală, nu o pană.

df -h /var
df -i /var

Apoi atribuiți creșterea unui proprietar. Cifra de utilizare a journalului acoperă doar journalul și nu va vedea niciodată un daemon care scrie într-o cale din fișierul său de configurare.

journalctl --disk-usage

Creșterea în timp spune mai mult decât orice citire unică. Un nivel de depanare lăsat pornit, o buclă de reîncercări care înregistrează fiecare încercare sau un fișier de captură pe care nimeni nu l-a oprit: fiecare poate părea obișnuit într-un moment și alarmant o oră mai târziu. Faceți o citire, așteptați o perioadă aglomerată, faceți alta și împărțiți la interval. O rată pe care o puteți enunța transformă capacitatea într-o decizie, nu într-un incendiu.

Ce face rotația cu un fișier deschis

Un fișier de jurnal este un nume care indică un inode, iar spațiul revine doar când ultimul descriptor deschis este închis. Redenumiți fișierul și scriitorul continuă să umple același inode; ștergeți-l și scriitorul continuă să umple un inode fără niciun nume. Această stare este motivul pentru care „am șters fișierul și discul a rămas plin” descrie descriptori de fișier, nu un sistem de fișiere defect. Repornirea scriitorului, sau alegerea unui mod de rotație care redeschide fișierul, este ceea ce returnează efectiv blocurile.

lsof +L1 | head

Politica aparține componentei care scrie fișierul. Journalul își impune propriile limite de stocare din fișierul său de configurare, în timp ce un serviciu bazat pe fișiere se bazează de obicei pe logrotate, fie cu o regulă de creare și un semnal de redeschidere, fie cu un mod de trunchiere la fața locului când scriitorul nu poate redeschide. Confirmați decizia fără a schimba nimic mai întâi:

logrotate -d /etc/logrotate.conf

Unde îi este locul limitei și cât de mare ar trebui să fie

Puneți limita acolo unde este configurat scriitorul, nu la punctul de montare. O cotă pe întregul volum protejează gazda, dar nu spune care serviciu va ceda primul, iar un script global de curățare tinde să șteargă dovezile de care va avea nevoie următorul incident. O limită a journalului, un număr de rotații cu o dimensiune maximă și păstrarea la nivel de aplicație limitează fiecare un singur producător. Împreună limitează totalul; separat, fiecare este o presupunere.

Dimensionați această limită pornind de la păstrarea pe care o puteți susține, nu de la spațiul liber disponibil. Dacă o revizuire are nevoie de o săptămână de încercări de conectare, journalul trebuie să țină o săptămână la cea mai aglomerată rată estimată, iar acea rată este numărul măsurat anterior.

Jurnalizarea de depanare este un mod temporar cu o oră de început înregistrată, nu un plan de stocare. Țineți întrebarea despre confidențialitate în aceeași decizie, pentru că jurnalele de conexiuni poartă adrese și identificatori. O păstrare mai lungă este și o alegere de prelucrare a datelor și ar trebui luată de cineva care cunoaște ambele constrângeri.

Verificați limita după o repornire

O modificare a păstrării care durează până la următoarea repornire nu este o modificare. Reporniți scriitorul, confirmați că noua limită se aplică și verificați că rotația încă funcționează după aceea. Pentru journal, o repornire și o citire a consumului răspund la ambele întrebări:

systemctl restart systemd-journald
journalctl --disk-usage

Pentru un serviciu bazat pe fișiere, rulați sarcina de rotație o dată manual și confirmați că fișierul a fost înlocuit și descriptorul redeschis. Un scriitor care păstrează descriptorul vechi trece de o verificare superficială și eșuează la următoarea umplere a volumului. Urmăriți spațiul liber în timpul testului, pentru că un fișier care s-a micșorat în timp ce spațiul nu revenea înseamnă că inode-ul vechi este încă ținut.

Comparați următoarea citire cu aceasta

Reveniți după o săptămână și comparați rata de creștere cu cea înregistrată. O rată identică înseamnă că limita rezistă și încărcarea este stabilă; o rată dublată înseamnă că ceva s-a schimbat, iar întrebarea utilă este ce. Citiți mai întâi conținutul jurnalului pentru eșecuri repetate, pentru că o buclă de reîncercări este atât simptom, cât și cauză a volumului. Apoi verificați orice a fost activat recent, inclusiv niveluri de depanare pornite în timpul unui incident și niciodată oprite.

Țineți copiile de rezervă în afara aceluiași volum, sau acceptați că un disc plin ia copia cu el. O copie scrisă pe gazda pe care o protejează nu este un plan de recuperare, iar păstrarea ei are nevoie de propriul răspuns.

Notați ce se păstrează, unde, cât timp și cine îl elimină. Acea propoziție este rezultatul și este singura parte a acestei lucrări care supraviețuiește următoarei reporniri.