Rotirea unui jurnal de supraveghere VPN fără a rupe scriitorul

O verificare a stării VPN care adaugă o linie pe minut creează în tăcere o a doua datorie: să decidă cum acele linii părăsesc discul. Repararea tunelului nu face nimic pentru acea datorie, iar redenumirea fișierului nu redirecționează un proces care încă ține descriptorul vechi. Răspundeți mai întâi la întrebarea despre destinație, apoi potriviți rotirea cu modul în care scriitorul îl deschide.

Alegeți destinația înaintea politicii de rotire

O unitate systemd care își trimite deja ieșirea către jurnal ține păstrarea într-un singur loc. journald impune limite precum SystemMaxUse și MaxRetentionSec , așa că un supraveghetor care scrie acolo moștenește o limită fără muncă suplimentară. Adăugarea unui al doilea fișier fără limită lângă el dublează întreținerea fără câștig.

Un fișier dedicat își câștigă locul când altceva îl citește: un parser, o exportare de audit sau o pagină care așteaptă o cale stabilă. Odată luată această decizie, fișierul are nevoie de un proprietar, un mod și o politică de rotire scrise împreună, pentru că toate trei sunt corecte doar ca ansamblu. O cale pe care oricine o poate crea este și o cale pe care oricine o poate înlocui, așa că permisiunile directorului aparțin aceleiași note. Scrieți toate acestea lângă verificare și următoarea modificare va porni de la aceleași fapte.

Scrieți blocul potrivit scriitorului

Porniți de la un scriitor care deschide calea la fiecare apel, adaugă o linie și iese. Acel model supraviețuiește rotirii fără nicio cooperare din partea procesului, pentru că rularea următoare deschide fișierul care se află acum pe acea cale. Blocul de mai jos păstrează o săptămână de versiuni și recreează fișierul cu proprietarul și modul de care are nevoie scriitorul:

/var/log/vpn-watchdog.log {
    daily
    rotate 7
    create 0600 root root
    missingok
    notifempty
}

Manualul logrotate definește numărul ca numărul de versiuni rotite păstrate, nu ca o garanție de șapte zile de istoric, iar cuvântul-cheie daily este evaluat când rulează sarcina, în loc să acționeze ca propriul planificator. În majoritatea distribuțiilor, un temporizator systemd sau o intrare cron deține deja acel apel, așa că verificați care există înainte de a adăuga un al doilea. Potrivirea proprietății contează mai mult decât numărul de păstrare. Copierea unui mod doar pentru root pe un fișier scris de un cont de serviciu oprește jurnalizarea la următoarea rotire, iar defectarea apare ore mai târziu ca un marcaj de timp învechit, nu ca o eroare. Confirmați utilizatorul scriitorului înainte de a copia un bloc de altundeva.

Un scriitor care nu redeschide niciodată are nevoie de altă soluție

Un proces de lungă durată care ține un descriptor deschis continuă să scrie în inodul redenumit. Spațiul nu este eliberat și fișierul vizibil încetează să crească, ceea ce arată ca o rotire stricată până când verificați inodul. Fie învățați procesul să redeschidă, fie faceți rotirea să copieze și să trunchieze în loc să redenumească.

Calea redeschiderii este cea mai curată acolo unde software-ul o acceptă: trimiteți semnalul documentat sau rulați comanda documentată și lăsați procesul să deschidă singur fișierul nou. Alternativa este copytruncate , care copiază conținutul sub numele rotit și apoi trunchiează originalul pe loc, astfel încât descriptorul rămâne valid, dar scrierile care cad între copiere și truncheriere se pierd.

Pentru unitățile pornite de systemd, îndreptați StandardOutput spre jurnal sau spre un fișier și lăsați unitatea să dețină ciclul de viață. O buclă shell care adaugă prin tee -a fără limită de dimensiune este aranjamentul care umple o partiție în timpul unei defecțiuni, pentru că o verificare eșuată jurnalizează adesea mult mai mult decât una sănătoasă.

Testați rotirea fără să așteptați temporizatorul

Modul de depanare raportează ce s-ar întâmpla și nu atinge nimic, ceea ce îl face prima rulare sigură după o editare. Forțați o rotire reală când sunteți mulțumit, apoi confirmați că următoarea linie de jurnal ajunge în fișierul nou, nu în cel redenumit:

logrotate -d /etc/logrotate.d/vpn-watchdog
logrotate -f /etc/logrotate.d/vpn-watchdog
ls -l /var/log/vpn-watchdog.log*
tail -n 3 /var/log/vpn-watchdog.log
df -h /var/log

Citiți ieșirea în această ordine. Trecerea de depanare ar trebui să numească fișierul și acțiunile pe care le intenționează; o rulare forțată ar trebui să producă numele rotit așteptat; coada ar trebui să arate o intrare proaspătă după ce scriitorul rulează din nou. O valoare df crescătoare cu un fișier vizibil care se micșorează înseamnă problema de descriptor descrisă mai sus.

Repetați rularea forțată de două ori pentru a vedea cum se comportă păstrarea când există deja versiuni. Ștergerea celui mai vechi fișier este rezultatul așteptat, iar o ștergere lipsă înseamnă de obicei că numărul sau caracterul universal din numele rotit nu corespund cu ce a creat logrotate.

Păstrați o revenire și o consemnare scrisă

Salvați blocul anterior înainte de editare și notați ce planificator îl rulează, pentru că o revenire care restaurează fișierul dar nu temporizatorul reproduce jumătate din problema inițială. Rotiți o dată manual după restaurare, apoi confirmați că contul scriitorului poate scrie pe calea jurnalului. Dacă serviciul rulează sub systemd, reîncărcați unitatea după orice modificare a redirecționării ieșirii sale, pentru că procesul aflat în execuție continuă să scrie către ținta veche. Citiți singur următoarele câteva linii de jurnal în loc să vă bazați că unitatea a revenit curat.

Notați modul, proprietarul, numărul de păstrare și bugetul de disc așteptat lângă verificarea însăși. Când mai târziu verificarea se schimbă dintr-un script unic într-un demon, politica de rotire trebuie să se schimbe cu ea, iar acea notă îi spune următoarei persoane care presupunere s-a rupt.

În final, țineți decizia despre jurnal separată de decizia de recuperare. O verificare eșuată ar trebui să urmeze politica de recuperare a conexiunii, nu o regulă ascunsă în logrotate, și nicio aranjare a jurnalizării nu ar trebui să fie motivul pentru repornirea unui tunel funcțional.