Come installare Grafana su CentOS 9 Stream -- TrgtKLS • Tech, Sicurezza e Strumenti & guide per Webmaster

1 1 visite 14/04/2026 Pubblicato il: 14/04/2026 00:33 Tempo di lettura: 10 min

Repository ufficiale e prerequisiti su CentOS 9 Stream

Su CentOS 9 Stream la strada più pulita è usare il repository ufficiale di Grafana. Evita pacchetti presi a mano o repository di terze parti senza necessità: per un servizio esposto in rete è meglio avere aggiornamenti tracciabili e un percorso di upgrade chiaro. Prima di toccare il sistema, verifica che la macchina sia aggiornata, che l’orologio sia corretto e che il DNS funzioni, perché sia l’installazione del repository sia il successivo accesso via browser dipendono da una base sana.

Assumo un host CentOS 9 Stream con accesso root o sudo, rete uscente verso Internet e firewall attivo. Se la macchina è dietro proxy, CDN o policy di egress restrittive, il punto da controllare subito è la raggiungibilità di packages.grafana.com e poi la porta 3000 in ingresso, se vuoi pubblicare l’interfaccia web direttamente.

Prima verifica rapida:

cat /etc/centos-release
sudo dnf -y update
sudo timedatectl status
curl -I https://packages.grafana.com/oss/rpm/

Se il comando curl -I restituisce una risposta HTTP valida, il problema non è l’uscita rete. Se fallisce per DNS o TLS, non ha senso andare avanti: prima sistemi la connettività, poi riparti con l’installazione.

Aggiunta del repository Grafana e installazione del pacchetto

Grafana pubblica il repository RPM ufficiale con chiave di firma dedicata. Il flusso corretto è importare la chiave, creare il file repo e installare il pacchetto. Così mantieni il controllo sugli aggiornamenti e riduci il rischio di mismatch tra versione installata e dipendenze.

Passi operativi:

Importa la chiave GPG ufficiale.
Crea il repository RPM di Grafana.
Pulisci la cache DNF e installa il pacchetto.

sudo rpm --import https://packages.grafana.com/gpg.key
sudo tee /etc/yum.repos.d/grafana.repo > /dev/null <<'EOF'
[grafana]
name=Grafana OSS
baseurl=https://packages.grafana.com/oss/rpm
repo_gpgcheck=1
gpgcheck=1
enabled=1
gpgkey=https://packages.grafana.com/gpg.key
EOF
sudo dnf clean all
sudo dnf makecache
sudo dnf -y install grafana

Se vuoi una versione specifica, blocca il pacchetto al numero desiderato invece di prendere l’ultima disponibile. È una scelta utile in ambienti con change window o quando devi allinearti a plugin compatibili. Esempio:

sudo dnf list --showduplicates grafana
sudo dnf -y install grafana-10.4.3-1

Se il repository non viene risolto, la verifica minima è il file /etc/yum.repos.d/grafana.repo e la risposta di dnf repolist. Se la chiave GPG non combacia, non forzare la disabilitazione dei controlli: correggi il repository o la chiave, altrimenti ti stai lasciando installare pacchetti non verificati.

Avvio del servizio e controllo dello stato systemd

Su CentOS 9 Stream Grafana gira come servizio systemd. Dopo l’installazione, il binario non parte da solo: devi abilitare e avviare il servizio. Qui la verifica non è solo “il processo esiste”, ma anche se ascolta sulla porta prevista e se i log iniziali sono puliti.

Comandi base:

sudo systemctl enable --now grafana-server
sudo systemctl status grafana-server --no-pager
sudo journalctl -u grafana-server -n 50 --no-pager

Lo stato atteso è active (running). Nei log iniziali dovresti vedere l’avvio del server HTTP, la creazione o apertura del database locale e il binding sulla porta 3000. Se il servizio si ferma subito, le cause tipiche sono: permessi errati sulla directory dati, porta già occupata, configurazione invalida o problemi di SELinux. In questo caso la diagnostica parte dai log, non dal riavvio ripetuto.

Controlla anche la porta in ascolto:

sudo ss -ltnp | grep ':3000'

Se non compare nulla, il servizio non sta ascoltando o sta ascoltando su un indirizzo diverso. In quel caso la configurazione va letta prima di cambiare altro.

Accesso iniziale all’interfaccia web e credenziali di default

Dopo l’avvio, l’interfaccia si raggiunge su http://IP_DEL_SERVER:3000. Il primo login usa in genere le credenziali predefinite admin / admin, ma il punto importante non è ricordarsele: è cambiarle subito al primo accesso e registrare il nuovo stato in modo sicuro.

La procedura corretta è semplice: entra, cambia password, poi verifica che l’account amministrativo sia ancora funzionante. Se la macchina è esposta su rete pubblica, questa è una finestra di rischio troppo grande per lasciarla aperta anche solo per qualche ora.

Per una verifica locale rapida, puoi testare la risposta HTTP prima del browser:

curl -I http://127.0.0.1:3000/login

Se il server risponde localmente ma non dall’esterno, il problema è quasi sempre nel firewall, nel routing o nel binding dell’applicazione. Se non risponde nemmeno in locale, torna ai log del servizio.

Firewall: aprire la porta 3000 senza esporre troppo

Per test o uso diretto devi consentire la porta 3000/tcp nel firewall. Farlo in modo minimo significa aprire solo ciò che serve e solo dove serve. Se Grafana è dietro reverse proxy, in molti casi conviene non esporre la 3000 all’esterno e lasciare che sia il proxy a parlare con l’origin in locale.

Con firewalld:

sudo firewall-cmd --permanent --add-port=3000/tcp
sudo firewall-cmd --reload
sudo firewall-cmd --list-ports

Verifica esterna minima:

curl -I http://IP_DEL_SERVER:3000

Se il server è in un segmento esposto, valuta di limitare la porta solo agli IP amministrativi oppure di usare un reverse proxy con TLS e autenticazione aggiuntiva. Aprire 3000 su Internet senza filtro non è una buona abitudine operativa.

Configurazione base: root_url, dominio e dietro reverse proxy

La configurazione di Grafana vive in /etc/grafana/grafana.ini. Il file è ricco di opzioni, ma per un’installazione standard le voci più importanti sono quelle relative a server. Se prevedi di esporre Grafana sotto un dominio, o dietro Nginx/Apache, devi impostare correttamente root_url e, se necessario, serve_from_sub_path.

Esempio tipico con sottopercorso:

[server]
protocol = http
http_addr = 127.0.0.1
http_port = 3000
domain = grafana.example.com
root_url = https://grafana.example.com/grafana/
serve_from_sub_path = true

Se vuoi far parlare Grafana solo in locale e delegare tutto al reverse proxy, imposta http_addr = 127.0.0.1. Così la porta 3000 non resta esposta sulla rete e il proxy diventa l’unico punto di ingresso. È una scelta più pulita in quasi tutti gli ambienti di produzione.

Dopo ogni modifica al file, riavvia il servizio e controlla i log:

sudo systemctl restart grafana-server
sudo journalctl -u grafana-server -n 20 --no-pager

Se stai dietro reverse proxy, i problemi più comuni sono redirect infiniti, asset mancanti o URL errati. Il sintomo classico è la pagina che carica male o rimanda sempre alla login. In quel caso il primo file da controllare è grafana.ini, non il browser.

Hardening minimo: password, utenti e segreti

La sicurezza base non si esaurisce nel cambiare la password admin. Grafana può gestire utenti locali, autenticazione esterna, token API e datasource con credenziali sensibili. La regola pratica è non lasciare segreti in chiaro nei file di configurazione o negli screenshot operativi. Se devi documentare un setup, redigi valori sensibili e mostra solo il campo o il nome della variabile.

Minimo sindacale dopo il primo accesso:

Cambia la password dell’utente admin.
Valuta di creare un utente nominativo con ruolo amministrativo e di disabilitare l’uso quotidiano di admin.
Se usi datasource esterni, conserva credenziali e token in secret manager o variabili protette, non nel repository Git.
Controlla che la dashboard non esponga dati sensibili oltre il necessario.

Se il server è esposto in rete, aggiungi almeno una barriera: TLS, accesso limitato per IP, autenticazione tramite reverse proxy o VPN. Grafana è un front-end amministrativo, quindi non va trattato come un sito statico qualsiasi.

Installazione plugin e gestione compatibilità

Uno dei vantaggi di Grafana è l’ecosistema plugin, ma è anche un’area dove si fanno errori banali. Non installare plugin a caso in produzione: controlla compatibilità con la versione del server, firma del plugin e necessità reale. Un plugin non compatibile può rompere il caricamento della UI o introdurre comportamenti inattesi nelle dashboard.

Installazione di esempio di un plugin ufficiale o compatibile:

sudo grafana-cli plugins install grafana-clock-panel
sudo systemctl restart grafana-server

La verifica dopo l’installazione è duplice: il plugin deve comparire nella UI e i log non devono mostrare errori di firma o caricamento. Se il plugin non è firmato o non è supportato dalla tua build, è meglio fermarsi e usare una versione compatibile piuttosto che forzare il bypass dei controlli.

Uso con Nginx come reverse proxy e TLS

In produzione, il pattern più pulito è mettere Grafana dietro Nginx con TLS terminato sul proxy. Così hai un punto unico per certificati, redirect, header di sicurezza e eventuale rate limiting. Grafana resta sull’origin interno, mentre il proxy gestisce il traffico esterno.

Snippet minimale Nginx:

server {
    listen 443 ssl http2;
    server_name grafana.example.com;

    ssl_certificate     /etc/letsencrypt/live/grafana.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/grafana.example.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Se usi un sottopercorso, allinea anche root_url e serve_from_sub_path. Senza coerenza tra proxy e configurazione applicativa, finisci con redirect rotti o risorse statiche non trovate.

Verifiche finali: salute del servizio, accesso e log

A installazione completata, non basta vedere la pagina di login. Serve una verifica minima su tre livelli: servizio, rete e applicazione. Questo riduce il rischio di considerare “risolto” un problema che in realtà si ripresenterà al primo reboot o al primo cambio di configurazione.

Controlli consigliati:

Servizio: systemctl is-active grafana-server deve restituire active.
Porta: ss -ltnp | grep ':3000' deve mostrare il listener corretto.
HTTP: curl -I http://127.0.0.1:3000/login deve restituire un codice 200, 302 o comunque una risposta coerente con il redirect di login.
Log: journalctl -u grafana-server -n 50 non deve contenere errori ripetuti.

Se qualcosa non torna, la sequenza giusta è: log, configurazione, rete. Riavviare senza capire il motivo serve solo a mascherare il difetto fino al prossimo riavvio o al prossimo aggiornamento.

Aggiornamenti e manutenzione ordinaria

Grafana va tenuto aggiornato con una cadenza ragionevole, soprattutto se lo usi in un contesto dove i dashboard sono un punto operativo. Prima di aggiornare, leggi le note di rilascio per eventuali breaking change su plugin, datasource o autenticazione. Un upgrade fatto alla cieca può rompere visualizzazioni o integrazioni con sistemi esterni.

Flusso prudente:

Snapshot o backup della configurazione in /etc/grafana/ e, se necessario, del database locale.
Aggiornamento del pacchetto con dnf update grafana.
Riavvio controllato del servizio.
Verifica di login, dashboard principali e plugin critici.

sudo cp -a /etc/grafana /root/grafana-backup-$(date +%F)
sudo dnf -y update grafana
sudo systemctl restart grafana-server

Se l’istanza è critica, pianifica un rollback semplice: conserva la versione precedente del pacchetto e il backup della configurazione. In caso di regressione, poter tornare indietro in pochi minuti vale più di qualsiasi tentativo di correzione “al volo”.

Conferma operativa e punti da non saltare

Una installazione corretta di Grafana su CentOS 9 Stream non si misura solo con il pacchetto presente, ma con la catena completa: repository affidabile, servizio attivo, porta raggiungibile, configurazione coerente con il dominio, accesso protetto e log senza errori. Se uno di questi punti manca, la base non è davvero pronta per la produzione.

In pratica, il percorso più solido è questo: installa dal repository ufficiale, limita l’ascolto a localhost se hai un reverse proxy, pubblica solo via TLS, aggiorna subito le credenziali e conserva una procedura di rollback. È una configurazione semplice, ma già abbastanza robusta per la maggior parte degli scenari Linux in ambito hosting e monitoraggio.