Microservizi observability per PMI 2022: stack Prometheus, Grafana, Loki e Tempo

Quando un ordine si blocca a metà del checkout, quando le notifiche push arrivano in ritardo di trenta minuti, quando il gestionale segna “errore” senza un perché umanamente leggibile, la PMI italiana che ha abbracciato i microservizi si trova in una situazione che gli SRE chiamano “volo cieco”. Tu sai che qualcosa non funziona, lo sanno i clienti, lo sa il commerciale che ti chiama alle 18:45, ma nessuno sa dove guardare. In un monolite PHP degli anni Duemila il problema era semplice: c’era un file di log, ci si collegava in SSH, si faceva tail e si trovava la stack trace. In un’architettura distribuita con dieci, venti o cento servizi che parlano tra loro via REST o gRPC, la stessa transazione utente attraversa cinque-sette container in dieci secondi e l’errore può nascondersi in qualunque punto della catena.

L’observability non è una buzzword da consulenti. È la disciplina che permette di rispondere alla domanda “perché il sistema si comporta così?” senza dover deployare codice nuovo o aggiungere log custom. Per una PMI italiana che nel 2022 ha completato la migrazione a Kubernetes o ha spinto il proprio prodotto SaaS su AWS/GCP/Azure, costruire uno stack observability open source intorno a Prometheus, Grafana, Loki e Tempo è la differenza tra notti tranquille e turni di reperibilità infiniti. In questa guida vediamo come progettarlo, quanto costa davvero e quali errori evitare nei primi novanta giorni.

I tre pilastri dell’observability: metrics, logs, traces

Nel 2018 Cindy Sridharan ha pubblicato il saggio fondativo “Distributed Systems Observability” e da allora i tre pilastri sono entrati nel vocabolario comune. Le metriche sono numeri aggregati nel tempo (richieste al secondo, errori HTTP 500, RAM consumata): bassa cardinalità, costo storage contenuto, perfette per dashboard real-time e alert. I log sono eventi discreti con testo (eccezioni, audit, payload JSON): ad alta cardinalità e storicamente costosi da indicizzare. Le tracce rappresentano una singola richiesta che attraversa più servizi: ogni hop è uno “span” con timing, parent ID e metadata, e rispondono alla domanda “dove ha speso tempo questa richiesta?”.

Nessuno dei tre pilastri basta da solo. Le metriche dicono che latenza è cresciuta, le tracce quale servizio ha causato il rallentamento, i log cosa è andato storto in quel servizio. La correlazione tra i tre — possibile solo condividendo trace ID via exemplars e injection — è quello che trasforma un sistema “monitorato” in un sistema “osservabile”.

I quattro segnali oro di Google SRE

Il libro Site Reliability Engineering di Google (O’Reilly, 2016) ha cristallizzato i “four golden signals” che ogni servizio dovrebbe esporre: latency (tempo di risposta separato tra successo ed errore), traffic (richieste al secondo o connessioni attive), errors (tasso di fallimento) e saturation (quanto è “pieno” il servizio rispetto alla capacità). Per la PMI che parte da zero, questo è il minimo sindacale: se ogni microservizio espone questi quattro segnali su un endpoint /metrics in formato Prometheus, sei già al 60% della copertura observability.

Tom Wilkie nel 2015 ha proposto un derivato pragmatico chiamato RED method: Rate, Errors, Duration. Si applica a qualunque servizio request-driven (HTTP API, gRPC, gestionale). Brendan Gregg in parallelo ha proposto il USE method per risorse hardware: Utilization, Saturation, Errors. La regola pratica è: RED per i tuoi servizi applicativi, USE per nodi/container/dischi. Insieme coprono il 95% dei casi d’uso di una PMI con cinque-cinquanta servizi in produzione.

Prometheus: la spina dorsale delle metriche

Prometheus, originariamente sviluppato in SoundCloud e diventato secondo progetto CNCF “graduated” nel 2018 (dopo Kubernetes), è di fatto lo standard de facto per le metriche cloud-native. La versione 2.36 di maggio 2022 ha portato miglioramenti alle query histogram e al supporto exemplars. Il modello è pull-based: Prometheus interroga periodicamente (default 15s) gli endpoint /metrics dei tuoi servizi. Questo approccio capovolge l’abitudine del push (StatsD, Graphite) con vantaggi precisi: service discovery semplice via Kubernetes API o Consul, pressione di rete prevedibile, blackbox monitoring automatico se un endpoint non risponde.

Il linguaggio di query PromQL è la prima cosa che ogni SRE deve imparare: aggregazioni temporali, rate sui counter, percentili sulle histogram, joins tra serie. Una query per il p95 di latenza HTTP raggruppata per endpoint occupa due righe ma sostituisce minuti di shell scripting. Gli exemplars (Prometheus 2.26+) permettono di agganciare un trace ID a un punto della metrica, abilitando il click-through “ho un picco di latenza qui, mostrami una trace di esempio”.

Per carichi tipici di una PMI italiana — 10-50 servizi con 1.000-5.000 metriche ciascuno — un singolo nodo Prometheus da 4 vCPU/16GB RAM regge con retention di 15-30 giorni. Quando la retention deve allungarsi a mesi o anni, entrano in gioco i sistemi long-term: Thanos (2018), Cortex e Grafana Mimir, presentato in preview a marzo 2022 e arrivato GA proprio a giugno. Mimir è il fork “rebranded” di Cortex da parte di Grafana Labs, ottimizzato per miliardi di serie. Per la PMI tipo, Thanos resta la scelta più collaudata; Mimir è la novità da tenere d’occhio.

L’ecosistema di exporters è il vero superpotere di Prometheus. node_exporter per CPU/RAM/disco/rete, exporter ufficiali o community per Postgres, MySQL, Redis, RabbitMQ, Kafka, Nginx; kube-state-metrics per lo stato dei pod, cAdvisor per le metriche per-container, blackbox_exporter per probe HTTP/TCP/ICMP. Il Pushgateway è la pezza per job batch effimeri — usalo solo quando serve, non come pattern generale.

Grafana: il pannello di controllo unificato

Grafana è il front-end visivo dello stack. Nel 2022 siamo arrivati alla versione 8.x stabile, con la 9.0 in beta avanzata (rilascio previsto a luglio). Quattro funzionalità contano per una PMI: il supporto nativo a più datasource (una stessa dashboard mescola Prometheus, Loki, Tempo, MySQL, CloudWatch, Elasticsearch); l’alerting unificato introdotto in Grafana 8 con regole multi-datasource, escalation, silenzi e integrazioni Slack/Teams/PagerDuty/Opsgenie/email; il RBAC per separare dashboard sviluppo/staging/produzione; il provisioning as code di dashboard, datasource e alert rules in file YAML/JSON versionabili in Git.

Il consiglio operativo: non disperderti su decine di dashboard custom dal giorno uno. Parti dalle dashboard ufficiali community su grafana.com (Node Exporter, Kubernetes, JVM, MySQL, Postgres, Nginx) e personalizzale solo dove serve. Dedica invece tempo a costruire 3-5 dashboard “service-oriented” con RED method per ciascun servizio critico. Sono quelle che il team userà ogni giorno.

Grafana Loki: log aggregation senza l’indice gigante

Loki, presentato nel 2018 e arrivato a giugno 2022 alla versione 2.5, è la risposta di Grafana Labs alla scala di Elasticsearch per i log. La filosofia è opposta a ELK Stack: Loki non indicizza il contenuto dei log, indicizza solo i label di metadata (servizio, ambiente, livello, namespace). Il payload viene compresso in chunk e salvato su object storage economico (S3, GCS, Azure Blob, MinIO). Una pipeline log da 100GB/giorno costa su Loki circa un decimo di una soluzione Elastic equivalente, con operatività molto più semplice.

Il prezzo da pagare è che le query “full-text” su miliardi di righe sono più lente di Elasticsearch — ma le query log che servono davvero a un team SRE sono sempre filtrate per servizio e finestra temporale. LogQL, volutamente simile a PromQL: {service="payment", level="error"} |= "timeout" filtra per label e poi cerca la stringa, con anche aggregazioni numeriche graficabili come metriche.

L’ingestion avviene tipicamente via Promtail, l’agent ufficiale che gira come DaemonSet su Kubernetes e tagga ogni log con i metadata del pod. Alternative: OpenTelemetry Collector e Fluent Bit hanno exporter Loki nativi. Importante: Loki impone limiti severi sulla cardinalità dei label — niente user_id o trace_id come label, vanno nel contenuto. La retention si gestisce con il compactor; tipicamente 30 giorni di “caldo” bastano.

Grafana Tempo: distributed tracing senza sampling aggressivo

Tempo, arrivato alla versione 1.4 ad aprile 2022, completa il terzetto di backend Grafana. È un sistema di distributed tracing che, come Loki per i log, non indicizza i contenuti: le tracce vengono salvate su object storage e referenziate via trace ID. Il vantaggio è che puoi fare 100% sampling (salvare ogni traccia, non solo l’1%) senza far esplodere i costi, perché lo storage S3/MinIO/GCS è economicissimo per dati immutabili compressi.

Tempo accetta tracce nei tre formati standard del settore: OpenTelemetry (OTLP, formato preferito 2022 in avanti), Jaeger (Thrift e gRPC, lo standard CNCF graduated del 2019) e Zipkin (lo storico di Twitter del 2012). Questo significa che se hai già strumentato i servizi con Jaeger SDK puoi ricevere quelle tracce in Tempo senza riscrivere codice. La pratica più sensata nel 2022 è però migrare progressivamente a OpenTelemetry SDK perché è lo standard che vincerà — sia Jaeger che Zipkin sono in fase di “feature freeze” a favore di OTel.

La feature killer di Tempo è l’integrazione bidirezionale con metriche e log dentro Grafana. Dal pannello metrica, click su un exemplar → la traccia completa si apre in un nuovo tab. Dal pannello log, click su un trace ID estratto via regex → si apre la traccia. Dalla traccia, click su uno span → si filtrano i log del servizio in quella finestra temporale di 200ms. Questa correlazione “ad hoc” è la differenza pratica tra investigare un incident in 5 minuti o in 50 minuti. Una capability che nel 2022 è ancora rara nei tool SaaS commerciali a metà fascia, ma che con lo stack Grafana è gratis.

OpenTelemetry: strumenta una volta, esporta dove vuoi

OpenTelemetry (OTel) è il progetto CNCF nato dalla fusione di OpenTracing e OpenCensus, in stato “incubating”. A febbraio 2022 le specifiche trace sono state dichiarate stable v1.0; le metriche arriveranno stable a fine 2022, i log sono ancora in beta. OTel risolve il vendor lock-in della strumentazione: storicamente, se sceglievi Datadog dovevi mettere il loro SDK; passare a New Relic significava rifare tutto. Con OTel strumenti una volta sola in formato OTLP, e il backend (Tempo, Jaeger, Datadog, Honeycomb, Lightstep) lo cambi spostando una linea di config nell’OpenTelemetry Collector.

L’OTel Collector (versioni 0.50+ nel 2022) riceve dati telemetry da tutti i servizi, applica trasformazioni (batching, sampling, redazione PII, arricchimento metadata) e li esporta verso uno o più backend. È un binario Go single-process, leggero, configurabile via YAML, deployabile come sidecar o DaemonSet. La auto-instrumentation è la feature che fa risparmiare settimane: per Java basta -javaagent:opentelemetry-javaagent.jar al startup della JVM e ottieni tracce automatiche di Spring, JDBC, Kafka client, gRPC senza toccare il codice. Auto-instrumentation simili per Python, Node.js, .NET. Per Go la strumentazione resta manuale (no agent runtime) ma le librerie ufficiali coprono net/http, gRPC, gorm, redis. La regola del pollice: parti da auto, aggiungi span custom solo dove il dominio applicativo lo richiede.

Quanto costa davvero lo stack OSS contro i SaaS

Numeri concreti per una PMI italiana tipo, con 20 microservizi, 5 nodi Kubernetes, 500 GB/mese di log, 5 milioni di tracce/mese. Self-hosted su AWS: 3 nodi t3.large per Prometheus+Loki+Tempo (~€250/mese), bucket S3 per log e tracce (~€80/mese), storage per Mimir long-term (~€100/mese), ALB e traffico (~€50/mese). Totale infrastruttura: €500-700/mese. Aggiungi 1 SRE part-time (30% di un FTE da €50k lordi annui) = €1.250/mese di tempo umano. Costo annuale all-in: €20-25k. Grafana Cloud (SaaS gestita dello stesso stack): piano Pro da €49 a €549/mese, tipicamente €300-500/mese per la fascia PMI.

Sul fronte commerciale, Datadog (Pro $15/host + APM $31/host + Logs $1.27/GB) per 5 nodi K8s con 20 servizi diventa spesso $4.000-6.000/mese, cioè $50-80k/anno. New Relic, con modello data-based ($0.30/GB), si attesta su $35-55k/anno per volumi PMI. Dynatrace ($25-65/host) arriva a $60-150k/anno. Splunk Cloud: pricing custom, da $80-200k/anno per 500GB/mese di log. La domanda non è “OSS o SaaS?” in assoluto, è “ho competenze SRE interne?” e “il TCO a 3 anni quale soluzione minimizza?”. Sotto i 30 sviluppatori e 5 nodi K8s, Grafana Cloud è spesso la scelta più razionale; sopra quella soglia, self-hosted ripaga in 12-18 mesi.

Correlation in pratica: exemplars, trace ID e structured logging

Avere tre backend separati per metriche, log e tracce ha senso solo se i dati si parlano. La correlazione concreta richiede tre disciplina operative. Primo, ogni log deve essere structured (JSON) e deve contenere trace_id e span_id quando emesso dentro un span attivo. OTel SDK iniettano automaticamente i correlation ID nel MDC (Mapped Diagnostic Context) di Logback per Java, in contextvars per Python, in AsyncLocalStorage per Node.js. Secondo, ogni metric Prometheus che misura durata di operazioni deve esporre exemplars: il client library (Java, Go, Python) lo fa automaticamente se il trace context è attivo. Terzo, Grafana va configurato con le data link tra i tre datasource: nella config del datasource Tempo aggiungi un link “Logs to Loki”, in Loki aggiungi un link “Trace to Tempo” che estrae trace_id dal JSON.

Risultato pratico: cinque click per andare da un alert di latenza degradata a un esempio di traccia lenta, ai log del servizio coinvolto in quei 230 millisecondi. Senza correlation, lo stesso percorso richiede 30 minuti di shell e ipotesi. Con correlation, è la differenza tra un MTTR (Mean Time To Resolution) di 5 minuti e uno di 50.

SLO, SLI, error budget: il linguaggio del management

Una dashboard tecnica con cento grafici non parla la lingua dell’amministratore delegato. Gli SLO (Service Level Objectives) sì. Un SLO è un obiettivo misurabile sul comportamento di un servizio dal punto di vista dell’utente. Esempio: “il 99.5% delle richieste API risponde sotto 300ms in un periodo di 30 giorni”. Lo SLI (Service Level Indicator) è la metrica concreta che misuri per verificare l’SLO. Lo SLA (Service Level Agreement) è il contratto commerciale, tipicamente più conservativo dell’SLO interno.

L’error budget è la conseguenza pratica: se prometti il 99.5% di successo, il restante 0.5% è il “budget” che puoi bruciare in incident, deployment rischiosi, esperimenti. Quando il budget si esaurisce prima della fine del periodo, congeli i deployment e mandi tutti a debuggare la stabilità. Questo framework, codificato da Google SRE, è il modo più efficace di portare la discussione tecnica al tavolo della direzione senza traduzioni. Per implementarli con Prometheus, le librerie di riferimento sono sloth e pyrra, che generano regole di recording PromQL e Alertmanager a partire da definizioni YAML dichiarative. Per una PMI che parte: definisci SLO solo sui 3-5 servizi business-critical, non su tutto.

Errori comuni nei primi 90 giorni e come evitarli

Dashboard sprawl: ogni team crea le sue venti dashboard, nessuno le mantiene, sei mesi dopo nessuno le guarda. Definisci una “shelf” di dashboard ufficiali (10-15 max) governate dal team di piattaforma, il resto va in cartella “experimental” senza alert.

Esplosione cardinalità dei label: mettere user_id, request_id o URL non normalizzati come label Prometheus o Loki fa esplodere costi e tempi di query. Regola: i label sono per dimensioni con cardinalità sotto 1.000 (servizio, ambiente, metodo HTTP, regione). Tutto il resto va nel contenuto della metrica.

Alert fatigue: troppi alert, tutti “warning”, tutti ignorati. Alert solo su sintomi user-facing (SLO burn rate, error rate, latenza p99), non su cause (CPU 80%). Per ogni alert deve esistere un runbook di tre passi in Markdown linkato dall’annotazione Alertmanager.

Nessun tracing: si parte con metriche e log, “il tracing lo facciamo dopo” — il dopo non arriva mai. Investigare incidenti distribuiti diventa archeologia. Il tracing va nello stack dal giorno 30, non dal giorno 300. Con OTel auto-instrumentation il costo iniziale è bassissimo.

Nessuna ownership: l’observability è “del team DevOps”, nessun product team la usa. Antidoto: la dashboard RED del servizio è responsabilità del team che possiede il servizio; la piattaforma observability è responsabilità di un team dedicato (anche solo 1-2 SRE in una PMI).

Team e competenze: quanti SRE servono davvero

La buona notizia: per una PMI italiana con 15-30 sviluppatori e 20-50 servizi, 1-2 SRE/Platform Engineer sono sufficienti per costruire e mantenere lo stack Grafana. Il profilo richiesto è ibrido: 40% sysadmin Linux/Kubernetes, 30% sviluppo (Go o Python preferibilmente), 20% data analysis e PromQL, 10% facilitatore culturale verso i team di sviluppo. Senior con esperienza specifica costa €55-75k lordi in Italia nel 2022; mid-level con buona formazione interna €40-55k.

L’alternativa “tutti devono saperlo fare” non funziona: senza una persona dedicata a curare la piattaforma, le metriche restano scollegate, gli alert si rompono ad ogni refactor, le dashboard invecchiano. La cattiva notizia è che il mercato è scarso: SRE con esperienza Kubernetes/Prometheus/OTel è un profilo cercato e in fuga verso aziende prodotto e remote-first internazionali. Investire in formazione interna di developer senior verso il ruolo SRE è spesso più realistico di assumere dall’esterno.

Roadmap 90 giorni: cosa fare settimana per settimana

Settimane 1-2: foundation. Deploy Prometheus + Grafana su un namespace Kubernetes dedicato (chart Helm kube-prometheus-stack di prometheus-community installa tutto in 15 minuti). Configura node_exporter, kube-state-metrics, cAdvisor. Importa le dashboard community di Kubernetes/Nodes da grafana.com. Risultato: visibilità sull’infrastruttura.

Settimane 3-4: metriche applicative. Aggiungi endpoint /metrics ai primi 3-5 servizi critici. Per Spring Boot è una dipendenza, per Express un middleware, per Flask un decorator. Costruisci una dashboard “Service Overview” con RED method. Definisci i primi 5 alert (error rate > 1%, latenza p99 > soglia, pod restart loop).

Settimane 5-6: log centralizzati. Deploy Loki + Promtail (chart Helm loki-stack). Configura retention 30 giorni su S3/MinIO. Aggiungi un pannello “Recent Errors” a ogni dashboard di servizio che filtra level=error negli ultimi 15 minuti.

Settimane 7-8: tracing distribuito. Deploy Tempo. Aggiungi OTel auto-instrumentation ai servizi (1 riga di config per JVM, agent CLI per Python/Node). Configura OTel Collector come DaemonSet che riceve OTLP e esporta verso Tempo. Verifica data link Grafana metriche ↔ tracce ↔ log.

Settimane 9-10: alerting maturo. Migra a Grafana Unified Alerting. Configura escalation Slack + PagerDuty (o Opsgenie). Scrivi i runbook per ogni alert critico in un repo Git linkato.

Settimane 11-12: SLO e cultura. Definisci 3-5 SLO sui servizi business-critical. Imposta burn rate alert. Presenta la dashboard SLO al management. Documenta il processo di on-call e di post-mortem blame-less. A questo punto, hai uno stack observability operativo e una cultura SRE in costruzione.

Tendenze 2022-2023 da tenere d’occhio

Tre fronti vale la pena monitorare. L’eBPF observability con progetti come Pixie (donato alla CNCF da New Relic) e Cilium Hubble permette di estrarre metriche di rete e applicative senza istruzione del codice, sfruttando il kernel Linux: per servizi legacy difficili da strumentare è una rivoluzione silenziosa. La maturazione di OTel logs — a giugno 2022 la specifica è ancora in beta — completerà entro 6-12 mesi il “single SDK” del telemetry. Sul fronte commerciale c’è consolidamento: Datadog aggiunge error tracking e RUM, New Relic ha aperto un modello data-based aggressivo, Honeycomb spinge su event-based tracing ad alta cardinalità, Lightstep è stata acquisita da ServiceNow nel 2021. Per la PMI questo significa più opzioni a costi calanti, ma anche più rumore commerciale. Il principio guida resta: scegli la piattaforma in base ai tuoi volumi e competenze a 3 anni, non al pitch di vendita di oggi.

Conclusione

L’observability open source nel 2022 non è più una scelta di nicchia per le big tech. Prometheus, Grafana, Loki e Tempo formano uno stack production-ready, supportato da una fondazione neutrale (CNCF), gratuito nel software e con costi infrastrutturali sostenibili anche per una PMI italiana. Il vero costo è il tempo umano: 1-2 SRE con buone competenze, una roadmap di 90 giorni disciplinata e un management che capisce la differenza tra “monitoring” (sapere che qualcosa è rotto) e “observability” (capire perché). Per le aziende che hanno scelto la via dei microservizi, l’observability non è un lusso da fase 2: è la condizione per cui i microservizi non diventino, paradossalmente, meno affidabili del monolite che hanno sostituito.