Monitorare un server hosting con Prometheus e Grafana (Ubuntu 24.04)

26 settembre 2026 · lettura 5 min · Koapanel

Un server di hosting si guasta quasi sempre in modo prevedibile: il disco si riempie, un servizio si ferma, un certificato scade, un backup smette di funzionare. Per accorgertene prima dei clienti ti bastano quattro pezzi: Prometheus che raccoglie i dati, node_exporter per CPU, memoria e dischi, blackbox_exporter per controllare i siti dall'esterno e Grafana per vederli. Su Ubuntu 24.04 si installano tutti in un quarto d'ora. In questa guida trovi i comandi, una configurazione pronta e le regole di allarme che conviene attivare per prime.

Come è fatto lo stack

Prometheus interroga a intervalli regolari degli indirizzi HTTP (gli exporter) che rispondono con numeri in formato testo, li conserva e valuta le regole di allarme.
node_exporter espone le metriche del sistema: CPU, memoria, dischi, rete, carico.
blackbox_exporter fa richieste ai tuoi siti come un visitatore: controlla che rispondano, il codice HTTP e la scadenza del certificato.
Alertmanager riceve gli allarmi da Prometheus e li manda per email, Telegram, Slack o altro.
Grafana disegna i grafici.

Il consiglio più importante viene prima dei comandi: metti Prometheus su un server diverso da quello che controlla. Se il server dei siti si blocca, un Prometheus installato lì si blocca con lui e non ti avvisa. Un VPS da pochi euro al mese basta per controllare decine di server.

1. Installare Prometheus e node_exporter

Ubuntu 24.04 ha i pacchetti ufficiali della distribuzione:

sudo apt update
sudo apt install prometheus prometheus-node-exporter prometheus-alertmanager prometheus-blackbox-exporter

Prometheus risponde sulla porta 9090, node_exporter sulla 9100, Alertmanager sulla 9093 e blackbox_exporter sulla 9115. La configurazione principale è /etc/prometheus/prometheus.yml.

Su ogni server di siti installa solo node_exporter e apri la porta 9100 al solo indirizzo del server di monitoraggio:

sudo apt install prometheus-node-exporter
sudo ufw allow from 203.0.113.50 to any port 9100 proto tcp

Non lasciare mai la 9100 aperta a tutti: le metriche rivelano nomi dei dischi, versioni e carico del server.

2. Configurare Prometheus

Sostituisci /etc/prometheus/prometheus.yml sul server di monitoraggio con una configurazione come questa (gli indirizzi sono di esempio):

global:
  scrape_interval: 30s
  evaluation_interval: 30s

rule_files:
  - /etc/prometheus/rules/*.yml

alerting:
  alertmanagers:
    - static_configs:
        - targets: ["localhost:9093"]

scrape_configs:
  - job_name: node
    static_configs:
      - targets: ["web1.example.com:9100", "web2.example.com:9100"]

  - job_name: siti
    metrics_path: /probe
    params:
      module: [http_2xx]
    static_configs:
      - targets:
          - https://www.cliente-uno.it
          - https://www.cliente-due.it
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - source_labels: [__param_target]
        target_label: instance
      - target_label: __address__
        replacement: localhost:9115

Il blocco relabel_configs è la parte che confonde tutti: dice a Prometheus di chiamare blackbox_exporter (localhost:9115) passandogli come parametro l'indirizzo del sito da controllare.

Controlla la sintassi e riavvia:

sudo mkdir -p /etc/prometheus/rules
promtool check config /etc/prometheus/prometheus.yml
sudo systemctl restart prometheus

Apri http://IP-del-server:9090/targets (meglio attraverso un tunnel SSH: ssh -L 9090:localhost:9090 server) e verifica che tutti i target siano UP.

3. Le regole di allarme che servono davvero

Molti allarmi sono peggio di nessun allarme: dopo una settimana di notifiche inutili smetti di leggerle. Parti da questi cinque, in /etc/prometheus/rules/hosting.yml:

groups:
  - name: hosting
    rules:
      - alert: ServerNonRaggiungibile
        expr: up{job="node"} == 0
        for: 3m
        annotations:
          summary: "{{ $labels.instance }} non risponde da 3 minuti"

      - alert: DiscoQuasiPieno
        expr: node_filesystem_avail_bytes{fstype!~"tmpfs|overlay"} / node_filesystem_size_bytes < 0.10
        for: 10m
        annotations:
          summary: "{{ $labels.instance }}: meno del 10% libero su {{ $labels.mountpoint }}"

      - alert: SitoGiu
        expr: probe_success{job="siti"} == 0
        for: 2m
        annotations:
          summary: "{{ $labels.instance }} non risponde"

      - alert: CertificatoInScadenza
        expr: probe_ssl_earliest_cert_expiry - time() < 14 * 86400
        for: 1h
        annotations:
          summary: "Il certificato di {{ $labels.instance }} scade tra meno di 14 giorni"

      - alert: MemoriaEsaurita
        expr: node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes < 0.05
        for: 10m
        annotations:
          summary: "{{ $labels.instance }}: memoria disponibile sotto il 5%"

Il campo for evita i falsi allarmi: la condizione deve restare vera per quel tempo prima di partire. Controlla con promtool check rules /etc/prometheus/rules/hosting.yml e ricarica Prometheus.

Perché 14 giorni per i certificati? Certbot rinnova i certificati Let's Encrypt circa 30 giorni prima della scadenza: se a 14 giorni il certificato è ancora quello vecchio, il rinnovo automatico non sta funzionando e hai ancora due settimane per sistemarlo.

4. Mandare gli allarmi per email

Alertmanager legge /etc/prometheus/alertmanager.yml. Una configurazione minima per l'email:

global:
  smtp_smarthost: smtp.example.com:587
  smtp_from: allarmi@example.com
  smtp_auth_username: allarmi@example.com
  smtp_auth_password: "la-password"

route:
  receiver: email
  group_wait: 1m
  repeat_interval: 12h

receivers:
  - name: email
    email_configs:
      - to: tu@example.com

repeat_interval: 12h ripete l'avviso finché il problema resta aperto, ma non più di due volte al giorno. Riavvia con sudo systemctl restart prometheus-alertmanager.

5. Grafana per i grafici

Grafana non è nei pacchetti di Ubuntu: si installa dal repository ufficiale.

sudo apt install -y apt-transport-https wget gnupg
sudo mkdir -p /etc/apt/keyrings
wget -q -O - https://apt.grafana.com/gpg.key | gpg --dearmor | sudo tee /etc/apt/keyrings/grafana.gpg > /dev/null
echo "deb [signed-by=/etc/apt/keyrings/grafana.gpg] https://apt.grafana.com stable main" | sudo tee /etc/apt/sources.list.d/grafana.list
sudo apt update && sudo apt install grafana
sudo systemctl enable --now grafana-server

Grafana risponde sulla porta 3000 (utente e password iniziali admin / admin, ti chiede subito di cambiarla). In Connections › Data sources aggiungi Prometheus con indirizzo http://localhost:9090, poi in Dashboards › Import inserisci l'ID 1860 («Node Exporter Full»): hai subito i grafici di CPU, memoria, dischi e rete di ogni server.

6. Le metriche che node_exporter non vede

node_exporter conosce il sistema, non i siti. Non sa quali siti ospiti, chi è il loro proprietario, quanto spazio occupa ciascuno, quando è stato fatto l'ultimo backup o quale versione di PHP usano. Per queste informazioni devi scrivere script che producono metriche (con il textfile collector di node_exporter) oppure usare un pannello che le espone da sé.

Il monitoraggio con Koapanel

Koapanel espone le metriche di hosting nel formato di Prometheus all'indirizzo /api/v1/metrics di ogni pannello, dalla versione 0.27. Non serve installare niente sul server dei siti: basta una chiave API di un amministratore, creata in Chiavi API e salvata in un file sul server di monitoraggio.

  - job_name: koapanel
    scheme: https
    metrics_path: /api/v1/metrics
    scrape_interval: 60s
    authorization:
      credentials_file: /etc/prometheus/koapanel.key
    static_configs:
      - targets: ["pannello.example.com:8443"]

Oltre a CPU, memoria, dischi e servizi, trovi:

Metrica	Cosa dice
`koapanel_sites`	siti online e sospesi
`koapanel_site_info`	ogni sito con proprietario, versione di PHP e se è WordPress
`koapanel_site_disk_bytes`	spazio occupato da ogni sito
`koapanel_site_ssl_expiry_timestamp_seconds`	scadenza del certificato di ogni sito
`koapanel_site_last_backup_timestamp_seconds`	ultimo backup riuscito di ogni sito
`koapanel_service_up`	nginx, MariaDB, PHP-FPM, fail2ban e SSH attivi o fermi
`koapanel_update_available`	c'è una versione nuova del pannello

La regola più utile che node_exporter non permette è quella sui backup:

      - alert: BackupMancante
        expr: time() - koapanel_site_last_backup_timestamp_seconds > 2 * 86400
        for: 1h
        annotations:
          summary: "{{ $labels.domain }}: nessun backup riuscito da due giorni"

Se non vuoi installare Prometheus, il pannello manda comunque da solo le email per certificato in scadenza con rinnovo non riuscito, backup non riuscito e disco oltre il 90%: le trovi in Email di sistema. La configurazione completa di Prometheus è nel manuale, sezione API e webhook.

Domande frequenti

Prometheus consuma molte risorse?

Per qualche decina di server e siti no: un VPS con 1-2 GB di RAM basta. Lo spazio dipende da quanti giorni di dati conservi (15 di serie): con --storage.tsdb.retention.time in /etc/default/prometheus puoi cambiarlo.

Meglio Prometheus o un servizio di uptime esterno?

Tutti e due. Il servizio esterno ti dice che un sito non risponde anche se è caduto il tuo server di monitoraggio; Prometheus ti dice perché, e ti avvisa prima che succeda (disco, memoria, certificati).

Posso usare Zabbix o Netdata al posto di Prometheus?

Sì. Leggono entrambi il formato di Prometheus, quindi anche l'indirizzo /api/v1/metrics di Koapanel.

Devo esporre la porta di Prometheus su Internet?

No. Tieni 9090, 9093 e 3000 chiuse e raggiungile con un tunnel SSH o dietro un reverse proxy con autenticazione.

Prova Koapanel

Puoi guardare il pannello nella demo pubblica oppure installarlo su un Ubuntu 24.04 appena creato, gratis fino a 3 siti:

curl -fsSL https://get.koapanel.app | sudo bash

Tutte le integrazioni, da WHMCS all'API, sono nella pagina Integrazioni.