Rotation log: gestire la dimensione dei log

I log di WordPress (debug.log, error_log PHP, log custom) possono crescere senza controllo e riempire il disco, causando l’errore 'no space left on devicè che blocca write su DB e file. La rotation log è la pratica per gestire questo problema.

Perchè serve la rotation

Senza rotation, debug.log può arrivare a GB e generare problemi: 1) disco pieno blocca MySQL e nginx, 2) editor non aprono file >100MB, 3) tail/grep diventano lenti, 4) backup richiedono tempi infiniti. La rotation taglia il file a una dimensione, archivia il vecchio (zip), e ricomincia da zero.

Strumenti disponibili

Linux: logrotate (cron quotidiano, config in /etc/logrotate.d/). WP Error Monitor: WPEM_LOG_MAX_SIZE auto-rotation interna quando il log supera dimensione. PHP error_log: open_basedir + log_errors_max_len per limitare singolo errore. Plugin: WP Log Viewer fornisce rotation built-in.

Configurazione consigliata

Per debug.log usa logrotate con: rotate 7 (mantieni 7 archivi), daily, compress, missingok, copytruncate. Così' hai 7 giorni di storia, file compressi (saving 80% spazio), tronca senza interrompere applicazione. Per WP Error Monitor i log locali in /tmp vengono ruotati automaticamente.

Logrotate esempio completo

Esempio /etc/logrotate.d/wordpress con direttive: daily ruota ogni giorno, rotate 14 mantiene 14 archivi (2 settimane), compress comprime (gzip), delaycompress non comprime ultimo file (per tail), missingok ok se mancante, copytruncate per app che tengono FD aperto, postrotate ricarica nginx se necessario. Configurazione testata in produzione su decine di siti G Tech.

Loki/Promtail per centralized logs

Per setup moderno, sostituisci/affianca logrotate con Loki+Promtail: Promtail tail il log e invia a Loki (storage tipo Prometheus per log). Grafana visualizza. Vantaggi: ricerca veloce, retention configurabile per stream, dashboard ricche. WP Error Monitor invia structured logs direttamente a Loki tramite WPEM_LOKI_URL endpoint. Setup tipico G Tech: Loki + Grafana su 1 VM, tutti i siti inviano via Promtail.

Compression e storage cost

Log compressi con gzip occupano 10-20% dello spazio originale. Logrotate con direttiva 'compress' applica automaticamente. Per long-term retention, compressione xz è ancora migliore (5-10% spazio) ma richiede più CPU. Calcolo storage: 100MB log/giorno x 30gg retention = 3GB raw, 300-600MB compressi. Pianifica con margine 2x per crescita imprevista. Per cold storage (>30gg), sposta su S3 Glacier (~1 euro/TB/mese) tramite cron mensile: i log diventano inaccessibili istantaneamente (richiamo 1-12h) ma costi minimi. WP Error Monitor automatizza il flow se configuri S3 endpoint.

Search performance con index

Log compressi sono difficili da searchare con grep tradizionale. Soluzione: indici inversi tipo Loki o Elasticsearch. Loki indicizza solo metadata (labels), non contenuto: trade-off ottimo per WordPress (cerchi tipicamente per timestamp+sito). Elasticsearch indicizza full-text ma costoso (CPU/RAM elevati). WP Error Monitor offre ricerca via PostgreSQL FTS sui eventi (campo description), sufficiente per la maggior parte delle query. Per query complesse oltre 90gg, suggeriamo export a Elasticsearch via lo schedule export.

Costi storage long-term

Costi storage long-term per log WordPress dipendono dal volume eventi: sito blog low-traffic ~50MB/mese eventi, ecommerce alto traffico ~5GB/mese. Per retention 1 anno su S3 con Lifecycle a Glacier dopo 90gg: blog ~0.50€/anno, ecommerce ~30€/anno. Costi trascurabili rispetto al valore di forensic, audit, trend analysis. WP Error Monitor include retention 90gg standard, 1 anno per piano premium. Per retention oltre serve setup S3 esterno cliente, accesso dati conservato indefinitamente. Compliance GDPR mantenuta con anonymization automatica.

Audit log rotation health

Implementa audit periodico della rotation log: verifica che ruoti effettivamente, che file vecchi siano compressi, che disk usage trend sia sostenibile. Setup grafana panel con disk usage /var/log per ogni server gestito, alert se cresce più del 10%/settimana sostenuto.

Procedura passo-passo

1. Crea /etc/logrotate.d/wordpress con configurazione standard.
2. Specifica path log: /var/log/wp/*.log e /var/www/*/wp-content/debug.log.
3. Imposta rotate 7, daily, compress, missingok, copytruncate.
4. Verifica configurazione: logrotate -d /etc/logrotate.d/wordpress.
5. Forza prima rotation: logrotate -f /etc/logrotate.d/wordpress.
6. Configura WPEM_LOG_MAX_SIZE=50M nei wp-config.php dei siti.
7. Monitora dimensione log con script cron quotidiano.
8. Alza alert se /var partition supera 80% utilizzo.
9. Crea config logrotate completo con postrotate hook.
10. Setup Loki+Promtail per centralized logs.

Errori comuni e come risolverli

• Log non viene ruotato: Permessi cron o utente logrotate: verifica /var/log/logrotate.log.
• Applicazione non scrive più dopo rotation: Manca copytruncate: l’inode cambia e l’app punta al vecchio file.
• Disco pieno nonostante rotation: Archivi non eliminati: rotate value troppo alto o disk monitor non funziona.
• Logrotate non comprime: delaycompress su rotate 1 = mai compresso: aumenta rotate.
• Loki disk pieno: Configura retention con loki.config retention_period.

Domande frequenti

D: Posso ruotare ogni ora?
R: Sì, usa hourly invece di daily, ma sovraccarica I/O.

D: Quanto disco serve per log?
R: Tipicamente 1-5GB per sito attivo con 7gg history.

D: WP Error Monitor manda log al CRM?
R: Solo eventi (non interi log): per archivio centrale usa Loki/ELK.

D: Quanto storage per Loki?
R: 1GB per 100MB log compressi: dimensiona per 30gg retention.

D: Posso usare ELK invece di Loki?
R: Sì, più potente ma più resource-hungry: serve cluster Elasticsearch.

Hai bisogno di aiuto?

Se vuoi affidare il monitoraggio WordPress al team di G Tech Group, scrivici tramite il modulo di contatto.