Grafana: Dashboard, Pannelli, Datasource e Alerting — Guida Operativa per il Monitoraggio in Produzione

Hai un'applicazione in produzione, i log arrivano a Prometheus o InfluxDB, ma quando apri Grafana vedi una dashboard vuota e non sai da dove iniziare. Oppure hai già qualche pannello ma gli alert non partono mai, o peggio, partono a caso nel cuore della notte. Ti è capitato? A noi sì, e più di una volta.

Noi, di Meteora Web, lavoriamo con il monitoraggio dal 2017: server, applicazioni, e-commerce, tutto passa per una dashboard fatta bene. E abbiamo visto che il 90% delle installazioni Grafana è sottoutilizzato: si configura una sorgente dati, si piazza un grafico a caso e via. Ma Grafana è molto di più. In questa guida vediamo come impostare datasource in modo solido, costruire pannelli che dicono qualcosa (non solo linee colorate), e configurare alerting che funziona davvero — senza falso allarmi.

Questa è una guida operativa. Prendi un terminale, apri Grafana, e seguici. Partiamo.

Perché Grafana? E perché ti serve una strategia, non solo un grafico

Grafana è il frontend universale delle tue metriche. Non importa se usi Prometheus, InfluxDB, MySQL, Elasticsearch o CloudWatch: un pannello ben costruito trasforma numeri grezzi in decisioni. Ma se non capisci come funzionano i datasource e le query, ottieni solo rumore.

Noi partiamo sempre da una domanda: “Qual è il sintomo che voglio vedere?”. Latenza alta? Errori HTTP? Carico CPU? La risposta decide che tipo di datasource e che pannello usare. E ricordati: una dashboard senza alerting è un cruscotto senza airbag. Quando il server cade, non hai tempo di guardare i grafici.

Datasource: connettere i dati a Grafana

Grafana parla con le tue fonti tramite datasource plugins. I più comuni: Prometheus, InfluxDB, Loki (per log), MySQL/PostgreSQL, e Elasticsearch. Ogni datasource ha la sua sintassi di query. Qui vediamo i due che usiamo di più in produzione: Prometheus e InfluxDB.

Configurare un datasource Prometheus

Supponiamo che Prometheus sia già in esecuzione su http://prometheus.internal:9090. In Grafana:

1. Vai a Configuration > Data Sources > Add data source.
2. Scegli Prometheus.
3. In URL inserisci l’endpoint: http://prometheus.internal:9090.
4. Abilita Access = Server (default) se Grafana può raggiungere Prometheus.
5. Lascia Scrape interval = 15s (o come configurato in Prometheus).
6. Clicca Save & Test — dovresti vedere un messaggio verde.

Attenzione agli errori comuni: se Grafana e Prometheus sono su macchine diverse, verifica i firewall. E non usare mai localhost se Grafana è in container e Prometheus sull’host. Noi abbiamo risolto casi in cui il client usava http://localhost:9090 dal container — non funziona mai.

Configurare un datasource InfluxDB (Flux)

InfluxDB 2.x usa il linguaggio Flux. Ecco una configurazione base:

URL: http://influxdb.internal:8086
Organization: miaorg
Token: il-tuo-token-di-amministrazione
Default Bucket: metriche-app

Poi in Query Language scegli Flux. Testa la connessione. Se vuoi usare InfluxQL (vecchio), devi attivare il mapping in InfluxDB. Noi preferiamo Flux perché è più potente per aggregazioni temporali.

Errore comune: timeout sulle query

Con dataset grandi (milioni di serie temporali), Grafana può andare in timeout. Aumenta il timeout nel datasource (es. 60s) e ottimizza le query con step più larghi (es. [5m] invece di [15s] su intervalli lunghi).

Pannelli: trasformare metriche in decisioni

Ogni pannello in Grafana ha un tipo (Time series, Stat, Gauge, Table, Bar gauge, ecc.) e una query. Il tipo giusto dipende dal dato: una linea temporale per l’andamento, uno Stat per un valore singolo, una Gauge per una soglia.

Time series: il pane quotidiano del monitoraggio

Per la CPU media di un cluster:

avg(rate(node_cpu_seconds_total{mode!="idle"}[5m])) by (instance)

Configura il pannello: Visualization = Time series, Legend mostra {{instance}}. Aggiungi Thresholds: ad esempio una linea a 0.8 (80%) che diventa arancione. Con il nuovo pannello Time series puoi anche aggiungere Transformations per calcolare medie mobili.

Consiglio operativo: non mettere tutti i grafici su un unico pannello con molte serie. Usa Repeated panels con la variabile $instance per avere un pannello per host. Lo vediamo spesso nei progetti: un solo grafico con 50 linee illeggibili. Noi facciamo sempre così: una riga per host, sezione per sezione.

Stat: il numero che conta

Per mostrare il numero di richieste HTTP 5xx nell’ultima ora:

sum(increase(http_requests_total{status=~"5.."}[1h]))

Visualizzazione: Stat. Color mode = background, Thresholds: base verde, sopra 10 arancione, sopra 50 rosso. Aggiungi Sparkline per vedere l’andamento senza occupare spazio.

Gauge: la velocità a colpo d’occhio

Per la percentuale di utilizzo disco:

100 - (avg(node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"}) * 100)

Pannello Gauge, Max = 100, Thresholds: 0-80 verde, 80-95 giallo, 95-100 rosso.

Table: i dettagli granulari

Per mostrate gli endpoint con più errori:

topk(10, sum by (handler) (rate(http_requests_total{status=~"5.."}[5m])))

Pannello Table, ordina per valore decrescente. Aggiungi Cell display mode per colorare le celle.

Alerting: non farti svegliare inutilmente

Il sistema di alerting di Grafana (unified alerting) ti permette di creare regole basate su query, con severità, notifiche e silenzi. È potente, ma va configurato con cura. Tre principi:

• Validazione prima di allertare: usa for per evitare falsi positivi (es. 5 minuti di persistenza).
• Segnala sintomi, non cause: allerta su latenza 95° percentile alta, non su “carico CPU” (che può essere normale).
• Routing intelligente: notifiche via email per criticità, Slack per warning, Telegram per info.

Creare una regola di alerting in Grafana (PromQL)

Supponiamo di volere un alert quando la latenza media delle richieste supera 500ms per più di 5 minuti.

1. Vai a Alerting > Alert rules > New alert rule.
2. Rule name: Latenza API alta.
3. Seleziona un datasource Prometheus e scrivi la query:

avg(rate(http_request_duration_seconds_sum[5m]) / rate(http_request_duration_seconds_count[5m])) > 0.5

4. Condition: A (query) > 0.5 (valore).
5. For: 5m (aspetta 5 minuti di persistenza).
6. Severity: Critical.
7. Notifications: Scegli un canale (già configurato in Contact points).
8. Clicca Save.

Errore comune: dimenticare il for porta a alert che partono con un singolo spike e subito si risolvono — inutili e rumorosi. Noi impostiamo sempre almeno 3-5 minuti per metriche non critiche, 1 minuto per criticità immediate (es. server down).

Configurare notifiche via Slack

1. Vai a Alerting > Contact points > Add contact point.
2. Tipo: Slack.
3. Inserisci il Webhook URL (da Slack: Apps > Incoming Webhooks).
4. Template: puoi personalizzare il messaggio. Esempio:

{
  "text": "{{ .Message }}\n{{ range .Alerts }}\n{{ .Annotations.summary }}\n{{ end }}"
}

5. Configura Notification policies per instradare le regole al contact point giusto.

Best practice per dashboard efficaci

Dopo anni a costruire dashboard per clienti (e per noi), abbiamo una checklist:

• Una dashboard per scopo: infrastruttura, applicazione, business. Non mischiare.
• Variabili: usa $env, $instance, $datacenter per filtrare senza duplicare pannelli.
• Ordine logico: dall’alto verso il basso — riepilogo (stat/overview), dettagli (time series), tabelle.
• Template JSON: esporta la dashboard come JSON e versionala in Git. Noi lo facciamo con un repository monitoring/grafana-dashboards.
• Librerie pubbliche: usa le dashboard ufficiali di Grafana Labs per Prometheus Node Exporter o Redis. Poi personalizzale.

In sintesi — cosa fare adesso

1. Controlla i tuoi datasource: verifica che Grafana possa raggiungere Prometheus/InfluxDB. Se hai timeout, aumenta il timeout o riduci la granularità della query.
2. Sostituisci i pannelli inutili con quelli giusti: usa Stat per KPI, Time series per trend, Gauge per soglie.
3. Configura almeno una regola di alerting con for e una notifica via Slack o email. Inizia da qualcosa di semplice: uptime di un servizio.
4. Costruisci una dashboard con variabili per ambiente e host. Esportala in JSON e mettila sotto controllo versione.
5. Leggi la documentazione ufficiale di Grafana Alerting per approfondire silenzi e silenziamenti: Grafana Alerting Docs.

E se vuoi vedere come integriamo Grafana in un’architettura completa di monitoring e observability, dai un’occhiata alla nostra guida pillar sul monitoring.