In cosa è diverso da Uptime Kuma?

Uptime Kuma risponde a «è su?». Prometheus e Grafana rispondono a «perché è lento, e da quando?»: metriche di CPU, memoria, disco, rete e applicazioni nel tempo. Molti usano entrambi: Kuma per gli avvisi sui guasti, Grafana per le tendenze e la pianificazione della capacità.

Quanto disco usa Prometheus?

Circa 1–2 byte per campione dopo la compressione. Dieci server che esportano mille serie ciascuno, letti ogni 15 secondi, fanno circa 60 milioni di campioni al giorno: nell'ordine dei 100 MB. Con la retention predefinita di 15 giorni sono un paio di gigabyte.

Posso monitorare server su piani NAT?

Sì, ma non con lo scraping: un server NAT non accetta connessioni in entrata verso il suo exporter. Esegui Prometheus in modalità agent sulla macchina NAT e invia le metriche al server di monitoraggio con remote_write. Il server di monitoraggio invece dovrebbe stare su un piano con IP dedicato.

Che piano dovrebbe avere il server di monitoraggio?

Micro-IP (2 GB di RAM, $10/mese) gestisce comodamente una o due dozzine di host. Se aggiungi metriche applicative ad alta cardinalità o conservi mesi di dati, passa a Small-IP. Un IP dedicato ti dà l'HTTPS per Grafana e un indirizzo stabile da mettere in whitelist sui target.

Il server di monitoraggio deve essere separato da ciò che monitora?

Sì. Se Grafana gira sul server che ha appena finito la memoria, perdi la visuale sul problema proprio quando ti serve. Un piccolo VPS separato continua a funzionare quando una macchina di produzione cede.

VPS per monitorare i server con Grafana + Prometheus

Raccogli in un unico posto le metriche di CPU, RAM, disco e servizi di tutti i tuoi server: Prometheus, node_exporter e Grafana su un VPS, dietro HTTPS.

«Il server è lento» è una segnalazione inutile, a meno che tu non possa aprire un grafico e vedere che la memoria è salita per tre giorni prima del crash. È questo che ti danno Prometheus e Grafana: CPU, RAM, disco e rete di ogni server, registrati ogni 15 secondi e disegnati in grafici che puoi scorrere all'indietro. Mettili su un piccolo VPS dedicato e continueranno a osservare anche quando una macchina di produzione cade.

I pezzi

node_exporter su ogni server che vuoi osservare: espone le metriche di sistema sulla porta 9100.
Prometheus sul VPS di monitoraggio: raccoglie (scrape) quelle metriche e le conserva.
Grafana: le dashboard, dietro HTTPS.
Facoltativamente Alertmanager o gli avvisi di Grafana per scriverti quando qualcosa supera una soglia.

Cosa ti serve

Micro-IP ($10/mese, 2 vCPU, 2 GB di RAM, 25 GB) osserva una o due dozzine di server. Più host, metriche applicative personalizzate o mesi di retention: Small-IP.
Un IPv4 dedicato per il server di monitoraggio: Grafana viene servito in HTTPS, e i tuoi target possono mettere in whitelist un unico indirizzo stabile per la porta 9100.

1. node_exporter su ogni target

apt install -y prometheus-node-exporter
# allow only the monitoring server to scrape it
ufw allow from 203.0.113.10 to any port 9100 proto tcp

Sostituisci 203.0.113.10 con l'indirizzo del tuo VPS di monitoraggio. Non lasciare mai la 9100 aperta al mondo: rivela molto sul tuo server.

2. Prometheus e Grafana sul VPS di monitoraggio

apt update && apt install -y docker.io docker-compose-v2 caddy
mkdir -p /opt/monitoring && cd /opt/monitoring

cat > prometheus.yml <<'EOF'
global:
  scrape_interval: 15s
scrape_configs:
  - job_name: nodes
    static_configs:
      - targets: ['198.51.100.21:9100', '198.51.100.22:9100']
EOF

cat > compose.yml <<'EOF'
services:
  prometheus:
    image: prom/prometheus
    volumes: [ "./prometheus.yml:/etc/prometheus/prometheus.yml:ro", "prom:/prometheus" ]
    command: [ "--config.file=/etc/prometheus/prometheus.yml", "--storage.tsdb.retention.time=15d", "--web.enable-remote-write-receiver" ]
    ports: [ "127.0.0.1:9090:9090" ]
    restart: unless-stopped
  grafana:
    image: grafana/grafana
    volumes: [ "grafana:/var/lib/grafana" ]
    ports: [ "127.0.0.1:3000:3000" ]
    restart: unless-stopped
volumes: { prom: {}, grafana: {} }
EOF

docker compose up -d

HTTPS davanti a Grafana:

echo 'grafana.example.com {
    reverse_proxy 127.0.0.1:3000
}' > /etc/caddy/Caddyfile && systemctl reload caddy

Accedi (admin / admin, poi cambiala), aggiungi Prometheus come sorgente dati su http://prometheus:9090 e importa la dashboard della community «Node Exporter Full» (ID 1860). In circa un minuto hai una dashboard di sistema completa.

Server su piani NAT

Un server NAT accetta connessioni in entrata solo sulla sua porta SSH personale, quindi Prometheus non può leggere il suo exporter. Inverti la direzione: esegui Prometheus in modalità agent sulla macchina NAT e invia i dati al server di monitoraggio, che accetta già scritture remote (il flag --web.enable-remote-write-receiver qui sopra).

# /etc/prometheus/agent.yml on the NAT server
scrape_configs:
  - job_name: self
    static_configs: [ { targets: ['127.0.0.1:9100'] } ]
remote_write:
  - url: https://prom-push.example.com/api/v1/write

Esponi quell'endpoint di push tramite Caddy con basic auth invece di aprire la porta 9090 così com'è.

Note oneste

Prometheus fa pull: ottimo per un parco macchine che controlli, scomodo per tutto ciò che sta dietro un NAT, da qui il trucco dell'agent. Il suo storage locale non è pensato per anni di storico; per una retention lunga aggiungerai più avanti uno storage remoto. E le dashboard sono solo metà del valore: imposta almeno tre avvisi fin dal primo giorno (disco oltre l'85%, pressione sulla memoria, target giù), altrimenti guarderai i grafici solo quando qualcosa si è già rotto.

Correlati

VPS per il monitoraggio dell'uptime (Uptime Kuma): avvisi sui guasti e pagine di stato
Come configurare il firewall UFW
Quanta RAM serve a un VPS?