Le metriche dicono che qualcosa non va; i log dicono perché. In un homelab con un hypervisor, alcune macchine virtuali, una decina di container, un router e un NAS, i log sono sparsi ovunque: nel journal di ogni sistema Linux, nei file di ogni applicazione, nella memoria limitata del router. Quando un servizio si ferma alle tre di notte, ricostruire cosa è successo saltando da una macchina all'altra è lento, e a volte impossibile perché il log è stato sovrascritto.
Perché centralizzare
Raccogliere i log in un unico punto offre vantaggi concreti:
- una sola ricerca per trovare un errore su tutte le macchine;
- correlazione temporale: vedere che il riavvio di un container coincide con un errore del disco sul NAS;
- sopravvivenza dei dati: se una macchina si blocca o viene reinstallata, i suoi ultimi log restano altrove;
- dispositivi senza memoria: router, switch e access point conservano pochi log e li perdono al riavvio.
I mattoni di base
syslog
Il protocollo syslog è il denominatore comune: quasi tutti i dispositivi di rete, i NAS e i sistemi Unix sanno inviare messaggi a un server syslog remoto, tradizionalmente sulla porta 514 in UDP. Implementazioni come rsyslog e syslog-ng possono ricevere quei messaggi e scriverli su file, divisi per host.
È la soluzione più semplice: un server che riceve, una cartella per dispositivo, una rotazione dei file con logrotate. Per molti homelab basta.
journald
Sulle distribuzioni con systemd, i log finiscono nel journal, che memorizza campi strutturati come unità, priorità e identificativo del processo. Il journal può inoltrare a syslog oppure essere letto direttamente da un agente di raccolta. Comandi come journalctl -u nomeservizio --since "1 hour ago" restano preziosi per l'analisi locale.
Docker
Per impostazione predefinita Docker conserva l'output dei container in file JSON sull'host. Senza un limite, crescono senza fine: conviene impostare nel file di configurazione del demone le opzioni max-size e max-file del driver di log. Un agente può poi leggere quei file e inviarli al sistema centrale.
Loki: log indicizzati per etichette
Grafana Loki è un sistema di archiviazione dei log pensato per affiancare Prometheus. La sua idea chiave è non indicizzare il testo completo dei messaggi, ma solo un piccolo insieme di etichette, come host, servizio e livello. Il contenuto viene compresso e salvato in blocchi. Ne risulta un sistema leggero, adatto a hardware modesto.
L'architettura tipica:
- un agente su ogni macchina legge journal, file e log dei container e li invia a Loki; storicamente si usava Promtail, oggi Grafana indica come successore il suo agente Alloy;
- Loki riceve, comprime e conserva;
- Grafana interroga Loki con il linguaggio LogQL e mostra i risultati accanto ai grafici delle metriche.
Un esempio di interrogazione LogQL:
{host="pve1", unit="pveproxy.service"} |= "error"
seleziona i log del servizio web di Proxmox su un host e filtra le righe che contengono «error».
Le stesse regole delle metriche valgono per le etichette: devono avere pochi valori possibili. Usare come etichetta l'indirizzo IP del client o l'identificativo di una richiesta moltiplica i flussi e appesantisce il sistema; quei dati vanno cercati nel testo.
Alternative
- Graylog: interfaccia di ricerca completa, flussi e regole di elaborazione; richiede un motore di ricerca come OpenSearch e più memoria.
- Pila Elastic o OpenSearch: indicizzazione completa del testo, ricerche molto potenti, ma consumi di RAM e disco importanti per un homelab.
- Solo rsyslog: minimo indispensabile, nessuna interfaccia, ricerca con grep.
Nel mio lavoro, per una rete domestica, tendo a partire da rsyslog per i dispositivi di rete e Loki per server e container: si integra con i cruscotti già esistenti e chiede poche risorse.
Conservazione e privacy
I log contengono informazioni sensibili: nomi utente, indirizzi IP, percorsi di file, a volte dati delle richieste. Alcune regole di buon senso:
- definire un periodo di conservazione, per esempio 30 o 90 giorni, e applicarlo con la configurazione di Loki o con la rotazione dei file;
- limitare l'accesso all'interfaccia di consultazione a una rete di amministrazione;
- non inviare i log fuori casa senza cifratura; tra sedi diverse si usa TLS o una VPN;
- evitare che le applicazioni scrivano password o token nei log, controllando il livello di dettaglio configurato.
Ricerche utili da salvare
Alcune interrogazioni meritano un posto fisso in una dashboard:
- tentativi di accesso SSH falliti su tutti gli host;
- errori di I/O dei dischi nel log del kernel;
- container che si riavviano ripetutamente;
- errori di autenticazione sull'interfaccia dell'hypervisor;
- messaggi del router su disconnessioni della linea.
Collegando alcune di queste a regole di allerta, i log diventano una fonte di avvisi oltre che uno strumento di indagine.
In sintesi
- Centralizzare i log permette ricerche uniche, correlazioni e conservazione dopo un guasto.
- syslog raccoglie i dispositivi di rete; journald e i log dei container richiedono un agente.
- Loki indicizza solo poche etichette e resta leggero; si consulta da Grafana con LogQL.
- Limiti di dimensione per i log dei container e un periodo di conservazione evitano dischi pieni.
- I log contengono dati sensibili: accesso ristretto e trasmissione cifrata.
