Hvem eier OpenVPN-loggene: dæmonen, rsyslog eller logrotate?

Loggrotasjon bryter sammen på en forutsigbar måte: tre komponenter tror hver for seg at de eier filen, og resultatet er en rotet logg som fortsetter å vokse mens den nye blir stående tom. Dæmonen holder en deskriptor, logrotate gir stien nytt navn, og rsyslog skriver et helt annet sted. Velg én skriver og én rotator før du legger enda en regel på haugen. Sjekklisten nedenfor går i den rekkefølgen fordi hvert senere steg avhenger av det.

Bestem hvem som skriver filen

To design er legitime. I det første skriver VPN-prosessen selv en fil via sitt eget log- eller log-append-alternativ. I det andre sender den oppføringer til systemloggen, og rsyslog eller journald bestemmer hvor de havner.

De er alternativer, ikke lag. En vert som slår på begge, ender med to filer som ikke stemmer overens, og den du leser er ofte den foreldede. Velg stien med vilje, og fjern deretter den andre skriveren.

Les den effektive tjenestekonfigurasjonen før du endrer noe, inkludert drop-ins som kan overstyre unit-filen. Et direktiv i profilen du redigerte er ikke bevis for at det er det den kjørende prosessen lastet. Sammenlign unit med prosessens argumenter, og deretter med filene den faktisk åpnet.

Gi dæmonen et navn slik at filteret kan være smalt

På syslog-stien gir du dæmonen en egen identitet og filtrerer på den. En regel som passer på programnavnet til denne VPN-forekomsten holder oppføringene dens utenfor en delt fil hvis oppbevaringspolicy tilhører noe annet.

Smale regler gjør også det neste spørsmålet svarbart: hvilken tjeneste produserte denne linjen? Et filter som passer på alt med ordet VPN i, samler gjerne trafikken til en andre tunnel og gjør begge utydelige. Match på den nøyaktige identifikatoren unit-en gir til loggen.

Lukk regelen etter handlingen slik at oppføringene ikke også faller gjennom til standardmålet. Dupliserte linjer i to filer ser ut som en loggefeil og er egentlig en manglende stopp. Den ene utelatelsen dobler også diskkostnaden til oppbevaringspolicyen.

Roter uten å miste deskriptoren

Når dæmonen skriver filen, gir logrotate stien nytt navn, men prosessen beholder sin åpne deskriptor. Nye oppføringer fortsetter inn i den omdøpte filen til noe får prosessen til å åpne den opprinnelige stien på nytt; derfor kan en rotasjon se ut til å virke mens den nye filen blir stående tom.

Løsningen er en postrotate-handling som utløser tjenestens dokumenterte oppførsel for omlasting eller omstart. Å sende et signal til loggen er en helt annen handling og gjør ingenting for en dæmon som holder sin egen fil.

Der gjenåpning er umulig, er copytruncate reserveplanen: kopier filen, og kutt den deretter på stedet. Det holder deskriptoren gyldig på bekostning av alt som skrives mellom kopien og kuttingen, så det er en byttehandel og ikke en løsning. Under last kan det gapet sluke nettopp den feilen du prøver å fange.

Velg én av de to per fil og skriv valget ned, fordi å blande dem på samme sti gir gap som er svært vanskelige å tilskrive senere. En leser som finner begge mønstrene i én katalog, kan ikke si hvilket som er autoritativt.

Sett oppbevaringen fra hendelsesvinduet

Oppbevaring, komprimering og maksimal størrelse bør følge av hvor langt tilbake du faktisk undersøker. Et vindu på sju dager med komprimering og et størrelsetak er et rimelig utgangspunkt for mange utrullinger; et tall kopiert fra en veiledning er det ikke.

Hold policyen på ett sted. Hvis logrotate roterer filen og rsyslog også roterer den, vinner den andre rotasjonen, og den førstes navneskjema overlever som rot. Velg eieren, slå av den andre rotasjonen, og noter beslutningen ved siden av policyen.

Dokumentasjonen til rsyslog dekker rutings- og handlingsmodellen, mens dokumentasjonen til OpenVPN-tjenesten forblir autoritativ for dæmonens egne loggvalg. Ingen av dem bestemmer oppbevaringspolicyen din for deg.

Test én rotasjon og én ny hendelse

Tving fram én enkelt rotasjon og generer deretter én ny hendelse, for eksempel en mislykket autentisering. Bekreft at den nye oppføringen vises i den nye filen, og at den gamle filen sluttet å vokse.

Sjekk også rettighetene på den nye filen, fordi en rotasjon som gjenoppretter den med en annen eier bryter skriveren ved neste skriving og lager et gap som ser ut som en krasj. Sammenlign eier og modus med tjenestekontoen før du går. Bekreft deretter at det komprimerte arkivet er lesbart, siden et arkiv ingen kan åpne, ikke er oppbevaring. En rask lesing av den nyeste oppføringen i den gamle filen beviser både komprimeringen og rettighetene.

Avslutt med å notere eieren av hvert steg: hvilken komponent som skriver, hvilken som roterer, og hvor oppbevaringspolicyen bor. Den noten gjør den neste logghendelsen til en femminutters sjekk i stedet for en ettermiddag med gjetting på hvilket lag som mistet linjen.