Tinyproxy-logrotasie: waarom maxsize 100M nie 'n harde perk is nie

logrotate kontroleer maxsize net wanneer dit hardloop. Stel die kontrolefrekwensie en die herproses van die log se heropening saam met die drempel in.

'n maxsize 100M-inskrywing is 'n rotasie-sneller, nie 'n lewende perk op Tinyproxy se logleer nie. As logrotate een keer per dag loop, kan die leer verby 100 MB groei voor die volgende kontrole.

Vir Tinyproxy wat 'n direkte LogFile skryf, voeg 'n beleid soos hierdie by sy bestaande logrotate-stanza in:

daily
maxsize 100M
rotate 7
compress
delaycompress

Behou die geinstalleerde stanza se korrekte pad, eienaarskap, create-regte en diensspesifieke postrotate-hantering. Hierdie fragment lewer die bewaringsbeleid, nie die volledige diensintegrasie nie.

Reel 'n meer gereelde logrotate-oproep as daaglikse kontroles te veel groei laat. Elke oproep evalueer die reels; dit roteer nie noodwendig nie. Met groottegedrewe rotasie beteken rotate 7 sewe geroteerde leers en kan dit minder as sewe dae verteenwoordig.

Die heropening voltooi die rotasie

Nadat die leer hernoem is, moet Tinyproxy sy log heropen. Tinyproxy dokumenteer SIGUSR1 as die herlaai van konfigurasie en die sluit en heropen van die logleer; dit herlaai ook filterkonfigurasie. Behoud 'n verpakte helper wat reeds die korrekte aksie doen eerder as om 'n sein of PID-leerligging te raai.

Die verwydering van die aktiewe leer koordineer nie daardie heropening nie. copytruncate vermy die hernoem-en-heropen-reeling, maar het 'n gedokumenteerde interval waarin data verlore kan gaan tydens kopiering en afkapping.

As die proxy logs na Syslog stuur, pas bewaring by die ontvangende logstelsel toe eerder as om 'n reel by te voeg vir 'n leer wat Tinyproxy nie skryf nie.

Verwante artikels