1 19/10/2026 9 min

Netdata su Ubuntu 20.04 ha senso quando vuoi visibilità immediata su CPU, memoria, disco, rete, processi e servizi senza aspettare di costruire una stack di monitoraggio pesante. Il vantaggio pratico non è solo la dashboard in tempo reale: è la capacità di vedere il comportamento del server mentre il problema sta succedendo, non dieci minuti dopo nei grafici aggregati.

Su una macchina esposta in produzione, però, l’installazione non va trattata come un click-and-forget. La domanda corretta è: chi può vedere l’interfaccia, su quale porta, con quali credenziali e quanto traffico diagnostico vuoi conservare. Se chiarisci questi punti prima, eviti di ritrovarti con una console utile ma troppo aperta o con dati troppo brevi per capire un picco di carico.

Quando Netdata è la scelta giusta su Ubuntu 20.04

Netdata è adatto quando ti serve un livello di osservabilità locale, dettagliato e quasi in tempo reale. È utile per troubleshooting di performance, saturazione disco, spike di load, code applicative, anomalie di rete e problemi di memoria. Non sostituisce un sistema di alerting centralizzato ben progettato, ma lo completa bene come primo strato di diagnosi.

Su Ubuntu 20.04 gira senza particolari frizioni, anche su VPS piccole. L’impatto in termini di risorse è in genere contenuto, ma non nullo: se il server è già tirato, conviene verificare memoria libera e I/O prima di aggiungere un demone di monitoraggio sempre attivo.

Installazione rapida con repository ufficiale

Il metodo più lineare è usare lo script ufficiale di installazione. È la strada più semplice per avere pacchetti aggiornati e configurazione iniziale già pronta. Prima di eseguirlo, controlla che il sistema abbia accesso a Internet e che il firewall non blocchi la porta web di Netdata, che di default è la 19999.

1) Aggiorna l’indice dei pacchetti e installa gli strumenti di base necessari per il download e l’esecuzione dello script.

sudo apt update
sudo apt install -y curl bash

2) Avvia l’installazione ufficiale. Lo script rileva la distribuzione e configura il servizio systemd.

bash <(curl -Ss https://my-netdata.io/kickstart.sh)

3) Al termine, verifica che il servizio sia attivo e in ascolto.

systemctl status netdata --no-pager
ss -ltnp | grep 19999

Il risultato atteso è un servizio active (running) e una socket TCP in ascolto su 0.0.0.0:19999 o su un indirizzo specifico se hai già limitato il binding. Se non compare nessuna porta, il problema è prima del livello web: controlla i log del servizio.

journalctl -u netdata -n 100 --no-pager

Accesso iniziale e lettura della dashboard

Dopo l’installazione, apri nel browser http://IP_DEL_SERVER:19999/. Se sei su un ambiente remoto, non considerare questo accesso come definitivo: è solo un test di funzionamento. In produzione, esporre direttamente la porta 19999 su Internet senza restrizioni è una scelta debole, anche se l’istanza è solo in lettura.

La dashboard mostra grafici granulari per CPU, RAM, swap, filesystem, I/O, rete, processi e servizi rilevati. Il valore pratico sta nel correlare i picchi: per esempio, un aumento del tempo di risposta HTTP spesso coincide con un picco di I/O disco o con una pressione di memoria che porta il kernel a usare swap. Netdata rende visibile questa relazione in pochi secondi.

Se la pagina si apre ma i grafici sono vuoti o parziali, non partire dalla reinstallazione. Verifica prima che il demone abbia accesso alle metriche del sistema e che non ci siano errori nei log:

journalctl -u netdata --since "10 min ago" --no-pager
ls -ld /proc /sys /var/cache/netdata

Hardening minimo: non lasciare Netdata esposto senza filtro

La prima correzione sensata è limitare l’accesso. Le opzioni migliori dipendono dal tuo scenario: VPN, reverse proxy con autenticazione, allowlist IP sul firewall oppure binding solo su localhost se usi un tunnel SSH o un proxy locale. La scelta va fatta in base a chi deve usare Netdata e da dove.

Se vuoi una misura immediata e reversibile, il firewall è il primo passo. Con UFW puoi consentire solo la tua subnet di amministrazione e bloccare il resto. Esempio:

sudo ufw allow from 203.0.113.0/24 to any port 19999 proto tcp
sudo ufw status numbered

Il controllo atteso è una regola esplicita per la porta 19999 e nessuna apertura globale non voluta. Se la macchina è dietro un reverse proxy, puoi anche evitare l’esposizione diretta e pubblicare Netdata solo su localhost, lasciando al proxy la terminazione TLS e l’autenticazione.

Per il binding locale, il file di configurazione principale si trova in /etc/netdata/netdata.conf. Se devi adattarlo, non editare a caso il file globale: crea uno snippet dedicato o usa la configurazione assistita del sistema quando disponibile. Prima di cambiare, fai una copia di sicurezza del file corrente.

sudo cp /etc/netdata/netdata.conf /etc/netdata/netdata.conf.bak.$(date +%F-%H%M)

Una modifica tipica consiste nel limitare l’ascolto a 127.0.0.1 o a un’interfaccia privata. Dopo il change, riavvia il servizio e verifica che la porta non sia più pubblica.

sudo systemctl restart netdata
ss -ltnp | grep 19999

Autenticazione, TLS e reverse proxy

Se devi esporre Netdata a più operatori o attraversare Internet, la soluzione corretta è metterlo dietro un reverse proxy con HTTPS e autenticazione. In pratica, il demone Netdata resta sul server, mentre Nginx o Apache si occupano di cifratura e controllo accessi. Questo riduce la superficie di attacco e ti permette di integrare certificati validi e policy di accesso coerenti con il resto dell’infrastruttura.

Un approccio comune è usare Nginx come front-end. La configurazione base deve inoltrare il traffico verso la porta locale di Netdata e impedire l’accesso diretto dall’esterno. Un esempio minimale:

server { listen 443 ssl; server_name monitor.example.com; location / { proxy_pass http://127.0.0.1:19999; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto https; }
}

Se usi questo schema, il controllo finale è semplice: da remoto deve rispondere solo il proxy HTTPS, mentre la porta 19999 deve restare raggiungibile solo localmente. Una verifica utile è confrontare l’output di ss -ltnp e una richiesta HTTP diretta all’indirizzo locale.

curl -I http://127.0.0.1:19999/
curl -I https://monitor.example.com/

Se vuoi autenticazione aggiuntiva, applica almeno Basic Auth sul proxy. Non è la soluzione più elegante in assoluto, ma è già meglio di un pannello libero su Internet. In ambienti più strutturati, meglio integrare SSO o accesso tramite VPN.

Personalizzare retention e consumo di risorse

Netdata salva dati locali con granularità elevata, ma la retention va tarata sul server e sull’uso reale. Se tieni troppo poco storico, perdi contesto quando il problema compare a intervalli; se tieni troppo, aumenti spazio occupato e carico di I/O. La scelta dipende dal ruolo della macchina: un web server piccolo non ha le stesse esigenze di un nodo che ospita più servizi critici.

Il file da controllare è ancora /etc/netdata/netdata.conf. Le sezioni relative a memoria e storage possono essere adattate in base alla capacità della macchina. Prima di cambiare i parametri, misura lo stato attuale del sistema con strumenti standard:

free -h
lsblk
sudo du -sh /var/cache/netdata

Il criterio pratico è questo: non alzare la retention “perché sì”. Se ti serve più storico, verifica prima se il problema è davvero la durata locale o piuttosto l’assenza di un backend centralizzato per archiviare metriche di lungo periodo.

Integrazione con alert e altri sistemi di monitoraggio

La dashboard da sola non basta quando devi essere avvisato su un degrado reale. Netdata può generare alert locali e, in molti casi, essere affiancato a un sistema più ampio di notifiche o raccolta centralizzata. Il punto non è duplicare tutto, ma usare Netdata come sensore vicino alla sorgente del problema.

Se hai già Prometheus, Grafana o un sistema di alerting dedicato, valuta l’integrazione invece di sostituire tutto. Netdata resta utile per il dettaglio minuto per minuto, mentre la piattaforma centrale gestisce storicizzazione, dashboard aggregate e regole di notifica coerenti su più host.

Un uso molto concreto è il troubleshooting di un sito lento: guardi prima CPU, load, disco e rete, poi confronti il grafico con i log dell’applicazione e del web server. Se vedi saturazione I/O mentre le richieste aumentano, il problema non è quasi mai il solo PHP o il solo front-end. Se invece la CPU sale e la memoria scende, puoi sospettare worker fuori controllo o processi che consumano più del previsto.

Verifica post-installazione e controlli operativi

Dopo l’installazione, fai sempre una verifica operativa e non solo visiva. Il controllo minimo deve includere stato del servizio, accessibilità della porta, assenza di errori nei log e corretto funzionamento del reload dopo una modifica di configurazione.

  1. Controlla che il servizio sia attivo: systemctl is-active netdata. Il risultato atteso è active.

  2. Verifica la porta: ss -ltnp | grep 19999. Atteso: processo netdata in ascolto.

  3. Apri la dashboard e conferma che i grafici siano popolati con dati in tempo reale.

  4. Controlla i log recenti: journalctl -u netdata -n 50 --no-pager. Atteso: nessun errore ripetuto o crash loop.

  5. Se hai cambiato la configurazione, riavvia o ricarica il servizio e ripeti i test.

Se qualcosa non torna, la prima domanda non è “Netdata funziona?”. La domanda giusta è “dove si interrompe il flusso: servizio, binding, firewall, proxy o browser?”. Questa sequenza ti evita di perdere tempo su falsi problemi di applicazione quando il difetto è di rete o di policy di accesso.

Rimozione pulita e rollback

Se devi disinstallare Netdata, fallo in modo pulito e con consapevolezza dell’impatto. Prima interrompi il servizio, poi rimuovi il pacchetto e infine valuta se conservare o cancellare i dati locali. In ambienti di test puoi eliminare tutto; in produzione conviene spesso conservare la configurazione finché non hai verificato il motivo della dismissione.

sudo systemctl stop netdata
sudo apt purge -y netdata
sudo apt autoremove -y

Se hai usato un reverse proxy o una regola firewall dedicata, ricordati di rimuovere anche quelle. Il rollback minimo, nel caso di un problema introdotto da configurazione o hardening, è ripristinare il backup di /etc/netdata/netdata.conf e riavviare il servizio.

In pratica, Netdata su Ubuntu 20.04 si installa in pochi minuti, ma il valore vero arriva quando lo tratti come un componente operativo: accesso controllato, verifica dei log, integrazione con il tuo flusso di monitoraggio e retention coerente con il problema che vuoi risolvere. Così non hai solo un grafico bello da vedere, ma uno strumento che accelera davvero la diagnosi.