Lo scudo di Prometeo per le VPN: come abbiamo unito Prometheus e Grafana nel 2026

Perché nel 2026 il monitoraggio della VPN non è un lusso, ma una vera armatura

I rischi dell’invisibilità dei tunnel

Se la VPN funziona in autonomia, scopriamo i problemi nel momento più inopportuno. Interruzione di una riunione, blocco della fatturazione, perdita di telemetria dai nodi remoti. Nel 2026, il traffico passa sempre più spesso attraverso tunnel criptati, quindi il tempo di reazione ai guasti è cruciale. Non possiamo permetterci scatole nere. Ci servono metriche, dashboard e alert che partano prima che gli utenti scrivano in chat "non si apre nulla". E sì, si può fare.

Una VPN senza monitoraggio è come un’auto senza cruscotto. Si viaggia finché va, ma la strada è a senso unico. Aggiungiamo Prometheus e Grafana per non vedere solo la velocità, ma anche la temperatura del motore, il livello del carburante, la pressione delle gomme. Meno metafore e più sostanza: le metriche dei tunnel sono il nostro linguaggio di allerta precoce.

Quali KPI e SLO funzionano davvero

Amiamo i numeri con senso compiuto. Per la VPN questi sono: disponibilità dei tunnel, latenza media e p95 del handshake, successo nelle connessioni, errori di cifratura, throughput in entrambe le direzioni, peer e client attivi, tempo di rotazione delle chiavi, carico CPU sulla crittografia. SLO? Per esempio, il 99,9% di disponibilità e non più dello 0,1% di tentativi di connessione falliti in 28 giorni. Semplice, misurabile e utile.

Le metriche non servono per “abbellire”. Servono per prendere decisioni. Aumentare i limiti, aggiungere nodi, ruotare le chiavi più o meno spesso, deviare parte del traffico su una regione di backup. Con gli SLO in vigore, le discussioni tecniche tipo "sembra tutto a posto" spariscono, così come le chiamate notturne inutili.

Cosa è cambiato nel 2026

Tre grandi cambiamenti. Primo, gli istogrammi nativi in Prometheus sono diventati lo standard di fatto per le metriche di rete, semplificando archiviazione e calcolo dei quantili. Secondo, gli approcci eBPF per l’osservabilità offrono overhead ridotto e visibilità profonda fino a flussi e pacchetti. Terzo, OpenTelemetry e Prometheus hanno imparato a convivere: attraverso OTEL Collector, remote_write e l’esportazione in formato unico. Non sono solo trend, ma routine per team maturi.

Architettura: Prometheus e Grafana per VPN senza problemi

Schema base e ruoli dei componenti

Lo scenario classico: esportatori sui gateway VPN, Prometheus raccoglie metriche con modello pull, le conserva e le invia a storage a lungo termine tramite remote_write, Grafana crea dashboard e gestisce alert, Alertmanager filtra il rumore e indirizza le notifiche. Minima magia, massimo controllo. Più è semplice, più è affidabile.

Aggiungiamo Node Exporter su ogni gateway per vedere CPU, dischi, memoria e interfacce di rete. Per diagnosi di livello link teniamo Blackbox Exporter che verifica la raggiungibilità delle porte VPN dall’esterno. Per reti avanzate, agenti eBPF basati su Cilium o simili per individuare colli di bottiglia a livello di pacchetto. Nessun sovraccarico, ma niente al buio.

Flusso dati, archiviazione e retention

Le metriche VPN sono spesso ad alta frequenza: connessioni su/giù, rotazione chiavi, cambi peer. Impostiamo intervalli di scrape tra 5 e 15 secondi per indicatori critici, 30-60 secondi per background. La retention locale in Prometheus è breve, tipo 15 giorni; i dati storici finiscono in storage remoto o servizi TSDB via remote_write. Il bilanciamento è semplice: velocità locale, storia remota per analisi.

Da dove cominciare? Con una lista: identificare metriche critiche, definire SLO, scegliere retention, abilitare campionamento per metriche pesanti. Fondamentale separare i job di scrape: così si regolano frequenze e timeout per protocolli e zone più facilmente.

Come scegliere metriche e frequenze di interrogazione

La regola è semplice: metriche sintomatiche le sondiamo più spesso, cause un po’ meno. Per esempio, peer attivi, errori handshake e latenze delle intestazioni ogni 5-10 secondi. Crittografia profonda e distribuzione dimensione pacchetti ogni 30-60. Nel 2026 evitiamo di sparare a tutto: alta frequenza solo dove veramente serve per alert.

Una nota sulla cardinalità: etichette per singolo client possono distruggere la TSDB. Massima cautela. Aggregiamo a livello di nodo o peer e abilitiamo esportazioni dettagliate per client solo per brevi indagini. Risparmiamo costi e non soffochiamo Prometheus.

Esportazione metriche VPN: OpenVPN, WireGuard, IPsec

OpenVPN: un combattente collaudato

OpenVPN è ampiamente usato in migliaia di aziende. Per monitorarlo utilizziamo esportatori dedicati che leggono l’interfaccia management o file di stato. Cosa raccogliamo: client attivi, byte in/out, durata sessioni, errori di renegoziazione, riavvii del demone. Un esempio: avviamo l’esportatore vicino al processo, assegniamo la porta di gestione e raccogliamo metriche in formato semplice.

Esempio di comando minimalista: openvpn_exporter --management.addr 127.0.0.1:7505 --management.auth disabled --web.listen-address :9176. Prometheus interroga la :9176 e ottiene le metriche. Tutto chiaro e trasparente.

WireGuard: moderno, veloce e essenziale

WireGuard è lo standard dove contano performance e semplicità. Le metriche tipiche: wg_peers, handshake_seconds, bytes_sent, bytes_received, allowed_ips, endpoint. L’esportatore funziona tramite wg show e interfacce di sistema. Misuriamo non solo peer e byte, ma anche la latenza dell’ultimo handshake, utile per individuare connessioni semi-morte.

Esempio di avvio: wireguard_exporter --web.listen-address :9586 --include-interfaces wg0,wg1 --resolve-endpoints true. Output: metriche pulite con etichette interfacce e peer, perfette per alert e pannelli.

IPsec: strongSwan e Libreswan senza misteri

IPsec resta fondamentale nelle reti aziendali. Esportiamo metriche via API Vici di strongSwan o log e script ausiliari per Libreswan. Critici: numero SA stabilite, riavvii, errori di autenticazione, ciclo di vita chiavi, eventi di rekey, verifiche DPD. Manteniamo job dedicato con etichette per tunnel site-to-site, comodo per filtri Grafana.

Se Vici non è accessibile, usiamo un collector leggero che analizza ipsec statusall e genera metriche a bassa cardinalità. Non perfetto, ma funzionale. Fondamentale mantenere formato stabile e testare parser ad ogni aggiornamento.

Approcci universali: Node Exporter e Blackbox

Node Exporter viene in soccorso quando esportatori specifici sono offline: monitora carico CPU su crittografia, queue overflow, drop di rete, saturazione interfacce. Blackbox Exporter è il nostro esploratore: test TCP porto, UDP via proxy, verifica TLS, tempi di risposta. Un monitoraggio base in un’ora dà già grande tranquillità.

Un paio di suggerimenti: non attivate tutti i collector Node Exporter di default, eliminate metriche rumorose; configurate moduli Blackbox separati per UDP/TCP/TLS e taggateli con region e probe.

Configurazione Prometheus: dallo scrape alla sicurezza

Esempi di scrape_configs

Di seguito esempi compatti senza interruzioni. WireGuard: scrape_configs: - job_name: wireguard scrape_interval: 10s metrics_path: /metrics static_configs: - targets: ["vpn-gw-1:9586","vpn-gw-2:9586"] labels: role: "vpn" proto: "wg". OpenVPN: - job_name: openvpn scrape_interval: 15s static_configs: - targets: ["vpn-gw-1:9176"] labels: role: "vpn" proto: "ovpn". IPsec: - job_name: ipsec scrape_interval: 30s static_configs: - targets: ["vpn-gw-1:9905"] labels: role: "vpn" proto: "ipsec".

Blackbox TCP check: - job_name: vpn-blackbox metrics_path: /probe params: module: ["tcp_connect"] static_configs: - targets: ["vpn.example.internal:51820"] relabel_configs: - source_labels: [__address__] target_label: __param_target - source_labels: [__param_target] target_label: instance - target_label: __address__ replacement: "blackbox:9115". Il senso è chiaro: testiamo la connessione e otteniamo tempo di risposta e codice.

Relabeling, service discovery ed etichette

Etichette curate sono metà del lavoro. Convertiamo instance in nomi chiari, aggiungiamo labels environment, region, proto, role, cluster. Il relabeling elimina rumore: scartiamo client_id e etichette ad alta cardinalità. Nel service discovery Kubernetes usiamo filtri per annotazioni per trovare esportatori in DaemonSet. In bare-metal gestiamo file_sd_configs generate da CMDB o Terraform, tutto dichiarativo senza click manuali.

Esempio di relabel per instance: - action: replace source_labels: [__meta_kubernetes_pod_node_name] target_label: instance. E per protocollo: - action: replace source_labels: [__meta_kubernetes_pod_label_proto] target_label: proto. Niente di magico, ma risparmia ore nella costruzione dei dashboard.

Remote_write, federazione e scaling

Quando la VPN cresce, evitiamo di sovraccaricare Prometheus locale con dati storici. Attiviamo remote_write verso backend a lungo termine. Config in una riga: remote_write: - url: https://tsdb.internal/api/v1/write queue_config: capacity: 200 max_shards: 10. Federiamo per riepiloghi cross-region: aggregati p95 handshake e peer attivi con etichette region e proto. Così il NOC ha una vista unica e i team regionali dettagli locali.

La stabilità conta più di tutto. Non saturate le code remote_write. Usate alert su ritardi e drop. Se serve, spezzate metriche su più profili remote_write per tipi di carico.

Sicurezza, limiti e affidabilità

Scrape via TLS con autenticazione mutua? Sì. User:pass semplice? In reti isolate, forse. Limiti di velocità su esportatore e Prometheus sono fondamentali: una richiesta malevola non deve bloccare tutto. Timeout per job e metriche con honor_timestamps: false se le sorgenti sono strane. Sempre un limite sui time series per job per evitare distruzioni accidentalmente TSDB.

Backup di configurazioni è importante quanto quello dati. Archiviamo su Git, integriamo CI, validiamo con promtool check config e test alert in pipeline. Noioso, ma evita sorprese notturne.

Dashboard Grafana: dal polso alla diagnosi approfondita

Struttura del dashboard e pattern UX

Costruiamo tre sezioni orizzontali. In alto status e SLO: disponibilità, peer attivi, errori connessione 1h e 24h. Centro prestazioni: throughput, p95 handshake, CPU crittografia, drop interfacce. In basso diagnostica: peer specifici, eventi DPD, riavvii demone, distribuzione RTT. Filtri per environment, region, proto, gateway: indispensabili.

Evitare sovraccarico di colori. Verde per OK, rosso per problemi seri, giallo per degradazioni. Legende brevi, titoli chiari. Sempre unità di misura: byte, pacchetti, secondi. Banale ma salva da fraintendimenti.

Pannelli per i diversi protocolli

WireGuard: grafici per peer e interfacce, latenza ultimo handshake, velocità byte in/out, contatore tentativi connessione. OpenVPN: client attivi, renegoziazione e errori, cambi route, carico processo. IPsec: SA stabilite, dinamica rekey, autenticazioni fallite, DPD live. Separiamo per protocollo, con panoramica comune superiore.

L’idea è rapida deviazione da sintomo a causa. Clic su p95 handshake verso peer specifico, dal traffico a interfaccia, da alert a dashboard nodo. Meno click, meno stress.

Tre livelli di vista: executive, NOC, ingegneri

Abbiamo tre preset. Executive: 5-7 tile con SLO, capacità e trend regionali, niente dettagli minuti. NOC: mappa incidenti, regioni calde, code alert. Ingegneri: dettagli completi, log, metriche, filtri. Così si risolve il dilemma "mostrami solo l’essenziale" vs "dammi tutto". Tutti contenti.

Consiglio: fissate versioni dei dashboard. Se qualcuno "migliora" assi o query, serve rollback facile. Cronologia modifiche è la vostra assicurazione contro errori umani.

Alerting: meno rumore, più valore

Regole e finestre basate su SLO

Scriviamo alert da SLO. Esempio: se la percentuale di handshake falliti supera 1% per 5 minuti continui, alert warning; 5% per 10 minuti, pagina. Se disponibilità tunnel scende sotto 99,9% in 24h, incidente medio. Matematica semplice, comportamento prevedibile. Niente supposizioni.

Importante scegliere bene le finestre: troppo corte generano rumore, troppo lunghe ritardano risposta. Per VPN 2-5 minuti per sintomi, 15-30 per trend. Ricordate i window notturni per rotazioni chiavi, per non svegliare inutilmente.

Sintomi vs cause

Sintomo: p95 handshake oltre 500 ms o calo improvviso peer attivi. Causa: CPU crypto sovraccarica o uplink caduto. Configuriamo due classi alert. Sintomatici: rumorosi ma brevi, reazione immediata. Causali: accompagnatori per guidare l’ingegnere. Insieme portano chiarezza, non caos.

Nel 2026 annotazioni unite in Grafana e Alertmanager permettono link a dashboard e checklist breve. In pratica accelera la risoluzione del 20-30%. Dettaglio piccolo, impatto grande.

Routing e soppressione del rumore in Alertmanager

Routing per region, proto e severity. Solo criticità della regione destinata vanno agli on-call; resto in canali generali con delay e deduplica. Usano inhibitor: se c’è alert “degrado regionale”, gli alert “porta non disponibile” della stessa regione sono soppressi. Risultato: -60% notifiche inutili in crisi.

Esempio breve di regola: groups: - name: vpn-alerts rules: - alert: WireGuardHandshakeSlow expr: histogram_quantile(0.95, sum(rate(wg_handshake_seconds_bucket[5m])) by (le,region)) > 0.5 for: 5m labels: severity: warning annotations: summary: p95 handshake superiore a 500 ms description: La regione {{ $labels.region }} sta riscontrando latenza.

Test alert e controllo continuo

Creiamo profili di carico e simuliamo guasti: disabilitiamo interfaccia, saturiamo CPU crypto, blocchiamo management OpenVPN. Gli alert devono scattare come previsto. Registriamo risultati nel playbook. Ejercizi regolari insegnano al team e riducono MTTD e MTTR. Niente magia, solo disciplina.

In più le regole passano in CI: promtool check rules, linter per espressioni, serie sintetiche per quantili complessi. Non perfetto, ma evita errori banali e soglie impossibili.

Log, tracing e eBPF come potenziatori

Log VPN convertiti in metriche tramite parsing

I log sono miniera di dettagli: eventi DPD, renegoziazioni, errori CRL. Non affoghiamo nel testo ma trasformiamo il cruciale in metriche: contatori errori per tipo, istogrammi durata handshake, etichette per regione e nodo. Un complemento utile all’esportatore quando protocollo dà poco. Nel 2026 molti team usano parser unificato e spingono metriche in Prometheus via Pushgateway per eventi rari o tramite OTEL Collector con prometheusremotewrite.

Importante distinguere: log per indagine, metriche per segnale. Colleghiamo alert a pannelli log. Un contesto breve aiuta molto.

eBPF: visione profonda ma con cautela

eBPF regala una visione dettagliata del traffico: flussi, latenze, ritrasmissioni, drop con cause. Oro liquido per VPN, specialmente in casi controversi tra rete e sviluppo. Attiviamo agenti eBPF su gateway con traffico più alto, raccogliendo metriche aggregate. Controlliamo overhead e aggiornamenti kernel. Regola: accendiamo solo ciò che useremo regolarmente.

Con eBPF individuiamo facilmente perché i peer "lampeggiano": rotte perse, MTU che rompe frammentazione o code interfaccia sature. Questi indizi salvano ore e nervi.

OpenTelemetry e Prometheus insieme

OpenTelemetry nel 2026 è non solo tracing ma anche metriche. Passiamo metriche VPN via OTEL Collector, normalizziamo etichette, convertiamo in formato Prometheus e spingiamo a storage. Vantaggi: punto unico di configurazione, filtraggio flessibile, tripla compatibilità con log e trace. Svantaggi: serve disciplina e documentazione per evitare confusione.

Setup operativo: esportatori inviano metriche direttamente a Prometheus per alert, parallelamente Collector fa arricchimenti e remote_write a storage lungo termine. Duplicazione strana ma aumenta la resilienza ai guasti.

Operatività: prestazioni, costi e affidabilità

Budget risorse sotto carico

I gateway VPN spesso vanno al limite CPU per crittografia. Monitoriamo cpu_utilization, crypto_time, irq_load. Per Prometheus fissiamo limiti TSDB e cache pagina. Per decine di gateway bastano 2 vCPU e 4-8 GB RAM. Per centinaia: scale out con raccolta shardata, federazione, distribuzione per zone. Non puntiamo a "sollevare un gigante" su un solo nodo, troppo costoso e poco affidabile.

Due regole: se limiti di scrittura, ridurre frequenza, abbattere cardinalità, aggregare eventi rari in contatori. Se limiti di lettura in dashboard, cache, espressioni semplici, downsampling dove possibile.

Cardinalità, retention ed economia

La cardinalità è il nemico dell’osservabilità. Centinaia di migliaia di etichette per client distruggono TSDB e budget. Manteniamo aggregazioni a livello peer o tunnel, per indagini attiviamo log dettagliati temporanei. Retention su livelli: caldi 7-15 giorni localmente, tiepidi 30-90 giorni in TSDB remoto, archivio più lungo su object storage o database economico.

In soldi: cardinalità extra significa dischi, CPU e licenze extra per storage lungo. Tagliando l’80% delle etichette inutili, il budget si riduce del 30%. Fa male sul momento, ma dopo migliora per tutti.

Backup, aggiornamenti e scenari DR

Prometheus è stateful ma non critico estrema; configurazioni e alert sono fondamentali. Backupamo repo Git, snapshot storage lungo, segreti e certificati. Aggiornamenti con canary: un collector, una Grafana, un Alertmanager per volta. Se qualcosa va storto rollback senza panico.

Per DR teniamo una seconda regione con Prometheus “freddo” e sincronizzazione dashboard. Se cade il primario, attiviamo backup. Controlliamo migrazioni ogni trimestre. Noioso, ma vera affidabilità.

Compliance, audit e privacy

Metriche VPN possono contenere dati sensibili. Evitiamo identificatori personali nelle etichette, usiamo hashing o pseudonimi. Accesso dashboard limitato per ruoli: NOC, ingegneri, auditor. Log di accesso e modifiche raccolti centralmente. Aiuta non solo audit ma anche a capire chi e cosa ha rotto, se serve.

Casi di studio: dal piccolo ufficio alla rete globale

Piccola impresa: 10-50 utenti

Un gateway OpenVPN, uno WireGuard come riserva. Node Exporter, esportatore protocollo minimo, Prometheus su server piccolo, Grafana vicino. Alert: disponibilità, errori autenticazione, peer offline >5 minuti. Implementazione in 1-2 giorni. Dashboard "tutto verde" e poche notifiche settimanali.

Ottimizzazione: togliere metriche costose, attivare solo dashboard necessari, programmare rotazioni chiavi. Non dimenticare test failover regolari: chi deve fare cosa se il gateway principale va in vacanza.

Azienda media: filiali e lavoro mobile

Più gateway in regioni diverse, WireGuard per site-to-site, OpenVPN per client. Prometheus in ogni regione, federazione verso l’alto, storage remoto su cluster condiviso. Alert via Alertmanager con routing regione. Dashboard su tre livelli, ruoli in Grafana. eBPF on demand per indagini su incidenti di rete.

Risultato: tempo di rilevamento sceso da decine a pochi minuti, indagini da giorni a ore. Business vede SLO chiari e pianifica capacità senza indovinare.

Provider o rete globale

Centinaia di gateway, migliaia di peer. Senza disciplina non si va avanti. Collector shardati, aggregazioni regionali, regole etichette rigide, configurazioni automatizzate da CMDB. remote_write su più storage, test carico regolari, aggiornamenti canary. Dashboard NOC dedicata con filtro rumore. Investiamo in automazione per risparmiare stress manuali.

Effetto: incidenti prevedibili, risposte rapide, minimo rumore. Costoso, ma meno di fermi massivi e penali SLA. Il team respira meglio, il business dorme tranquillo.

Errori comuni e come evitarli

Primo: spam di metriche e cardinalità per client incontrollata. Si risolve con politiche di cardinalità. Secondo: alert senza priorità o istruzioni. Corretto con annotazioni, playbook, SLO. Terzo: dashboard da 100 panel inutili. Serve struttura, UX e tre livelli. Quarto: sicurezza “poi si vede”. Si cura da subito con TLS, ruoli e audit. Quinto: niente test e DR. Serve disciplina, altrimenti rischiate brutte sorprese.

E sì, non temete di togliere il superfluo. Il monitoring non è un museo di metriche ma uno strumento. Meglio poco e buono.

Checklist d’implementazione: breve e pratica

Preparazione

Definire protocolli e nodi. Scegliere esportatori. Descrivere SLO. Decidere retention e budget. Disegnare schema etichette. Stabilire ruoli accesso e requisiti sicurezza minimi. Preparare CMDB o file per file_sd_configs. Tutto fattibile in una settimana senza eroi.

Importante allinearsi: quali incidenti sono critici, dove vanno notifiche, chi è on-call. Senza questo anche il miglior monitor diventa una bella schermata in sala riunioni.

Implementazione

Installare Node Exporter e esportatori protocollo. Lanciare Prometheus e Alertmanager. Configurare scrape_configs, relabeling, remote_write. Deploy Grafana, importare dashboard base, aggiungere template. Generare primi alert. Test rapidi: bloccare porte, stressare demone, controllare alert e dashboard vivi.

Registrare risultati, misurare MTTD. Regolare soglie e frequenze. È l’occasione per adattare monitoraggio alla vostra realtà, non al manuale.

Avvio e formazione

Sessione per NOC e ingegneri: come leggere dashboard, filtrare per etichette, tracciare cause. Documentare playbook per top-5 incidenti. Attivare fire-drill mensili con simulazione guasti reali. Aggiornare guide dopo ogni incidente. Piccole cose che fanno risparmiare settimane.

Dopo un mese retrospettiva: quali alert inutili, metriche inutili, dove mancava contesto. Conversazione onesta e due giorni per migliorare. Così il sistema inizia a lavorare per voi, non contro.

FAQ: domande frequenti raramente scritte

Risposte rapide

Serve monitorare client per utente?

Solo per brevi indagini. Per monitoraggio continuo aggregate a livello peer o tunnel. Etichette personali digestiscono cardinalità e costi. E sì, è la fonte di dolore per molti principianti.

Quale intervallo di polling per WireGuard?

Per sintomi 5-10 secondi, per cause 30-60. Se budget tirati, allungate finestre ma mantenete check veloci su porte.

Cosa è più veloce da implementare: monitoraggio OpenVPN o WireGuard?

WireGuard di solito è più semplice: meno entità, metriche più pulite. Ma se avete già management OpenVPN configurato, anche lì tutto si monta in un paio d’ore.

Dettagli tecnici

Cosa conservare a lungo e cosa localmente?

Localmente: dati caldi 7-15 giorni per reazioni rapide. A lungo: aggregati latenza, errori autenticazione, throughput e capacità. Serie raw ad alta frequenza solo se avete reale esigenza analitica.

Come testare alert senza paura?

Scenari in Git, promtool per controlli, serie sintetiche per quantili complessi. Una volta al mese simulazioni con porta down, CPU alta, interventi manuali dashboard. Noioso, ma infallibile.

Gestione operativa

Come gestire falsi positivi notturni?

Attivare inhibitor, livellare finestre temporali, aggiungere annotazioni con contesto e playbook. Soprattutto, dopo l’incidente prendersi tempo per risolvere la causa del rumore, altrimenti si corre in tondo.

Serve subito OpenTelemetry?

Se partite da zero, no. Prima metriche base e alert, poi log e OTEL integrati. Quando presi la mano, Collector sarà vostro alleato. Cercare di fare tutto subito è strada verso delusione.

Come fornire metriche in modo sicuro da DMZ?

mTLS, allowlist statica, agent Prometheus dedicato in DMZ con federazione verso l’alto. Non esponete tutto indiscriminatamente. E non dimenticate rotazione e revoca certificati.