Integrazione tra Prometheus e Grafana che intercetta i problemi

Pubblicato il 6 ottobre 2026

L'integrazione tra Prometheus e Grafana permette di sfruttare al meglio le metriche del server: mostra cosa sta cambiando, ti avvisa prima che il superamento di una soglia causi un'interruzione e fornisce dati concreti quando un servizio sembra lento. Prometheus raccoglie e archivia i dati numerici. Grafana li trasforma in dashboard e avvisi che il team può comprendere a colpo d'occhio. Insieme, sostituiscono le supposizioni con una visione operativa più chiara.

Che si tratti di un VPS, un server dedicato, una piattaforma SaaS o un negozio online molto frequentato, questa configurazione è particolarmente utile prima che qualcosa smetta di funzionare. Un disco pieno, memoria esaurita, tempi di risposta in aumento o un pool di connessioni al database prossimo al limite lasciano in genere tracce nelle metriche. Il servizio potrebbe funzionare al momento, ma il grafico sta già raccontando cosa succederà dopo.

I ruoli di Prometheus e Grafana

Prometheus è un sistema di monitoraggio basato su serie temporali. Raccoglie metriche dai target a intervalli regolari, assegna etichette a queste misurazioni e le rende disponibili per le query. È particolarmente adatto al monitoraggio di server e applicazioni, perché metriche come l'utilizzo della CPU, la pressione della memoria, il numero di richieste, la latenza e la capacità del file system si integrano naturalmente nel suo modello.

Grafana è il livello di visualizzazione e gestione degli avvisi. Si collega a Prometheus come origine dati, consente di creare pannelli con query PromQL e di organizzarli in dashboard. Una buona dashboard Grafana non deve essere decorativa. Il suo scopo è rispondere rapidamente a domande pratiche: il server funziona correttamente? Quale servizio sta usando le risorse? Le prestazioni stanno peggiorando? Il rilascio delle 14:00 ha cambiato qualcosa?

Prometheus può valutare autonomamente le regole degli avvisi, mentre Alertmanager gestisce il raggruppamento, l'instradamento e la disattivazione temporanea delle notifiche. Grafana può anche creare avvisi a partire dalle query delle dashboard. Entrambi gli approcci possono funzionare. Per gli avvisi relativi all'intera infrastruttura e gestiti tramite codice, spesso è più semplice standardizzare le regole di Prometheus insieme ad Alertmanager. Per una dashboard dedicata a un servizio specifico, gli avvisi gestiti da Grafana possono essere pratici. Evita di eseguirli entrambi per la stessa identica condizione, a meno che le notifiche duplicate alle 3 del mattino. non siano previste.

Integrazione tra Prometheus e Grafana: un'architettura pratica

Un'architettura iniziale ragionevole è semplice. Quando possibile, esegui Prometheus e Grafana su un VPS dedicato al monitoraggio, separato dal server o dall'applicazione sotto osservazione. Installa gli exporter sui sistemi monitorati. Gli exporter espongono le metriche tramite un endpoint HTTP e Prometheus le raccoglie secondo una pianificazione.

Per i server Linux, Node Exporter è la scelta abituale per iniziare. Espone misurazioni a livello di host, tra cui CPU, memoria, media del carico, utilizzo del disco, traffico di rete e statistiche del file system. Gli exporter per database possono aggiungere visibilità su MySQL, PostgreSQL, Redis e altri servizi. Le metriche delle applicazioni possono provenire da un endpoint Prometheus nativo, da una libreria del framework o da un exporter scelto con attenzione.

Il flusso di dati di base è semplice:

• Un exporter espone le metriche di un server, database o applicazione.
• Prometheus raccoglie i dati dall'endpoint e archivia le serie temporali.
• Grafana interroga Prometheus e visualizza i risultati.
• Le regole degli avvisi valutano le soglie o i comportamenti anomali e inviano notifiche tramite il canale selezionato.

Avere un quadro semplice è importante perché semplifica anche la risoluzione dei problemi. Se un pannello Grafana è vuoto, verifica che Grafana riesca a interrogare Prometheus. Se Prometheus non dispone di dati, controlla la pagina dei target e l'endpoint dell'exporter. Se il target è inattivo, controlla l'accesso alla rete, le regole del firewall, lo stato del servizio e la configurazione dell'exporter. A questo punto, di solito anche i log raccontano la stessa storia.

Inizia dalle metriche che portano a un'azione

Raccogliere tutte le metriche disponibili genera rumore, occupa spazio di archiviazione e produce dashboard che nessuno consulta. Inizia dalle metriche che supportano decisioni operative chiare. Per la maggior parte dei server, si tratta di utilizzo e carico della CPU, memoria disponibile, attività di swap, spazio su disco e utilizzo degli inode, latenza di I/O del disco, errori di rete, disponibilità dei processi e tempo di attività del sistema.

Per le applicazioni web, aggiungi il numero di richieste HTTP, il tasso di errori, la durata delle richieste, le connessioni attive e la lunghezza della coda, se pertinenti. Per i database, monitora il numero di connessioni, le query lente, lo stato della replica, l'efficienza della cache, i blocchi e la crescita dello spazio di archiviazione. Un sito di e-commerce potrebbe considerare fondamentali gli errori durante il checkout e la latenza del database; un'agenzia di sviluppo potrebbe dare priorità al tempo di attività degli ambienti dei clienti e all'esito dei backup. Dipende dal carico di lavoro, non da quale dashboard sia più impressionante.

Usa le etichette con attenzione. Le etichette consentono di filtrare per ambiente, ruolo del server, cliente, area geografica o applicazione. Possono anche generare un gran numero di serie temporali distinte se includono valori che cambiano continuamente, come ID utente, ID ordine, token di sessione o percorsi di richiesta con parametri dinamici. Le etichette ad alta cardinalità sono un modo subdolo per far lavorare Prometheus molto più del necessario.

Configura la raccolta senza introdurre nuovi rischi

Prometheus ha bisogno di un elenco di target nella propria configurazione. Un target di base per Node Exporter potrebbe essere simile a questo:

``\`yaml scrape_configs:

• job_name: node

static_configs:

• targets: ['10.0.0.15:9100']

labels: environment: production role: web ``\`

In un ambiente di piccole dimensioni, i target statici sono chiari e affidabili. Quando l'infrastruttura cresce, in genere è preferibile usare il rilevamento dei servizi, perché i target vengono aggiunti e rimossi automaticamente. Qualunque metodo tu scelga, mantieni privati gli endpoint di monitoraggio quando possibile. Non lasciare le porte degli exporter esposte indiscriminatamente su Internet solo perché una dashboard ha bisogno di dati.

Se opportuno, usa una rete privata, elenchi di autorizzazione del firewall, una VPN o un proxy inverso con autenticazione. Cifra il traffico quando le metriche attraversano reti non attendibili. Le metriche Prometheus possono rivelare nomi host, nomi interni dei servizi, modelli di carico di lavoro e dettagli sulle versioni. Sono dati operativi, non elementi decorativi da esporre al pubblico.

Imposta la conservazione dei dati in base alle esigenze di gestione degli incidenti e pianificazione della capacità. Per molte installazioni di piccole dimensioni, da quindici a trenta giorni sono sufficienti per individuare modifiche recenti e tendenze a breve termine. Una conservazione più lunga aiuta a individuare la domanda stagionale e la crescita graduale della capacità, ma richiede più spazio su disco. Per consultare dati storici su periodi più lunghi, valuta l'archiviazione remota invece di conservare dati senza limiti sullo stesso VPS che esegue Grafana.

Crea dashboard per diagnosticare rapidamente i problemi

Per prima cosa, crea una dashboard panoramica. Dovrebbe mostrare lo stato dei sistemi più importanti, non tutte le metriche del catalogo. Una panoramica utile include spesso la disponibilità dei server, CPU, memoria, utilizzo del disco, traffico di rete, tasso di errori HTTP e latenza delle richieste. Usa variabili per host, ambiente e servizio, così una dashboard può essere riutilizzata per più sistemi senza diventare un museo di copie e incolla.

Poi crea dashboard specifiche per ciascun servizio. Una dashboard per un database richiede pannelli diversi da quelli di una dashboard per un server web. Una dashboard per un processo in background dovrebbe mostrare la lunghezza della coda, il tempo di elaborazione, i nuovi tentativi e gli errori. Scegli titoli diretti per i pannelli: «Spazio libero su /var», «Tasso di errori HTTP 5xx» e «Connessioni attive PostgreSQL» sono preferibili a nomi spiritosi che richiedono di essere decifrati proprio nel momento peggiore.

È utile aggiungere annotazioni per rilasci, finestre di manutenzione e modifiche alla configurazione. Quando la latenza aumenta poco dopo un rilascio, un'annotazione trasforma un grafico sospetto in uno spunto utile per l'analisi. Non dimostra un rapporto di causa-effetto, ma offre all'indagine un punto di partenza ragionevole.

Crea avvisi sui sintomi, non su ogni singolo dato

Un avviso sulla CPU all'80% può essere utile per un server e privo di significato per un altro. Un nodo dedicato all'elaborazione in batch può funzionare a pieno carico per ore per scelta progettuale, mentre un improvviso aumento della latenza API può avere effetti immediati sui clienti anche quando l'utilizzo della CPU è moderato. Le regole degli avvisi dovrebbero riflettere l'impatto e il comportamento previsto.

Inizia con avvisi per le condizioni che richiedono un intervento: un exporter o un servizio non è raggiungibile, lo spazio su disco si esaurirà presto, i processi di backup non riescono, la pressione sulla memoria causa attività di swap, il tasso di errori aumenta, i certificati sono prossimi alla scadenza oppure la replica del database non funziona correttamente. Imposta una durata per evitare che brevi picchi sveglino qualcuno senza motivo. Ad esempio, uno spazio su disco persistentemente ridotto per quindici minuti è in genere più utile per intervenire di un calo di cinque secondi.

Ogni avviso dovrebbe rispondere a tre domande: cosa non funziona, dove si verifica il problema e cosa dovrebbe controllare per prima cosa chi interviene? Aggiungi all'annotazione dell'avviso il nome del server, l'ambiente, il servizio e una breve istruzione tratta dal runbook. «Spazio su disco insufficiente» non basta quando ci sono venti server e qualcuno legge il messaggio dal telefono.

Le disattivazioni temporanee e le finestre di manutenzione fanno parte di una gestione efficace degli avvisi: non servono a nascondere i problemi. Usale per gli interventi pianificati e rimuovile al termine dei lavori. Una disattivazione dimenticata ha un pessimo senso del tempismo.

Mantieni gestibile lo stack di monitoraggio

Considera le dashboard, le regole degli avvisi e la configurazione di Prometheus come risorse operative. Esegui dei backup, rivedile dopo gli incidenti e, quando è possibile farlo in sicurezza, archivia la configurazione nel sistema di controllo delle versioni. Verifica periodicamente gli avvisi. Un canale di notifica mai testato è solo una speranza teorica.

Monitora anche il sistema di monitoraggio. Prometheus ha bisogno di memoria e spazio di archiviazione sufficienti, Grafana richiede backup della propria configurazione e del database e gli exporter devono rimanere raggiungibili anche dopo le modifiche al firewall o alla rete. Monitora la durata delle raccolte, quelle non riuscite, la capacità di archiviazione e gli errori di consegna degli avvisi. Se il server di monitoraggio è sovraccarico, i grafici potrebbero sembrare tranquilli mentre il sistema, senza farsi notare, non raccoglie i dati di cui hai bisogno.

Per i team che desiderano assistenza operativa insieme alla gestione della propria infrastruttura, kodu.cloud può supportare gli ambienti VPS e server monitorati, mentre tu continui a tenere sotto controllo le metriche importanti per la tua attività. L'obiettivo non è rendere misterioso il monitoraggio. È ridurre i problemi futuri, individuarli prima e renderli più facili da gestire.

Una configurazione ben ottimizzata di Prometheus e Grafana non elimina gli incidenti. Offre al team un preavviso maggiore, un contesto più chiaro e meno decisioni alla cieca quando si verifica un incidente. Inizia con un server, una dashboard e pochi avvisi a cui le persone possano effettivamente rispondere. Da lì, il servizio torna a funzionare senza intoppi.

Andres Saar, ingegnere dell'assistenza clienti