Logging e monitoraggio di un VPS: come capire cosa succede ai tuoi servizi 📒🖥️

Un sito è lento. Un servizio non risponde. Il disco si riempie durante la notte. Oppure un’applicazione che fino a ieri funzionava senza problemi comincia a restituire errori casuali.

Quando succede, la prima reazione è spesso quella di collegarsi al server e iniziare a controllare tutto un po’ a caso. Si riavvia un servizio, si svuota una cache, si modificano due configurazioni e magari il problema scompare. Peccato che, senza capire che cosa sia successo, potrebbe ripresentarsi qualche ora dopo.

È qui che entrano in gioco logging e monitoraggio. Non servono soltanto alle grandi infrastrutture aziendali: sono strumenti utilissimi anche per chi gestisce un VPS, un server domestico o una manciata di applicazioni self-hosted. 🔎

Log, metriche e monitoraggio: non sono la stessa cosa

Questi termini vengono spesso usati come se indicassero la stessa attività, ma descrivono aspetti differenti del comportamento di un sistema.

• Log: registrano eventi specifici, come un errore PHP, un accesso SSH, una richiesta HTTP fallita o l’avvio di un servizio.
• Metriche: rappresentano valori misurabili nel tempo, per esempio utilizzo della CPU, RAM disponibile, spazio su disco e numero di richieste al secondo.
• Monitoraggio: raccoglie e interpreta informazioni per capire se un sistema sta funzionando come previsto.
• Alerting: invia una notifica quando si verifica una condizione che richiede attenzione, per esempio un disco quasi pieno o un servizio non disponibile.

Immagina che il tuo sito WordPress diventi improvvisamente lento. Una metrica potrebbe mostrarti che la CPU è vicina al 100%. I log potrebbero rivelare numerosi errori PHP o richieste ripetute a un endpoint. Il monitoraggio ti aiuta a capire quando è iniziato il problema e se sta peggiorando.

Un sistema maturo combina queste informazioni invece di affidarsi a un singolo indicatore.

1. Prima di tutto: scopri quali servizi stai eseguendo

Su un VPS Linux è facile accumulare servizi nel corso del tempo: web server, database, PHP-FPM, cron, agent di backup, servizi di posta e applicazioni personalizzate. Prima di impostare un sistema di monitoraggio complesso, conviene conoscere quelli che devono rimanere attivi.

Se il sistema utilizza systemd, puoi ottenere una panoramica dei servizi attivi con:

systemctl --type=service --state=running

Per controllare un servizio specifico:

systemctl status nome-servizio

Sostituisci nome-servizio con il nome reale del servizio. Il comando mostra lo stato corrente e, spesso, alcune righe recenti di log utili per una prima diagnosi.

Se un servizio è gestito da un pannello hosting, verifica prima la documentazione del pannello e i nomi effettivi delle unità systemd. Non tutti gli ambienti utilizzano le stesse convenzioni.

2. Come leggere i log con journalctl

Su molte distribuzioni Linux, systemd raccoglie gli eventi dei servizi nel journal. Lo strumento da conoscere è journalctl.

Per visualizzare gli ultimi eventi del sistema:

journalctl -n 100

Per controllare i messaggi relativi a un servizio specifico:

journalctl -u nome-servizio

Se stai indagando su un problema recente, puoi limitare la ricerca agli ultimi trenta minuti:

journalctl -u nome-servizio --since "30 minutes ago"

Per seguire gli eventi mentre accadono:

journalctl -u nome-servizio -f

Quest’ultimo comando è particolarmente comodo quando stai riproducendo un errore: lasci il terminale aperto, esegui l’operazione che causa il problema e osservi se compaiono messaggi significativi.

La documentazione ufficiale è disponibile nella pagina man di journalctl.

3. I log del web server e di PHP

Se gestisci siti web, non puoi fermarti ai log generici di sistema. Un errore può verificarsi a diversi livelli: web server, PHP, applicazione, database o rete.

Per esempio, un errore HTTP 500 non identifica automaticamente la causa. Potrebbe derivare da un’eccezione PHP, da una configurazione errata, da un permesso insufficiente o da un servizio a valle che non risponde.

In un ambiente con OpenLiteSpeed o LiteSpeed Enterprise, WordPress e PHP, conviene sapere dove vengono scritti:

• i log del web server;
• gli eventuali log di PHP e PHP-FPM, in base alla configurazione;
• il log degli errori di WordPress, se abilitato temporaneamente o gestito in modo controllato;
• i log di MariaDB;
• i log delle applicazioni personalizzate.

I percorsi dipendono dalla distribuzione, dal pannello hosting e dalle impostazioni applicate. Evita di copiare percorsi trovati in una guida senza verificare che corrispondano al tuo server.

Nel caso di WordPress, il debug può essere utile per individuare errori PHP, ma non dovrebbe essere lasciato indiscriminatamente attivo in produzione. I file di log possono contenere informazioni interne, percorsi del filesystem e dettagli che non devono essere esposti pubblicamente.

La regola pratica è semplice: raccogli informazioni sufficienti per diagnosticare il problema, ma non trasformare il sistema di logging in una raccolta incontrollata di dati sensibili.

4. Controlla CPU, RAM e spazio su disco

Non tutti i problemi sono causati dal codice. A volte l’applicazione è corretta, ma il server non ha più risorse sufficienti per gestire il carico.

Utilizzo di CPU e processi

Per una panoramica interattiva dei processi puoi utilizzare:

top

Se è installato, anche htop offre una vista più comoda dei processi e del carico del sistema.

Non interpretare però un valore elevato di CPU come una prova automatica di un attacco o di un bug. Può essere dovuto a backup, scansioni pianificate, indicizzazione, traffico legittimo o attività temporanee. È importante confrontare i dati con gli orari e gli eventi registrati.

Memoria disponibile

free -h

Questo comando mostra la memoria utilizzata e disponibile in un formato leggibile. Su Linux, la RAM usata per cache può essere liberata quando necessario: per questo il campo “used” da solo non basta a stabilire se il server sia davvero sotto pressione.

Controlla anche eventuali segnali di esaurimento della memoria o interventi dell’OOM killer nei log di sistema.

Spazio su disco

df -h

Il comando mostra l’occupazione dei filesystem. Per capire quali directory consumano spazio, puoi usare:

du -xhd1 /var

Il comando precedente è un esempio per Linux con una versione di du che supporta queste opzioni. Potrebbe essere necessario adattarlo alla distribuzione e ai permessi disponibili.

Controlla soprattutto log, backup locali, cache e file temporanei. Non cancellare directory o file soltanto perché occupano molto spazio: prima individua chi li utilizza e se esiste una procedura corretta di rotazione o pulizia.

5. Come capire se un sito è davvero raggiungibile

Un servizio può risultare attivo secondo systemd e, allo stesso tempo, non essere raggiungibile dagli utenti. Potrebbe esserci un problema DNS, TLS, firewall, reverse proxy o applicativo.

Per una prima verifica HTTP puoi utilizzare:

curl -I https://esempio.it

Il comando invia una richiesta HTTP HEAD e mostra gli header della risposta. Non tutti i server o gli endpoint gestiscono HEAD nello stesso modo, quindi un risultato negativo non dimostra necessariamente che il sito sia completamente irraggiungibile.

Per verificare anche una risposta con contenuto, puoi provare una richiesta GET:

curl -sS -o /dev/null \
  -w "HTTP %{http_code} - tempo %{time_total}s\n" \
  https://esempio.it/

Questo esempio mostra il codice HTTP e il tempo totale della richiesta. È utile per controlli rapidi, ma non misura da solo l’intera esperienza dell’utente: non valuta rendering JavaScript, interazioni, immagini o funzionamento dei flussi applicativi.

Se il sito utilizza Cloudflare o un altro proxy, ricorda che una verifica dall’esterno può misurare il percorso attraverso quel proxy, non necessariamente lo stato diretto del server di origine.

6. Gli alert: meglio pochi e utili che cento notifiche ignorate

Un sistema di monitoraggio che non avvisa nessuno quando qualcosa si rompe è poco utile. Ma anche un sistema che invia notifiche per ogni variazione minima finisce per essere ignorato.

Per un VPS con alcuni siti e servizi self-hosted, puoi iniziare da questi controlli:

• Disponibilità: il sito o il servizio non risponde per un intervallo significativo.
• Disco: lo spazio libero scende sotto una soglia prudente.
• Certificati TLS: un certificato sta per scadere o il rinnovo non è riuscito.
• Backup: un’esecuzione pianificata non è stata completata o il file atteso non esiste.
• Database: il servizio non risponde o si verificano errori ripetuti.
• Risorse: CPU, memoria o carico rimangono anomali per un periodo significativo.

La soglia va scelta in base al servizio. Un utilizzo elevato della CPU per dieci secondi potrebbe essere normale durante un backup; una crescita costante dell’occupazione del disco per giorni potrebbe invece indicare un problema strutturale.

È utile anche distinguere tra avvisi informativi e problemi che richiedono un intervento immediato. Non tutte le notifiche devono svegliarti nel cuore della notte. 🌙

7. Quali strumenti utilizzare per un server self-hosted?

Non esiste un unico strumento ideale per tutti. La scelta dipende dal numero di servizi, dalla quantità di dati da raccogliere, dal tempo che vuoi dedicare alla manutenzione e dal fatto che preferisci un sistema leggero oppure una piattaforma completa.

Soluzione minimale: strumenti già presenti su Linux

Per iniziare, systemctl, journalctl, top, free, df e curl possono già aiutarti a diagnosticare moltissimi problemi.

Il vantaggio è che non devi installare un nuovo stack. Lo svantaggio è che la raccolta dei dati nel tempo, la visualizzazione centralizzata e gli alert automatici richiedono lavoro aggiuntivo.

Uptime Kuma: per controllare la disponibilità

Uptime Kuma è un progetto open source che consente di monitorare siti web e altri servizi e di inviare notifiche quando rileva problemi.

È una buona opzione quando la domanda principale è: “Il mio sito risponde? E da quanto tempo è offline?”. Non sostituisce però l’analisi dei log e delle metriche del server.

Prometheus e Grafana: per metriche e dashboard

Prometheus raccoglie e memorizza metriche nel tempo, mentre Grafana permette di costruire dashboard e visualizzazioni.

Insieme possono diventare una soluzione potente per monitorare CPU, RAM, disco, servizi e applicazioni. Tuttavia, richiedono configurazione e manutenzione: per un singolo sito personale potrebbero essere più di quanto serva.

OpenTelemetry: quando vuoi osservare anche le applicazioni

OpenTelemetry offre strumenti e convenzioni per raccogliere telemetria applicativa, tra cui trace, metriche e log, con l’obiettivo di aiutare a capire come si comportano i componenti di un sistema.

È particolarmente interessante quando un’applicazione comunica con più servizi e vuoi ricostruire il percorso di una richiesta. Per un semplice VPS può essere un passo successivo, non necessariamente il punto di partenza.

8. Sicurezza: i log possono contenere informazioni delicate

Registrare tutto non è una buona strategia. Nei log possono finire token, identificativi di sessione, indirizzi email, parametri delle richieste, dati personali e dettagli interni dell’infrastruttura.

Prima di centralizzare o conservare i log, considera alcune regole:

• Non registrare password, token di autenticazione o segreti in chiaro.
• Limita l’accesso ai file e alle dashboard di monitoraggio.
• Definisci una politica di conservazione: non tutto deve essere mantenuto per sempre.
• Proteggi le comunicazioni tra server e sistemi di raccolta.
• Verifica che i log non siano raggiungibili direttamente dal web.
• Evita che input non attendibili possano falsificare le righe di log tramite caratteri di controllo o messaggi costruiti ad arte.

La OWASP Logging Cheat Sheet è un buon riferimento per approfondire questi aspetti.

Ricorda inoltre che i log non sono necessariamente una fonte di verità completa: un’applicazione compromessa potrebbe manipolarli, un servizio potrebbe non registrare determinati eventi e una configurazione errata potrebbe lasciare lacune importanti. Per gli eventi di sicurezza più critici, valuta anche la protezione e la centralizzazione dei dati di audit.

9. Non dimenticare backup e verifiche di ripristino

Un backup programmato non è automaticamente un backup affidabile. Può fallire senza che te ne accorga, contenere file incompleti oppure risultare inutilizzabile quando arriva il momento di ripristinare il servizio.

Per questo conviene monitorare almeno:

• l’esito dell’ultima esecuzione;
• la presenza e la dimensione del backup atteso;
• lo spazio disponibile nella destinazione;
• eventuali errori di trasferimento;
• la possibilità concreta di ripristinare dati e configurazioni.

Il controllo più importante, anche se spesso viene dimenticato, è la prova periodica di ripristino. Un backup che non hai mai verificato è una promessa, non una certezza.

Un piano pratico per cominciare oggi

Se non hai ancora un sistema di monitoraggio strutturato, non installare subito cinque piattaforme diverse. Parti da una base essenziale e aggiungi complessità soltanto quando hai una necessità concreta.

1. Fai l’inventario: elenca siti, database, servizi e processi pianificati che devono funzionare.
2. Individua i log: annota dove trovare gli errori di web server, PHP, database e applicazioni.
3. Controlla le risorse: verifica CPU, memoria, disco e andamento dell’occupazione nel tempo.
4. Imposta controlli di disponibilità: inizia dai servizi più importanti e verifica che le notifiche arrivino davvero.
5. Monitora i backup: non limitarti a sapere che esistono; controlla esiti e ripristini.
6. Documenta gli incidenti: quando risolvi un problema, annota causa, sintomi e soluzione.

Conclusione: il monitoraggio serve a capire, non solo a guardare grafici

Gestire un VPS non significa soltanto installare software e verificare che la pagina iniziale si apra. Significa anche riuscire a capire cosa accade quando qualcosa smette di funzionare.

Log leggibili, metriche essenziali, controlli di disponibilità e notifiche ben configurate possono ridurre notevolmente il tempo necessario per diagnosticare un problema. E non è indispensabile partire da un’infrastruttura complicata: spesso gli strumenti già disponibili su Linux sono sufficienti per costruire una prima base solida.

La differenza vera arriva quando smetti di accorgerti dei problemi soltanto grazie a una segnalazione e inizi a rilevarli prima, con informazioni abbastanza precise da sapere dove guardare. 🛠️