Ale cui sunt jurnalele OpenVPN: ale daemonului, ale rsyslog sau ale logrotate?

Rotația jurnalelor se strică într-un mod previzibil: trei componente cred fiecare că dețin fișierul, iar rezultatul este un jurnal rotit care continuă să crească în timp ce noul rămâne gol. Daemonul ține un descriptor, logrotate redenumește calea, iar rsyslog scrie cu totul altundeva. Alegeți un scriitor și un rotator înainte de a adăuga încă o regulă la grămadă. Lista de verificare de mai jos merge în această ordine pentru că fiecare pas ulterior depinde de ea.

Decideți cine scrie fișierul

Două proiecte sunt legitime. În primul, procesul VPN scrie el însuși un fișier prin propria opțiune log sau log-append. În al doilea, trimite înregistrările către loggerul de sistem, iar rsyslog sau journald decide unde ajung.

Sunt alternative, nu straturi. Un host care le activează pe amândouă ajunge cu două fișiere care nu se potrivesc, iar cel pe care îl citiți este adesea cel învechit. Alegeți calea în mod deliberat, apoi eliminați celălalt scriitor.

Citiți configurația efectivă a serviciului înainte de a schimba ceva, inclusiv fișierele drop-in care pot suprascrie fișierul de unit. O directivă prezentă în profilul pe care l-ați editat nu este dovada că este cea încărcată de procesul care rulează. Comparați unit-ul cu argumentele procesului, apoi cu fișierele pe care le-a deschis efectiv.

Numiți daemonul ca filtrul să poată fi îngust

Pe calea syslog, dați daemonului o identitate distinctă și filtrați după ea. O regulă care se potrivește cu numele de program al acestei instanțe VPN ține înregistrările ei în afara unui fișier partajat a cărui politică de păstrare aparține altcuiva.

Regulile înguste fac și următoarea întrebare cu răspuns posibil: care serviciu a produs această linie? Un filtru care se potrivește cu tot ce conține cuvântul VPN va aduna bucuros traficul unui al doilea tunel și le va estompa pe amândouă. Potriviți identificatorul exact pe care unit-ul îl transmite loggerului.

Închideți regula după acțiune ca înregistrările să nu cadă și în destinația implicită. Liniile duplicate în două fișiere par o eroare de jurnalizare și în realitate sunt o oprire lipsă. Acea singură omisiune dublează și costul pe disc al politicii de păstrare.

Rotiți fără a pierde descriptorul

Când daemonul scrie fișierul, logrotate redenumește calea, dar procesul își păstrează descriptorul deschis. Înregistrările noi continuă în fișierul redenumit până când ceva forțează procesul să redeschidă calea originală; de aceea o rotație poate părea că funcționează în timp ce fișierul nou rămâne gol.

Soluția este o acțiune postrotate care declanșează comportamentul documentat de reîncărcare sau repornire a serviciului. Trimiterea unui semnal către logger este o acțiune complet diferită și nu face nimic pentru un daemon care își ține propriul fișier.

Acolo unde redeschiderea este imposibilă, copytruncate este soluția de rezervă: copiați fișierul, apoi trunchiați-l la loc. Păstrează descriptorul valid cu prețul pierderii a tot ce se scrie între copiere și trunchiere, deci este un schimb, nu o soluție. Sub sarcină, acea lacună poate înghiți exact defecțiunea pe care încercați să o prindeți.

Alegeți una din cele două pentru fiecare fișier și notați alegerea, pentru că amestecarea lor pe aceeași cale produce lacune foarte greu de atribuit mai târziu. Un cititor care găsește ambele tipare într-un director nu poate spune care este cel autoritar.

Stabiliți păstrarea după fereastra incidentului

Păstrarea, compresia și dimensiunea maximă ar trebui să decurgă din cât de departe investigați cu adevărat. O fereastră de șapte zile cu compresie și un plafon de dimensiune este un punct de plecare rezonabil pentru multe implementări; un număr copiat dintr-un tutorial nu este.

Țineți politica într-un singur loc. Dacă logrotate rotește fișierul și rsyslog îl rotește la fel, câștigă a doua rotație, iar schema de denumire a primeia supraviețuiește ca dezordine. Alegeți proprietarul, dezactivați cealaltă rotație și notați decizia lângă politică.

Documentația rsyslog acoperă modelul său de rutare și acțiuni, în timp ce documentația serviciului OpenVPN rămâne autoritatea pentru opțiunile de jurnalizare ale daemonului însuși. Niciuna nu vă decide politica de păstrare în locul dumneavoastră.

Testați o rotație și un eveniment nou

Forțați o singură rotație și apoi generați un eveniment nou, cum ar fi o autentificare eșuată. Confirmați că înregistrarea nouă apare în fișierul nou și că fișierul vechi a încetat să crească.

Verificați și permisiunile fișierului nou, pentru că o rotație care îl recreează cu alt proprietar rupe scriitorul la următoarea scriere și produce o lacună care arată ca o cădere. Comparați proprietarul și modul cu contul serviciului înainte de a pleca. Apoi confirmați că arhiva comprimată este lizibilă, căci o arhivă pe care nimeni nu o poate deschide nu este păstrare. O citire rapidă a celei mai recente înregistrări din fișierul vechi dovedește atât compresia, cât și permisiunile.

Încheiați notând proprietarul fiecărui pas: ce componentă scrie, care rotește și unde trăiește politica de păstrare. Acea notă transformă următorul incident de jurnalizare într-o verificare de cinci minute în loc de o după-amiază în care ghiciți ce strat a pierdut linia.