Pulizia log server con logrotate

logrotate e il tool standard Linux per la rotazione e l'archiviazione dei file di log. Lavora in modo dichiarativo: tu definisci le politiche e lui esegue. Una configurazione corretta evita la saturazione del disco, mantiene log analizzabili e rispetta i requisiti di conservazione (anche normativi).

Concetti fondamentali

logrotate viene eseguito tipicamente da cron.daily tramite /etc/cron.daily/logrotate o da una unit systemd dedicata. Legge le configurazioni globali in /etc/logrotate.conf e i pezzi per servizio in /etc/logrotate.d/. Ogni stanza definisce: pattern di file, frequenza, retention, compressione, hook pre/post rotazione.

Direttive comuni

• daily/weekly/monthly: frequenza di rotazione.
• rotate N: numero di archivi da conservare.
• compress / delaycompress: compressione (gzip default).
• missingok: non fallire se il log manca.
• notifempty: non ruotare file vuoti.
• create MODE OWNER GROUP: ricrea il file dopo rotazione.
• postrotate ... endscript: comando da eseguire (es. reload del servizio).
• size 100M: rotazione basata su dimensione anziche tempo.

Esempio per Nginx

Un classico file /etc/logrotate.d/nginx ruota log giornalieri, conserva 14 archivi, comprime con gzip, ricrea i file con permessi 644 nginx adm e ricarica Nginx via signal. La parte postrotate tipicamente esegue kill -USR1 $(cat /run/nginx.pid) o systemctl reload nginx.

Procedura passo-passo

1. Identifica i log più voluminosi: du -sh /var/log/*.
2. Verifica le configurazioni esistenti in /etc/logrotate.d/.
3. Per ogni servizio applicativo crea uno snippet con frequenza e retention.
4. Imposta compressione e dimensione massima per evitare crescite anomale.
5. Includi sempre missingok e notifempty per evitare errori spurii.
6. Inserisci postrotate per ricaricare servizi che mantengono il file aperto.
7. Testa con logrotate -d /etc/logrotate.d/nomeservizio in modalita debug.
8. Forza un giro con logrotate -f /etc/logrotate.d/nomeservizio.
9. Monitora il disco e regola retention in funzione di crescita reale.

Errori comuni e come risolverli

• File non ruotato perché aperto da un demone: usa copytruncate o un postrotate che ricarichi il servizio.
• Permessi errati dopo rotazione: definisci sempre create.
• Retention troppo aggressiva: alcune normative richiedono conservazione per 6-12 mesi.
• Compressione non applicata: verifica con ls /var/log/ di vedere file .gz; in caso contrario controlla la stanza.

Domande frequenti

D: Posso integrare con un log server centralizzato?
R: Si: rsyslog, journald-remote, Loki, Graylog raccolgono e archiviano in remoto, logrotate gestisce la copia locale.

D: Cosa succede se logrotate fallisce?
R: I file crescono indefinitamente. Monitora /var/lib/logrotate/status e i log di cron.

D: copytruncate vs reload, quale scegliere?
R: reload e più pulito (nessuna riga persa); copytruncate serve quando il servizio non puo essere ricaricato.

Approfondimento tecnico: copytruncate vs reload

Quando un processo tiene aperto un file di log, semplicemente rinominarlo lascia il processo che continua a scrivere nel vecchio file: il file nuovo resta vuoto. Due strategie risolvono il problema. reload: dopo la rotazione, logrotate invia un segnale (SIGHUP, SIGUSR1) o esegue systemctl reload servizio nel blocco postrotate: il servizio chiude e riapre i file aprendo quello nuovo. copytruncate: logrotate copia il file aperto in un'archivio, poi lo tronca a zero: il processo non si accorge di nulla e continua a scrivere dalla nuova posizione. Lo svantaggio: c e una finestra in cui le righe scritte tra copia e truncate possono essere perse.

Per i log JSON strutturati moderni (containerd, journald in json format) molte applicazioni gestiscono internamente la rotazione, rendendo logrotate non necessario per quei file.

Scenari d'uso reali

Un server Nginx con 10 vhost ruota log giornalieri, conserva 30 giorni, ricarica nginx via kill -USR1: niente connessioni perse, rotazione pulita.

Un servizio Java enterprise con logback usa la sua rotazione interna: logrotate gestisce solo i log di systemd-stdout via journald.

Un server di Docker container usa logrotate per i log JSON in /var/lib/docker/containers/ evitando saturazione disco.

Checklist operativa logrotate

• File di config per servizio in /etc/logrotate.d/.
• compress, missingok, notifempty sempre presenti.
• postrotate con reload o copytruncate secondo il servizio.
• Retention proporzionata a normativa e business need.
• Test in modalita debug prima di mettere in produzione.
• Monitoring dello stato in /var/lib/logrotate/status.
• Integrazione con log centralizzato (rsyslog, Loki).

Risorse e riferimenti

man logrotate e la documentazione GNU. Per log centralizzati moderni considera Grafana Loki, Elastic Stack, Graylog. Su systemd journalctl ha rotazione integrata via journald.conf. Per debug ricorda logrotate -d per dry-run e logrotate -f per forzare.

Considerazioni economiche e organizzative

Implementare correttamente quanto descritto in questo articolo su pulizia log server con logrotate richiede tempo, formazione e talvolta investimenti hardware o software. La buona notizia e che il ritorno e quasi sempre positivo: meno incidenti, meno tempo speso in troubleshooting reattivo, maggiore predicibilita dei servizi. Stima sempre il costo del downtime per il tuo business: anche poche ore l'anno di indisponibilita possono giustificare investimenti che a prima vista sembrano sovradimensionati.

Sul piano organizzativo, la documentazione e il fattore decisivo. Un sistema brillantemente configurato ma non documentato e una bomba a orologeria: il giorno in cui il sysadmin originale lascia l'azienda, ogni intervento diventa archeologia. Mantieni runbook aggiornati, versionali in git, fai pratica di lettura nei momenti di calma e non solo durante gli incidenti.

Glossario rapido dei termini chiave

RTO (Recovery Time Objective): tempo massimo entro cui un servizio deve tornare operativo dopo un'incidente. RPO (Recovery Point Objective): perdita massima accettabile di dati misurata nel tempo (es. 1 ora di transazioni). SLA (Service Level Agreement): contratto formale che definisce livelli di servizio e penali. SLO/SLI (Service Level Objective/Indicator): metriche interne di qualità usate per misurare e mantenere lo SLA. MTBF/MTTR: tempo medio tra guasti e tempo medio di ripristino, indicatori di affidabilità. Idempotenza: proprietà di un'operazione che, applicata più volte, produce lo stesso risultato della singola applicazione (fondamentale per automazione).

Hai bisogno di aiuto?

Se hai dubbi sulla gestione server, il team di G Tech Group puo aiutarti. Contattaci tramite il modulo di contatto.