Il monitoraggio di Proxmox con Prometheus e Grafana è la soluzione preferita in molte realtà IT per rendere misurabili, storicizzabili e allarmabili host, macchine virtuali (VM) e lo stato dei cluster. Questo dossier è rivolto ad amministratori, ingegneri di sistema e operatori e spiega in modo pratico quali exporter sono necessari, come scalare Prometheus, come operationalizzare gli alert e quali strategie di verifica e fallback si sono dimostrate efficaci in ambienti di produzione reali.
Monitoraggio di Proxmox con Prometheus e Grafana: Prerequisiti rapidi e controllo dei termini
Prima di iniziare: Prometheus è una database di metriche basata su serie temporali (TSDB) con meccanismo pull; Grafana è il front-end di visualizzazione; Alertmanager gestisce notifiche, raggruppamento e silenziamenti. Gli exporter sono piccoli servizi che espongono metriche nel formato Prometheus – node_exporter fornisce metriche dell’OS, pve_exporter interroga la Proxmox-API. Orologi sincronizzati (NTP/Chrony), regole firewall e token sicuri sono obbligatori.
Decisioni di architettura e di scalabilità
Iniziate con una chiara separazione tra Hot-Store (retention breve, query veloci) e Long-Term-Store (dati storici). Per ambienti piccoli è sufficiente un singolo Prometheus; con requisiti di cardinalità crescenti e molte VM è consigliabile un pattern Edge-/Central: istanze Prometheus locali eseguono lo scraping dei nodi, remote_write invia i dati a una TSDB centrale e scalabile come VictoriaMetrics, Thanos o Cortex.
Perché Edge-Prometheus?
Un Edge-Prometheus riduce il carico di rete, limita le chiamate API verso Proxmox e mantiene i guasti localizzati. Federation o remote_write aggregano solo ciò che è necessario centralmente. Questo minimizza il rischio che una singola query globale sovraccarichi l’intera infrastruttura.
Gli exporter nel dettaglio: gestire correttamente node_exporter e pve_exporter
node_exporter: note operative
node_exporter dovrebbe girare come servizio systemd, con collector limitati (disattivare i moduli non necessari) e il textfile-collector per controlli di stato locali (es. risultati dei backup). Permessi dei file e contesti utente (utente dedicato, non privilegiato) sono importanti, perché node_exporter legge metriche dal sistema.
# Systemd-Unit-Auszug für node_exporter
[Service]
User=nodeusr
Group=nodeusr
ExecStart=/usr/local/bin/node_exporter
--no-collector.wifi
--no-collector.mdadm
--collector.textfile.directory=/var/lib/node_exporter/textfile_collector
# Verzeichnisrechte
chown -R nodeusr:nodeusr /var/lib/node_exporter
chmod 750 /var/lib/node_exporterpve_exporter: Auth, Cache und API-Rate-Limits
pve_exporter utilizza la Proxmox-REST-API ed è quindi dipendente dalla stabilità delle API e dalle autorizzazioni dei token. Impostate una durata della cache (es. 30–60s) nell’exporter per evitare carico API inutile; gli endpoint proxmox-api possono rispondere lentamente o essere temporaneamente bloccati in caso di troppe richieste.
# systemd-Umgebung mit sicherer Token-Datei
[Service]
User=pveexport
EnvironmentFile=/etc/pve_exporter/env
ExecStart=/usr/local/bin/pve_exporter --listen-address=127.0.0.1:9273 --cache-duration=60s
# /etc/pve_exporter/env (richtig setzen mit 600)
PROXMOX_API_TOKEN_ID=exporter@pve!id
PROXMOX_API_TOKEN_SECRET=longsecret
Importante: create token con privilegi minimi e conservate i secret in un vault, oppure almeno in file con permessi restrittivi (chmod 600). Testate l’accesso alle API separatamente prima di collegare Prometheus.
Controllare la cardinalità: strategia di label e relabeling
La cardinalità indica il numero di serie temporali uniche; cresce rapidamente se si adottano metadati dinamici come label (p. es. note libere delle VM). Ciò aumenta il fabbisogno di storage, la CPU e la latenza delle query. Misure:
- Definire una lista di label consentite per job.
- Rimuovere le label volatili già tramite relabel_configs.
- Creare label di tipo service o role tramite normalizzazione regex invece dei nomi VM completi.
relabel_configs:
- source_labels: [vm_description]
regex: '.*'
action: drop
- source_labels: [vm_name]
regex: '^(web|db|cache)-.*'
target_label: service
replacement: '${1}'Gestione di Prometheus: Retention, Compaction e risorse
Prometheus memorizza i dati in block. Le configurazioni raccomandate sono una hot-retention di 15–30 giorni e remote_write per lo storage a lungo termine. Monitorare il TSDB-I/O: le latenze del disco provocano un aumento della durata degli scrape e errori.
# Prometheus Startflags (Beispiel)
prometheus --storage.tsdb.path=/var/lib/prometheus
--storage.tsdb.retention.time=30d
--storage.tsdb.no-lockfile
In caso di carico elevato scalare orizzontalmente con Thanos o VictoriaMetrics; verificare inoltre la dimensione dei block e le impostazioni della WAL se si osservano picchi di scrittura frequenti.
Esempi PromQL utili nella pratica
Query pratiche per diagnostica e dashboard:
# Aktive VMs pro Node
count by (instance) (pve_vm_info{state="running"})
# Storage-Usage pro Storage-Pool
sum by (storage) (pve_storage_used_bytes) / sum by (storage) (pve_storage_total_bytes)
# Disk-IO-Latenz pro VM (wenn Exporter Metrik liefert)
avg by (vm) (rate(pve_vm_disk_io_time_seconds_total[5m]))Alerting: pattern consolidati e integrazione con Alertmanager
Utilizzare Alertmanager come controllo centrale per routing, raggruppamento, inibizione (soppressione) e silences. Gli alert devono essere orientati all’azione: un breve sommario, una causa precisa (se possibile) e un runbook linkato.
Raggruppamento, Inhibition ed esempio
Il raggruppamento riduce il flusso di notifiche, l’inibizione evita doppi allarmi (p. es. quando un’interruzione dello storage genera una serie di alert sulle VM).
# Beispiel: Inhibit-Regel in alertmanager.yml
inhibit_rules:
- source_match:
severity: 'critical'
target_match:
severity: 'warning'
equal: ['instance']Regola di alert: riempimento storage con for-delay
- alert: ProxmoxStorageHighUsage
expr: (pve_storage_used_bytes / pve_storage_total_bytes) > 0.9
for: 30m
labels:
severity: warning
team: storage
annotations:
summary: "Storage fast voll auf {{ $labels.storage }}"
runbook: "https://intranet/runbooks/proxmox-storage-full"
Con un valore for più lungo si ritardano gli allarmi per picchi transitori (p. es. snapshot temporanei).
Passi pratici di test e validazione
Prima del rollout in produzione, verificare in modo standardizzato:
- Endpoint dell’exporter:
curl -s http://pve-node1:9273/metrics | head - Prometheus /targets: tutti i target rilevanti devono risultare UP e con bassa durata di scrape.
- Pannelli Grafana: validare le analisi principali (CPU, memoria, storage).
- Test degli alert: attivare una regola di test con soglia bassa, verificare la route di Alertmanager.
- Esercitazione sul playbook: i destinatari eseguono i passaggi definiti e riportano il punto di ripristino.
Integrazione in Incident-Management-Tools
Alertmanager supporta molte integrazioni (Webhook, PagerDuty, Opsgenie, Microsoft Teams, Slack). Per Slack/Webhook definite un Receiver con l’URL corrispondente e strutturate i label per il routing (team, severity).
receivers:
- name: 'slack-main'
slack_configs:
- api_url: 'https://hooks.slack.com/services/XXXXX/XXXXX/XXXXX'
channel: '#infra-alerts'
title: '{{ template "slack.title" . }}'
Evitare di memorizzare URL sensibili in repository in chiaro; utilizzate una gestione dei segreti.
Rischi per la sicurezza e l’operatività
Endpoint degli exporter insufficientemente protetti costituiscono una superficie d’attacco. Proteggete i seguenti livelli:
- Rete: consentire la connessione via firewall solo tra Prometheus ed exporter.
- Trasporto: TLS o mTLS tramite reverse-proxy, se i segmenti di rete non sono sicuri.
- Accessi API: token con privilegi minimi, rotazione e uso di Vault.
Note su upgrade e migrazione
Le versioni di exporter e API possono diventare incompatibili. Procedura:
- Pinning delle versioni: testate le nuove versioni degli exporter in staging.
- Smoke test: dopo l’upgrade verificate gli endpoint degli exporter, i target di Prometheus e i dashboard di Grafana.
- Rollback: mantenete la gestione delle versioni per le configurazioni (Git) e script di revert per le unit systemd.
Strategia di fallback in caso di flood di alert o guasto di sistema
Se gli alert vengono generati incontrollatamente o Prometheus stesso causa problemi, esistono azioni rapide:
- Applicare un silence tramite l’API di Alertmanager per i gruppi di alert interessati.
- Identificare nelle query di Prometheus le espressioni più onerose e disattivarle temporaneamente (revert della configurazione).
- Riattivare gli Edge-Prometheus o separare il carico dall’istanza centrale.
# Silence per API anlegen (Beispiel)
curl -XPOST -H "Content-Type: application/json" http://alertmanager.example.local/api/v2/silences -d '{
"matchers": [{"name":"team","value":"storage"}],
"startsAt":"2026-07-28T10:00:00Z",
"endsAt":"2026-07-28T10:30:00Z",
"createdBy":"ops",
"comment":"Emergency mute while investigating"
}'Grafana: dashboard, struttura e riproducibilità
La costruzione dei dashboard è più che grafici estetici: usate variabili per ambiente/node, salvate i dashboard come JSON in Git (Export/Import) e collegate i runbook direttamente nelle annotazioni dei pannelli. Configurate i permessi delle cartelle in modo che la modifica sia limitata a un piccolo team.
Checklist pratica per il rollout
- Verificare token, firewall e sincronizzazione dell’orario.
- Node- e PVE-exporter come servizi, conservare i segreti in modo sicuro.
- Definire il relabeling di Prometheus, attivare il report sulla cardinalità.
- Testare il routing di Alertmanager, i Silences e le regole di inhibition.
- Fornire i dashboard di Grafana con variabili, link ai runbook e versionamento.
Conclusione
Il monitoraggio di Proxmox con Prometheus e Grafana offre approfondimenti dettagliati se si introduce il sistema in modo iterativo: un set snello di exporter (node_exporter, pve_exporter), una strategia RESTrittiva di label per limitare la cardinalità, alert testabili con runbook e una strategia di persistenza scalabile sono i componenti chiave. Mettete in sicurezza gli accessi API, automatizzate i test e mantenete chiare strategie di fallback — così gestirete il vostro cluster Proxmox in modo stabile, tracciabile e scalabile.
Punti di controllo aggiuntivi (breve)
- Verificare la rotazione automatizzata dei token.
- Documentare i backup della TSDB e i processi di RESTore.
- Eseguire regolarmente drill sugli alert e processi di postmortem.
Sicurezza operativa, Disaster Recovery e „monitoring che si controlla“
Oltre alla funzionalità di base è cruciale che il vostro monitoring sia esso stesso robusto, testabile e ripristinabile. Considerate Prometheus, Alertmanager e Grafana non come strumenti qualsiasi, ma come servizi critici per l’operatività: richiedono propri SLO, procedure di backup, pianificazione della capacità e un’osservazione in grado di rilevare precocemente i guasti della pipeline di monitoraggio.
Metriken, mit denen Sie das Monitoring überwachen
Raccogliete metriche interne mirate delle vostre istanze di monitoring, per esempio durata dello scrape (scrape_duration_seconds), scrape falliti (scrape_samples_post_metric_relabeling), WAL-lag e utilizzo dello storage della TSDB. Definite alert quando questi indicatori superano soglie — un elevato WAL-lag segnala spesso colli di bottiglia I/O, un rapido aumento degli scrape mancanti indica problemi di rete o dell’API.
Recording Rules und Aggregationen zur Performance-Optimierung
Le Recording Rules memorizzano serie temporali preaggregate come nuove metriche e scaricano query PromQL ricorrenti e costose. Create regole per le metriche di uso frequente (ad es. utilizzo medio della memoria per nodo su 5m) anziché ricalcolare i dati grezzi ad ogni interrogazione della dashboard.
groups:
- name: recording_rules
rules:
- record: job:node_memory_used_bytes:avg5m
expr: avg_over_time(node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes[5m])
Perché funziona: le query su series già calcolate sono molto più veloci e riducono la CPU sulla istanza centrale di Prometheus. Quando fallisce: con cardinalità molto alta anche le Recording Rules devono essere limitate e progettate con cura.
TSDB-Backup und Wiederherstellung
Prometheus fornisce una Snapshot-API che genera un blocco consistente. Create snapshot regolari e archiviateli al di fuori dello storage primario (ad es. object storage). Esempio: generate uno snapshot prima di modifiche ai parametri di retention o compaction e verificate il ripristino in un ambiente di staging.
# Snapshot per API auslösen und anschließend sichern
curl -s -XPOST http://prometheus.local:9090/api/v1/admin/tsdb/snapshot
| jq -r '.data.name'
| xargs -I{} tar -C /var/lib/prometheus/snapshots -czf /backup/prom_snap_{}.tar.gz {}
Documentate esplicitamente i passaggi di ripristino (quale versione, quali file di configurazione) e testate i ripristini almeno trimestralmente.
Canary-Scrapes und synthetische Checks
Predisponete un piccolo insieme di VM o servizi “canary” che vengono verificati sinteticamente (blackbox o HTTP-Exporter). Questi forniscono segnali precoci quando cambiamenti API, segmenti di rete o problemi di autenticazione impattano interi gruppi di target.
Multi-Tenancy, Zugriffsteuerung und Compliance
Se più team usano Grafana o fornite metriche Proxmox come servizio a terzi, pRESTate attenzione a un RBAC fine-granulare. Utilizzate organizzazioni Grafana, permessi sulle cartelle e query basate su variabili per ottenere isolamento dei dati. Verificate inoltre se le metriche contengono dati personali (p.es. nomi utente nei meta della VM) e rimuoveteli/anonimizzateli per evitare rischi di compliance.
Kostenplanung und Betriebskosten reduzieren
La conservazione a lungo termine di dati ad alta cardinalità è costosa. Definite una data-retention-policy che bilanci necessità operative e costi: retention breve nello store hot, aggregazione lenta nello store a lungo termine (VictoriaMetrics, Thanos). Utilizzate sampling e downsampling per i dati storici.
Automatisierung: Provisioning und Config-as-Code
Versionate il provisioning di Prometheus, Alertmanager e Grafana (Dashboards, Alerts, Datasources) in Git. Automatizzate i rollout tramite CI/CD, testate le modifiche di configurazione contro un’istanza Prometheus di test (promtool check rules) e assicuratevi che i rollback tramite Git-Revert siano riproducibili.
Schnelle Rückfall- und Eskalationspfade
Definite chiare soglie di escalation in Alertmanager (p.es. Team → On-call → Management) e predisponete runbook documentati. Se il monitoring stesso dovesse cadere: applicate temporaneamente Silences, disattivate query costose e switchate su istanze Edge-Prometheus per ridurre i tempi di ripristino.
Check rapido (operativo): attivare le metriche di monitoraggio, creare Recording Rules, automatizzare Snapshot-Backups, mettere in piedi Canary-Scrapes, verificare RBAC e l’anonimizzazione dei dati, versionare in Git Dashboards e Alerts. Con queste misure aggiuntive gestirete il vostro Proxmox-Monitoring in modo resistente, verificabile e conforme dal punto di vista legale — prerequisiti per una conduzione operativa sostenibile e per integrazioni in software aziendale personalizzato e processi operativi centrali.
Service Discovery, Laufzeitisolierung und mTLS-Härtung
Due aspetti complementari sono praticamente rilevanti: Service Discovery automatica per pool Proxmox dinamici e un isolamento di runtime netto per Prometheus. Generare i target tramite file_sd dal vostro strumento di inventario (Ansible/CMDB), invece di mantenerli statici, riduce le configurazioni errate in fase di scalabilità.
# file_sd example
- targets: ['pve1:9273','pve2:9273']
labels:
cluster: 'prod'
role: 'hypervisor'
Eseguite Prometheus preferibilmente in un contesto di runtime dedicato (container o VM) con block-storage diretto e performante; verificate cgroup e I/O-QoS per evitare cadute di WAL e compaction. Per gli endpoint di export è consigliabile mTLS tramite Reverse-Proxy (Envoy/Nginx) e una CA interna per facilitare la rotazione dei certificati. In questo modo proteggete l’integrità dei dati, riducete la superficie di attacco e semplificate l’integrazione in software aziendale personalizzato tramite webhook sicuri.
Per questo tema sono rilevanti anche Proxmox Monitoring e Prometheus Alerting. L’articolo inquadra questi aspetti in modo comprensibile e mostra cosa conta nella pratica quotidiana.