Prometheus Grafana Monitoring: Checklist Installazione e Alert Critici (2026)

RISPOSTA DIRETTA

Un monitoring stack con Prometheus e Grafana permette di raccogliere, archiviare e visualizzare metriche di sistema, configurando alert personalizzati per prevenire downtime e identificare anomalie prima che diventino problemi critici. L’automazione del deployment riduce a minuti i tempi di configurazione.

Snippet Rapido: Alert Disco Pieno

- alert: DiskSpaceCritical
  expr: (node_filesystem_avail_bytes / node_filesystem_size_bytes) * 100 < 5
  for: 1m
  labels:
    severity: critical
  annotations:
    summary: "Disco quasi pieno su istanza {{ $labels.instance }}"
    description: "Spazio su disco inferiore al 5% su {{ $labels.instance }} (filesystem {{ $labels.mountpoint }})"

Intro

Venerdì sera. 23:45. Squilla il telefono. Server down. Produzione ferma. Il problema? Disco pieno al 100%. Nessun alert era partito. Nessuno sapeva nulla fino a quando gli utenti non hanno iniziato a segnalare l’interruzione del servizio. La beffa? Il sistema di monitoring era installato sullo stesso server andato in crash. Questo scenario, purtroppo, non è un’eccezione ma una realtà che ho riscontrato più volte in ambienti enterprise. Un monitoring stack ben progettato e configurato non è un lusso, ma una necessità per qualsiasi infrastruttura moderna. In questa guida, vedremo come implementare un sistema di monitoring robusto con Prometheus e Grafana, concentrandoci sull’installazione, la configurazione di alert critici e l’automazione, per evitare che un semplice disco pieno diventi un incubo notturno.

Prerequisiti / Ambiente di test

Per seguire questa guida, avrai bisogno di:

• Un server Linux (Ubuntu 22.04 LTS o CentOS 8/9 Stream raccomandato) con almeno 4GB RAM e 2 core CPU per ospitare Prometheus, Grafana e AlertManager.
• Almeno un altro server Linux da monitorare (il ‘target’) con accesso SSH.
• Conoscenza base di Linux, systemd e concetti di networking.
• Accesso sudo su entrambi i server.

Installazione Prometheus e Node Exporter

Prometheus è il cuore del nostro sistema di monitoring, responsabile della raccolta delle metriche. Node Exporter è un agente leggero che gira sui server target e espone metriche hardware e del sistema operativo. Per garantire resilienza, Prometheus e Node Exporter non dovrebbero mai risiedere sullo stesso host monitorato.

Installazione Node Exporter (sul server da monitorare)

Sul server target, scarichiamo e installiamo Node Exporter. Utilizzeremo la versione 1.8.0, stabile e ampiamente testata.

# Scarica Node Exporter
wget https://github.com/prometheus/node_exporter/releases/download/v1.8.0/node_exporter-1.8.0.linux-amd64.tar.gz

# Estrai l'archivio
tar xvfz node_exporter-1.8.0.linux-amd64.tar.gz

# Sposta il binario in una posizione accessibile
sudo mv node_exporter-1.8.0.linux-amd64/node_exporter /usr/local/bin/

# Pulisci i file scaricati
rm -rf node_exporter-1.8.0.linux-amd64.tar.gz node_exporter-1.8.0.linux-amd64/

# Crea un utente per Node Exporter
sudo useradd -rs /bin/false node_exporter

# Crea un file di servizio systemd per Node Exporter
sudo tee /etc/systemd/system/node_exporter.service > /dev/null <<EOF
[Unit]
Description=Node Exporter
Wants=network-online.target
After=network-online.target

[Service]
User=node_exporter
Group=node_exporter
Type=simple
ExecStart=/usr/local/bin/node_exporter

[Install]
WantedBy=multi-user.target
EOF

# Ricarica systemd, abilita e avvia Node Exporter
sudo systemctl daemon-reload
sudo systemctl enable node_exporter
sudo systemctl start node_exporter

# Verifica lo stato (dovrebbe essere 'active (running)')
sudo systemctl status node_exporter

# Verifica che le metriche siano esposte (dovrebbe mostrare una pagina con metriche)
curl http://localhost:9100/metrics

Installazione Prometheus (sul server di monitoring)

Sul server dedicato al monitoring, installeremo Prometheus.

# Scarica Prometheus (versione più recente, ad esempio 2.44.0)
wget https://github.com/prometheus/prometheus/releases/download/v2.44.0/prometheus-2.44.0.linux-amd64.tar.gz

# Estrai l'archivio
tar xvfz prometheus-2.44.0.linux-amd64.tar.gz

# Crea directory e sposta i binari
sudo mkdir -p /etc/prometheus /var/lib/prometheus
sudo mv prometheus-2.44.0.linux-amd64/prometheus /usr/local/bin/
sudo mv prometheus-2.44.0.linux-amd64/promtool /usr/local/bin/
sudo cp -r prometheus-2.44.0.linux-amd64/{consoles,console_libraries} /etc/prometheus/

# Crea un utente per Prometheus
sudo useradd -rs /bin/false prometheus

# Assegna permessi
sudo chown -R prometheus:prometheus /etc/prometheus /var/lib/prometheus
sudo chown prometheus:prometheus /usr/local/bin/prometheus /usr/local/bin/promtool

# Crea il file di configurazione iniziale (prometheus.yml)
sudo tee /etc/prometheus/prometheus.yml > /dev/null <<EOF
global:
  scrape_interval: 15s

scrape_configs:
  - job_name: 'prometheus'
    static_configs:
      - targets: ['localhost:9090']
  - job_name: 'node_exporter'
    static_configs:
      - targets: ['IP_DEL_SERVER_DA_MONITORARE:9100'] # SOSTITUISCI CON L'IP DEL TUO SERVER TARGET
EOF

# Crea il file di servizio systemd per Prometheus
sudo tee /etc/systemd/system/prometheus.service > /dev/null <<EOF
[Unit]
Description=Prometheus
Wants=network-online.target
After=network-online.target

[Service]
User=prometheus
Group=prometheus
Type=simple
ExecStart=/usr/local/bin/prometheus \n    --config.file /etc/prometheus/prometheus.yml \n    --storage.tsdb.path /var/lib/prometheus \n    --web.console.templates=/etc/prometheus/consoles \n    --web.console.libraries=/etc/prometheus/console_libraries \n    --web.listen-address=0.0.0.0:9090

[Install]
WantedBy=multi-user.target
EOF

# Ricarica systemd, abilita e avvia Prometheus
sudo systemctl daemon-reload
sudo systemctl enable prometheus
sudo systemctl start prometheus

# Verifica lo stato
sudo systemctl status prometheus

Accedi all’interfaccia web di Prometheus all’indirizzo http://IP_DEL_SERVER_MONITORING:9090/targets per verificare che Node Exporter sia riconosciuto e le metriche vengano raccolte.

Grafana — datasource e dashboard Linux base

Grafana è lo strumento di visualizzazione che useremo per trasformare le metriche di Prometheus in dashboard leggibili e utili.

Installazione Grafana

# Aggiungi la chiave GPG di Grafana
sudo apt-get install -y apt-transport-https software-properties-common wget
wget -q -O - https://apt.grafana.com/gpg.key | sudo apt-key add -

# Aggiungi il repository Grafana
echo "deb https://apt.grafana.com stable main" | sudo tee /etc/apt/sources.list.d/grafana.list
sudo apt-get update

# Installa Grafana
sudo apt-get install grafana

# Avvia e abilita Grafana
sudo systemctl daemon-reload
sudo systemctl enable grafana-server
sudo systemctl start grafana-server

# Verifica lo stato
sudo systemctl status grafana-server

Accedi a Grafana all’indirizzo http://IP_DEL_SERVER_MONITORING:3000. Le credenziali di default sono admin/admin (cambiale subito!).

Configurazione Datasource e Dashboard Linux Base

1. Aggiungi Datasource: In Grafana, vai su Configuration -> Data Sources -> Add data source. Seleziona Prometheus. In URL, inserisci http://localhost:9090 (se Prometheus è sullo stesso server) o l’IP/hostname di Prometheus. Salva e testa.
2. Importa Dashboard: Le dashboard predefinite sono un ottimo punto di partenza. Cerca su Grafana Labs le dashboard per Node Exporter (ID consigliato: 1860 per System Overview o 11074 per Node Exporter Full). Importale tramite Dashboards -> Import e inserisci l’ID.

AlertManager — configurare notifiche email e Telegram

AlertManager gestisce gli alert generati da Prometheus, deduplicandoli, raggruppandoli e instradandoli ai ricevitori appropriati. Un alert efficace ti permette di agire proattivamente.

Installazione AlertManager

# Scarica AlertManager (versione più recente, ad esempio 0.27.0)
wget https://github.com/prometheus/alertmanager/releases/download/v0.27.0/alertmanager-0.27.0.linux-amd64.tar.gz

# Estrai l'archivio
tar xvfz alertmanager-0.27.0.linux-amd64.tar.gz

# Sposta il binario
sudo mv alertmanager-0.27.0.linux-amd64/alertmanager /usr/local/bin/
sudo mv alertmanager-0.27.0.linux-amd64/amtool /usr/local/bin/

# Crea directory e utente
sudo mkdir -p /etc/alertmanager /var/lib/alertmanager
sudo useradd -rs /bin/false alertmanager
sudo chown -R alertmanager:alertmanager /etc/alertmanager /var/lib/alertmanager
sudo chown alertmanager:alertmanager /usr/local/bin/alertmanager /usr/local/bin/amtool

# Configurazione AlertManager (alertmanager.yml) - Esempio con email e Telegram
sudo tee /etc/alertmanager/alertmanager.yml > /dev/null <<EOF
global:
  resolve_timeout: 5m

route:
  group_by: ['alertname', 'instance']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 1h
  receiver: 'default-receiver'

receivers:
  - name: 'default-receiver'
    email_configs:
      - to: 'tuo_email@example.com'
        from: 'alertmanager@example.com'
        smarthost: 'smtp.example.com:587'
        auth_username: 'smtp_user'
        auth_password: 'smtp_password'
    # Telegram (richiede un bot e una chat ID - vedi documentazione AlertManager)
    # telegram_configs:
    #   - bot_token: 'YOUR_BOT_TOKEN'
    #     chat_id: YOUR_CHAT_ID

EOF

# Crea il file di servizio systemd per AlertManager
sudo tee /etc/systemd/system/alertmanager.service > /dev/null <<EOF
[Unit]
Description=Prometheus Alertmanager
Wants=network-online.target
After=network-online.target

[Service]
User=alertmanager
Group=alertmanager
Type=simple
ExecStart=/usr/local/bin/alertmanager \n    --config.file /etc/alertmanager/alertmanager.yml \n    --storage.path /var/lib/alertmanager \n    --web.listen-address=0.0.0.0:9093

[Install]
WantedBy=multi-user.target
EOF

# Ricarica systemd, abilita e avvia AlertManager
sudo systemctl daemon-reload
sudo systemctl enable alertmanager
sudo systemctl start alertmanager

# Verifica lo stato
sudo systemctl status alertmanager

Configura Prometheus per inviare gli alert ad AlertManager modificando prometheus.yml (aggiungi sotto global:):

alerting:
  alertmanagers:
  - static_configs:
    - targets: ['localhost:9093'] # O IP dell'AlertManager

Riavvia Prometheus per applicare le modifiche.

Alert rules critiche — disco, CPU, memoria, servizi down

Le alert rules sono la spina dorsale del monitoring proattivo. Devono essere precise per evitare “alert fatigue”, ma sufficientemente sensibili da catturare i problemi in tempo. Secondo un report di IBM del 2024, il costo medio di un downtime non pianificato è di circa 9.000 dollari al minuto per le grandi aziende, e un buon sistema di alerting può ridurre significativamente questa cifra.

Crea un file rules.yml in /etc/prometheus/:

# /etc/prometheus/rules.yml

groups:
- name: host_alerts
  rules:
  - alert: HighCPULoad
    expr: 100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 85
    for: 5m
    labels:
      severity: warning
    annotations:
      summary: "Elevato carico CPU su {{ $labels.instance }}"
      description: "Il carico CPU supera l'85% su {{ $labels.instance }} per più di 5 minuti."

  - alert: HighMemoryUsage
    expr: 100 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes * 100) > 90
    for: 5m
    labels:
      severity: critical
    annotations:
      summary: "Utilizzo elevato della memoria su {{ $labels.instance }}"
      description: "La memoria utilizzata supera il 90% su {{ $labels.instance }} per più di 5 minuti."

  - alert: DiskSpaceWarning
    expr: (node_filesystem_avail_bytes{fstype!="rootfs"} / node_filesystem_size_bytes{fstype!="rootfs"}) * 100 < 15
    for: 5m
    labels:
      severity: warning
    annotations:
      summary: "Disco quasi pieno su {{ $labels.instance }}"
      description: "Spazio su disco inferiore al 15% su {{ $labels.instance }} (filesystem {{ $labels.mountpoint }})."

  - alert: DiskSpaceCritical
    expr: (node_filesystem_avail_bytes{fstype!="rootfs"} / node_filesystem_size_bytes{fstype!="rootfs"}) * 100 < 5
    for: 1m
    labels:
      severity: critical
    annotations:
      summary: "Disco critico su {{ $labels.instance }}"
      description: "Spazio su disco inferiore al 5% su {{ $labels.instance }} (filesystem {{ $labels.mountpoint }})."

  - alert: ServiceDown
    expr: up == 0
    for: 1m
    labels:
      severity: critical
    annotations:
      summary: "Servizio {{ $labels.job }} su {{ $labels.instance }} non raggiungibile"
      description: "Il target Prometheus {{ $labels.job }} su {{ $labels.instance }} ha fallito per più di 1 minuto."

Per includere queste regole in Prometheus, modifica prometheus.yml aggiungendo la seguente riga:

alerting:
  rule_files:
    - "/etc/prometheus/rules.yml"

Riavvia Prometheus per caricare le nuove regole. Puoi testare le regole tramite la UI di Prometheus (/alerts).

Query di esempio: Memoria disponibile

Per visualizzare la percentuale di memoria utilizzata in Grafana o Prometheus:

100 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes * 100)

Retention, storage e performance tuning

Prometheus archivia i dati localmente. Per ambienti di produzione con molte metriche, è fondamentale pianificare storage e retention.

• Retention: La configurazione di default è 15 giorni. Puoi modificarla aggiungendo --storage.tsdb.retention.time=30d (per 30 giorni) o --storage.tsdb.retention.size=50GB (per limitare lo spazio) ai parametri di avvio di Prometheus nel file prometheus.service.
• Performance: Per ambienti molto grandi, considera l’utilizzo di soluzioni di storage a lungo termine come Thanos o Mimir, che permettono scalabilità orizzontale e alta disponibilità. Un’analisi del 2023 di CNCF ha rivelato che il 65% delle aziende che usano Prometheus in produzione con oltre 1000 host, adottano una soluzione di storage a lungo termine.

Automazione con Ansible: stack completo in 10 minuti

L’installazione manuale è utile per capire i meccanismi, ma in produzione l’automazione è la chiave per la coerenza e la velocità. Ho utilizzato Ansible per automatizzare il deployment completo di Prometheus, Grafana e AlertManager. Questo mi permette di replicare l’intera infrastruttura di monitoring in pochi minuti, riducendo drasticamente gli errori umani e garantendo una configurazione standardizzata su tutti i server. Un playbook Ansible ben scritto può installare Node Exporter su decine di server target e configurare il server di monitoring con tutte le dipendenze, file di configurazione e servizi systemd necessari.

Errori comuni e troubleshooting

• Firewall: Assicurati che le porte 9090 (Prometheus), 9100 (Node Exporter) e 3000 (Grafana) siano aperte tra i server e per l’accesso dalla tua postazione.
• Permessi: Errori di permessi sui file di configurazione o sulle directory di storage sono frequenti. Verifica che gli utenti prometheus e alertmanager abbiano i permessi corretti (chown, chmod).
• Configurazione YAML: Gli errori di indentazione nei file YAML sono comuni. Usa promtool check config /etc/prometheus/prometheus.yml e amtool check-config /etc/alertmanager/alertmanager.yml per validare le configurazioni.
• Target Down: Se un target Node Exporter appare come DOWN in Prometheus, verifica che il servizio node_exporter sia attivo sul server target e che il firewall non blocchi la porta 9100.

FAQ — Domande Frequenti

Come posso monitorare applicazioni specifiche (es. Nginx, MySQL) con Prometheus?

Per monitorare applicazioni specifiche, puoi utilizzare gli “exporter” dedicati. Ad esempio, c’è un Nginx exporter, un MySQL exporter, ecc. Questi funzionano in modo simile a Node Exporter, esponendo metriche specifiche dell’applicazione che Prometheus può raccogliere. Li configuri come nuovi job nel file prometheus.yml.

Qual è la differenza tra for: 5m e group_wait: 30s in Prometheus/AlertManager?

for: 5m in una alert rule di Prometheus significa che la condizione dell’alert deve essere vera per almeno 5 minuti consecutivi prima che l’alert venga generato. group_wait: 30s in AlertManager è il tempo che AlertManager attende dopo aver ricevuto il primo alert di un gruppo prima di inviare le notifiche, permettendo di raggruppare alert simili e inviare una singola notifica.

Prometheus è adatto per il monitoring di log?

No, Prometheus è un sistema orientato alle metriche (time-series database) e non è ottimizzato per la raccolta e l’analisi dei log. Per il monitoring dei log, sono più adatti strumenti come ELK Stack (Elasticsearch, Logstash, Kibana), Grafana Loki o Splunk. Puoi integrare i log con le metriche tramite Grafana.

Come posso rendere il mio stack di monitoring altamente disponibile?

Per un’alta disponibilità, puoi configurare più istanze di Prometheus in modalità HA (High Availability) utilizzando un sistema di storage a lungo termine condiviso come Thanos o Mimir. Anche AlertManager può essere configurato in modalità cluster. Grafana, essendo stateless, può essere facilmente messo dietro un load balancer.

Conclusioni con takeaway operativi

Implementare un monitoring stack efficace con Prometheus e Grafana è un passo fondamentale per la resilienza di qualsiasi infrastruttura IT. Non si tratta solo di raccogliere dati, ma di trasformarli in insight azionabili tramite alert intelligenti. Ricorda di:

1. Separare il monitoring dal monitorato: Mai installare il sistema di monitoring sullo stesso server che deve monitorare.
2. Configurare alert critici: Focalizzati su disco, CPU, memoria e stato dei servizi come priorità.
3. Automatizzare il deployment: Usa strumenti come Ansible per garantire coerenza e scalabilità.
4. Pianificare lo storage: La retention dei dati è cruciale per l’analisi storica e il troubleshooting.

Un buon monitoring ti fa dormire sonni più tranquilli e ti permette di intervenire prima che un problema minore diventi una crisi di produzione. Il 92% dei professionisti IT considera il monitoring proattivo essenziale per la continuità operativa (SolarWinds, 2025).

Leggi anche

Leggi anche: Bash Scripting Sysadmin: 10 Script Pratici per Automazione Quotidiana (2026)

Leggi anche: LVM su Linux: Gestione Avanzata dei Volumi Logici — Resize, Snapshot, Migration (2026)

Leggi anche: Netdata Monitoring Linux: Installazione e Configurazione Real-Time (2026)

Aggiornato: giugno 2026