Grafana non è un sostituto di Looker Studio: è uno strumento nato per un problema diverso. Looker Studio eccelle con i report business da presentare agli stakeholder — colleghi, finanziatori, team marketing. Grafana è lo strato di visualizzazione per dati tecnici in tempo reale: metriche IoT, serie temporali da sensori, monitoring di applicazioni e infrastrutture. La differenza non è estetica — è strutturale. E capirla è il primo passo per usarli entrambi bene. Quinta puntata del percorso Stack Digitale 2026.
Immagina di avere 50 stazioni meteo che trasmettono temperatura, umidità e qualità dell’aria ogni cinque minuti. In un giorno produci 720 misurazioni per stazione — 36.000 data point complessivi. In un mese, oltre un milione. Looker Studio può tecnicamente visualizzarli. Ma non è progettato per questo: ogni refresh ricalcola tutto, le query aggregate su milioni di righe diventano lente, e il sistema di alerting — avvisami quando la temperatura supera 40°C — semplicemente non esiste.
Grafana è progettato esattamente per questo scenario. E non solo per l’IoT — ma per qualsiasi sistema che produce dati continui nel tempo: metriche applicative, log di sistema, dati finanziari tick-by-tick, monitoring di pipeline dati. Il caso d’uso del corso Advanced Data Modeling del Politecnico — Smart City con dati ARPA Piemonte, Kafka come ingestion layer, InfluxDB come storage — ha Grafana come strato finale di visualizzazione per una ragione precisa.
Come funziona Grafana: il modello datasource + panel
L’architettura di Grafana si basa su due concetti. I datasource sono le connessioni alle fonti dati — Grafana non archivia nulla, interroga sempre il database sorgente al momento del refresh. I panel sono i singoli widget visuali che compongono una dashboard: grafici a linea, stat panel numerici, mappe, tabelle, gauge, heatmap. Ogni panel ha la propria query indipendente verso il datasource configurato.
Questo design è fondamentale per capire il valore reale dello strumento. I dati restano dove sono — in InfluxDB, PostgreSQL, Elasticsearch, Prometheus. Grafana è il layer di lettura e presentazione. Puoi avere la stessa metrica visualizzata in tre panel diversi con tre scale temporali diverse, tre tipi di grafico diversi, per tre audience diverse — senza duplicare un singolo byte di storage.
Grafana Cloud Free: operativo in due minuti
Grafana ha due modalità di deployment: self-hosted (open source, installazione locale) e Grafana Cloud. Per iniziare — e per l’articolo precedente sulle immagini — il piano Cloud Free è sufficiente: include 10.000 metriche Prometheus, 50 GB di log, 50 GB di trace, alerting completo e accesso ai dashboard demo preinstallati. Nessuna carta di credito, nessuna installazione. Si registra su grafana.com con Google, l’istanza è attiva in due minuti con sample data già pronti da esplorare.
Connessioni: si collega a tutto lo stack dati moderno
Qui Grafana mostra la sua vera flessibilità. La schermata qui sotto è la pagina Connections → Add new connection dell’interfaccia Cloud. I datasource più popolari in cima parlano chiaro: Linux Server, Prometheus, InfluxDB, MySQL, Elasticsearch, Synthetic Monitoring. Più in basso: Kubernetes Monitoring, OpenTelemetry, AWS CloudWatch, Docker.
La sezione “Infinity for JSON” merita una menzione a parte: permette di connettere qualsiasi API REST o endpoint JSON come datasource, senza scrivere codice. Se hai un’API che restituisce dati in JSON — un CRM, un sistema gestionale, un feed di dati esterno — puoi visualizzarli in Grafana direttamente. L’icona AI Ask Assistant in alto aiuta a scegliere il connettore giusto in base alla descrizione del caso d’uso.
Creare un panel: dal datasource al grafico in 4 step
L’immagine qui sotto mostra il panel editor di Grafana aperto sul panel “Temperature” del dashboard Weather Demo. È l’interfaccia che usi ogni volta che crei o modifichi un panel — ed è utile capirne la struttura prima di usarla per la prima volta.
In alto: l’anteprima del grafico in tempo reale — ogni modifica alla query si riflette immediatamente senza salvare. A sinistra: tre tab — Queries (le query verso il datasource), Transformations (operazioni sui dati prima della visualizzazione: join, filtri, rinomina colonne), Alert (soglie di alerting per questo specifico panel). A destra: il pannello delle opzioni — tipo di visualizzazione (Time series, con il pulsante Change per passare a bar chart, gauge, stat, tabella), titolo, stili predefiniti.
La query PromQL visibile nell’editor
Il datasource configurato è Prometheus (${DS_PROMETHEUS}), e la query nella riga A è:
avg(weather_temp_c{job="weather-service", location=~"$location"}) by (location). È una query PromQL che: seleziona la metrica weather_temp_c dal job weather-service, filtra per location usando la variabile dashboard $location (quella che vedi nel filtro “London” in alto), calcola la media per ogni location distinta. Il risultato è esattamente la linea gialla del grafico — temperatura media di Londra negli ultimi 7 giorni, granularità 15 minuti.
Non è necessario conoscere PromQL per usare Grafana — il tab Builder accanto a Code costruisce la query visualmente, con menu a tendina per metric, label filter e operazioni. PromQL diventa rilevante quando hai bisogno di query più specifiche che il builder non copre direttamente.
Alerting: la funzione che Looker Studio non ha
Questa è la differenza operativa più importante tra Grafana e qualsiasi tool di business intelligence classico. Grafana ha un sistema di alerting nativo, completo e configurabile — non un add-on, non un’integrazione esterna. Tu definisci le condizioni, Grafana monitora in background e ti notifica via email, Slack, webhook, PagerDuty, Telegram o qualsiasi altro canale quando una soglia viene superata.
La schermata qui sotto mostra la pagina di creazione di una nuova alert rule: step 1 per il nome, step 2 per la query e la condizione di alert. Il builder è identico a quello dei panel — selezioni datasource, costruisci la query, poi definisci la condizione: WHEN QUERY IS ABOVE [valore]. Il pulsante “Preview alert rule condition” esegue la query sullo storico e mostra se la condizione sarebbe scattata nelle ore precedenti — utilissimo per calibrare le soglie prima di attivare l’alert.
Casi d’uso pratici dell’alerting
Nel progetto Smart City del corso Poli: notifica al team operativo quando PM10 supera i 50 µg/m³ (soglia OMS per qualità dell’aria) su almeno tre stazioni consecutive. Nel monitoring applicativo: alert se il tempo di risposta medio dell’API sale sopra 500ms per più di 5 minuti consecutivi. Nel progetto IoT Smart Agriculture: notifica automatica quando l’umidità del suolo scende sotto la soglia di irrigazione in una specifica zona del campo.
Nessuno di questi scenari è gestibile con Looker Studio — che è uno strumento di visualizzazione passiva, non di monitoring attivo. È la stessa differenza tra guardare un grafico quando vuoi e ricevere una telefonata quando qualcosa va storto.
Grafana vs Looker Studio: la bussola per scegliere
La domanda non è quale dei due sia migliore — è quale sia più adatto al tuo caso. Looker Studio è la scelta corretta quando il tuo dataset principale viene da Google Sheets, Google Analytics o Google Ads; quando il pubblico è non tecnico (stakeholder, finanziatori, management) e il formato è un report statico da presentare; quando hai bisogno di zero configurazione e zero costi senza possibilità di autenticazione e datasource custom.
Grafana è la scelta corretta quando i dati arrivano in tempo reale da sensori, API o sistemi applicativi; quando hai bisogno di alerting proattivo su soglie; quando il datasource è InfluxDB, Prometheus, Elasticsearch o qualsiasi database non-Google; quando il team che consuma la dashboard ha background tecnico e ha bisogno di drill-down e query interattive.
In molte architetture reali i due strumenti coesistono: Grafana per il monitoring operativo e tecnico, Looker Studio per i report ai finanziatori. Il prossimo articolo del percorso introduce un terzo layer: la tecnica RAG, che porta l’AI conversazionale sopra questi dati — permettendo di interrogare documenti e database in linguaggio naturale, senza scrivere query SQL o PromQL. Il monitoring diventa dialogo.
