Self-Hosting10 servizi, 10 password diverse, zero audit. Poi ho installato Authentik: un identity provider self-hosted con SSO, 2FA e audit log centralizzato. Come e perché l'ho fatto nel mio homelab.
Self-HostingCorosync knet, QDevice su Raspberry Pi 5, replica ZFS ogni 15 minuti e failover automatico su 4 container. Come funziona il mio cluster Proxmox a 2 nodi — con i limiti reali che nessun tutorial menziona.
21 aprile 2026 · 9 min lettura
VM vs LXC Proxmox: 40 MB vs 600 MB di RAM idle, boot 2s vs 30s, 8x densità. Quando usare LXC, quando serve davvero la VM, senza ideologia.
Iscriviti alla newsletter per ricevere i migliori articoli direttamente nella tua inbox.
Ho nove job Prometheus che scrapeano ogni trenta secondi, quindici target node-exporter attivi, sette blackbox probe, tre exporter di sicurezza. Raccolgo tutto. E sulle cose che contano davvero, ora ricevo anche gli alert.
Chiudiamo la serie con il layer che osserva tutti gli altri. Cluster, failover, backup, ZFS, segmentazione di rete, autenticazione — ognuno di questi pezzi genera metriche che finiscono qui. Senza un layer di osservabilità coerente, l'infrastruttura c'è ma nessuno la vede davvero.
In questa parte racconto lo stack reale — nove job, quattro layer — e il passo operativo appena chiuso: quattro alert rule attive in Prometheus, pronte a scattare prima che un problema diventi un incidente.
Prometheus e Grafana girano insieme su un container LXC dedicato. Due core, un giga di RAM, otto giga di storage su ZFS mirror SSD. Grafana è alla 12.4.1, dietro SSO Authentik con OAuth2 — nessun login separato da ricordare.
Lo scrape interval è a trenta secondi. Abbastanza granulare per fare debug in tempo reale quando qualcosa si comporta in modo strano, abbastanza leggero da non pesare su un container da un giga.
Accanto a Prometheus c'è n8n su un container separato — il motore di automazione che farà il routing delle notifiche verso Telegram quando collegherò il webhook. La raccolta e la valutazione delle rule, invece, vivono già dentro Prometheus: indipendenti, persistenti, verificabili.
Il monitoring copre quattro livelli distinti. Non è un singolo dashboard con qualche grafico di CPU: è una rete di exporter che espone metriche da ogni angolo dell'infrastruttura.
Infrastruttura. Node-exporter gira su entrambi i nodi Proxmox, sul Pi gateway e su ogni container LXC. CPU, RAM, disco, temperatura, traffico di rete — tutto esposto su porta standard. In parallelo, un pve-exporter interroga le API Proxmox per lo stato del cluster: health, stato di VM e container, storage.
Applicazioni. Sette blackbox probe HTTP controllano che le applicazioni web rispondano con un 200. Non testa la logica applicativa — testa che il servizio sia raggiungibile e risponda. Uptime monitoring base, combinato con le rule di alerting diventa la spina dorsale della reattività.
Sicurezza. Tre exporter dedicati: AIWALL per threat detection e pacchetti analizzati, CrowdSec per decisioni e ban attivi, Suricata per gli alert IDS. Tutto confluisce in Grafana — un unico punto dove vedere se qualcuno sta bussando troppo forte.
DNS. Blocky espone metriche su query totali, blocchi pubblicitari e latenza di risoluzione. Quando il DNS rallenta, tutto rallenta — avere visibilità su questo è meno ovvio di quanto sembri.
Nove job, trenta secondi di intervallo (sessanta per il DNS), copertura completa su quattro layer. Questa è la base dati: da qui partono le dashboard per il debug e le rule di alerting per la reattività.
Una dashboard che nessuno apre è un archivio. Le metriche servono davvero solo quando qualcuno — o qualcosa — le guarda e reagisce. Per questo il pezzo finale del monitoring non sono i grafici, sono le alert rule: regole dichiarative che Prometheus valuta ogni trenta secondi e che cambiano di stato quando una metrica supera una soglia per un tempo definito.
Il principio è minimalismo ragionato: poche regole che coprono il 90% degli incidenti reali in un homelab, senza il rumore di chi configura trenta alert e poi li silenzia tutti dopo una settimana.
Il file vive in /etc/prometheus/rules/homelab.yml ed è referenziato da una direttiva rule_files nel prometheus.yml principale. Ogni modifica passa da promtool check rules prima del reload — linting obbligatorio, niente config rotte che bloccano l'evaluation.
groups:
- name: homelab-critical
interval: 30s
rules:
- alert: HostDiskAlmostFull
expr: (1 - node_filesystem_avail_bytes{fstype!~"tmpfs|overlay|devtmpfs|squashfs"}
/ node_filesystem_size_bytes) > 0.85
for: 10m
labels: { severity: warning }
annotations:
summary: "Disco {{ $labels.instance }} {{ $labels.mountpoint }} sopra 85%"
- alert: TargetDown
expr: up == 0
for: 5m
labels: { severity: critical }
annotations:
summary: "Target {{ $labels.instance }} ({{ $labels.job }}) non risponde da 5m"
- alert: BlackboxProbeFailing
expr: probe_success == 0
for: 5m
labels: { severity: warning }
annotations:
summary: "Probe HTTP {{ $labels.instance }} non 2xx da 5m"
- alert: HostHighTemperature
expr: node_hwmon_temp_celsius > 80
for: 5m
labels: { severity: warning }
annotations:
summary: "Temperatura {{ $labels.instance }} sopra 80°C"Quattro nomi, quattro PromQL, quattro finestre temporali. Il campo for è la parte che filtra il rumore: un disco che sforora l'85% per trenta secondi può essere un picco di cache, a dieci minuti è un problema reale. Una probe che ritorna 500 per due scrape è un deploy in corso, a cinque minuti è un servizio giù.
Gli stati delle rule sono tre: inactive (tutto bene), pending (condizione vera ma non ancora per il tempo richiesto), firing (alert scattato). Grafana mostra lo stato in tempo reale sotto Alerting → Alert rules.
C'è un altro aspetto che vale la pena documentare. Nel post sul cluster Proxmox ho spiegato quali container sono sotto HA e quali no. Grafana non è tra quelli protetti dal failover automatico — ed è una scelta, non una dimenticanza.
Il container è replicato ogni quindici minuti su pve2 via ZFS sync: i dati non si perdono, il failover è manuale ma rapido. Le rule di alerting invece restano attive finché Prometheus gira, e Prometheus gira sempre — perché è sullo stesso CT di Grafana.
In un homelab di produzione con due nodi, la gerarchia di criticità è chiara: i container user-facing sotto HA, quelli operativi come Grafana con replica ZFS + failover manuale. Ogni scelta è un compromesso, non una lacuna — e documentarla è parte del contratto con chi gestirà l'infrastruttura dopo di te.
Le rule valutano. Grafana le mostra. Il prossimo tassello è il canale di consegna: una notifica push, un messaggio Telegram, una voce in un log centralizzato. L'architettura è già pronta — n8n gira su CT separato e ha i connector per Telegram, Slack, email, webhook custom.
È un passo aggiuntivo ma separabile: le rule scattano comunque anche senza il canale — sono visibili su Grafana e su Prometheus /alerts. Il canale è il moltiplicatore di reattività, non il prerequisito. Iterare a strati è la via pragmatica quando si gestisce produzione dopo il lavoro, non al posto del lavoro.
Il monitoring senza alert è un archivio utile per il post-mortem. Le rule lo trasformano in un sistema vivo: la macchina valuta le soglie, lo stato cambia, la notifica arriva. Il lusso di un homelab di produzione è poter scegliere quali soglie ti interessano davvero — e dirlo con quattro righe di YAML.
La configurazione base richiede un container LXC dedicato con Prometheus e Grafana installati. Nel prometheus.yml si definiscono job separati per ogni layer: node-exporter su nodi e container, pve-exporter per le API di cluster, blackbox exporter per l'uptime HTTP delle applicazioni, e gli exporter specifici per sicurezza e DNS. Lo scrape_interval a 30 secondi è un buon compromesso per un homelab — granulare abbastanza per il debug, leggero abbastanza per un container da un gigabyte di RAM. Aggiungi una directory rule_files per tenere le alert rule separate dal config principale.
Dipende dai layer che vuoi coprire. Un setup completo per un homelab Proxmox usa tipicamente: node-exporter su ogni nodo e container (infrastruttura), pve-exporter per il cluster, blackbox exporter per l'uptime HTTP delle applicazioni, exporter per i tool di sicurezza (CrowdSec, Suricata, firewall) e DNS (Blocky). Il mio setup usa 9 job distinti per coprire 4 layer — infrastruttura, applicazioni, sicurezza, DNS — più il self-monitoring di Prometheus stesso.
Quattro rule coprono il 90% degli incidenti reali in un homelab: disco oltre l'85% (prima che replica ZFS o snapshot saturino il filesystem), target scraper down da 5 minuti (container fermo, node-exporter crashato, rete segmentata male), probe HTTP non-2xx da 5 minuti (regression applicative, servizi down), temperatura sopra 80°C (picchi termici estivi su hardware casalingo). Tutte con il campo for per filtrare il rumore — soglie brevi generano alert storm, soglie di minuti isolano i problemi reali. Il canale di consegna (Telegram via n8n, email, webhook) è un layer aggiuntivo separabile.
Sei parti, sei layer: cluster, rete, autenticazione, backup, monitoring. L'ultimo non è il più appariscente — non ha failover né disaster recovery né identità federata. È però quello che tiene gli altri onesti: senza osservabilità attiva, qualsiasi architettura ben scritta sulla carta scivola lentamente verso uno stato imprevisto.
Le quattro rule su disco, probe, target e temperatura sono il minimo utile: linting via promtool, stato visibile su /rules di Prometheus, evaluation ogni trenta secondi. Il canale Telegram è il prossimo passo, non il prerequisito — e questo è il pattern che ha tenuto insieme tutta la serie: un layer alla volta, scritto per durare, iterato in produzione.
Fonti — Prometheus, Grafana
Parte 1 — Perché trattare il homelab come produzione
Parte 2 — Cluster Proxmox 2 nodi: Corosync, QDevice e HA
Parte 3 — Networking: 3 subnet, Pi firewall e NetBird VPN
Parte 4 — SSO e 2FA su tutto con Authentik
Parte 5 — ZFS, backup e disaster recovery
Parte 6 — Monitoring con Prometheus e Grafana — questo articolo
| Layer | Job Prometheus | Cosa monitora |
|---|---|---|
| Infrastruttura | proxmox-host, lxc-containers, pve-exporter | CPU, RAM, disco, temp, stato cluster |
| Applicazioni | blackbox-http | Uptime HTTP 200 su 7 servizi |
| Sicurezza | aiwall-orchestrator, crowdsec-exporter, suricata-exporter | Threat detection, ban, alert IDS |
| DNS | blocky-dns | Query, blocchi, latenza |
| Self-monitoring | prometheus | Salute dello stack stesso |