{"id":2021,"date":"2022-06-21T11:09:00","date_gmt":"2022-06-21T09:09:00","guid":{"rendered":"https:\/\/brentasoft.com\/blog\/microservizi-observability-prometheus-grafana-loki-pmi-2022\/"},"modified":"2022-06-21T11:09:00","modified_gmt":"2022-06-21T09:09:00","slug":"microservizi-observability-prometheus-grafana-loki-pmi-2022","status":"publish","type":"post","link":"https:\/\/brentasoft.com\/blog\/microservizi-observability-prometheus-grafana-loki-pmi-2022\/","title":{"rendered":"Microservizi observability per PMI 2022: stack Prometheus, Grafana, Loki e Tempo"},"content":{"rendered":"<p>Quando un ordine si blocca a met\u00e0 del checkout, quando le notifiche push arrivano in ritardo di trenta minuti, quando il gestionale segna &#8220;errore&#8221; senza un perch\u00e9 umanamente leggibile, la PMI italiana che ha abbracciato i microservizi si trova in una situazione che gli SRE chiamano &#8220;volo cieco&#8221;. Tu sai che qualcosa non funziona, lo sanno i clienti, lo sa il commerciale che ti chiama alle 18:45, ma nessuno sa <em>dove<\/em> guardare. In un monolite PHP degli anni Duemila il problema era semplice: c&#8217;era un file di log, ci si collegava in SSH, si faceva tail e si trovava la stack trace. In un&#8217;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&#8217;errore pu\u00f2 nascondersi in qualunque punto della catena.<\/p>\n<p>L&#8217;<strong>observability<\/strong> non \u00e8 una buzzword da consulenti. \u00c8 la disciplina che permette di rispondere alla domanda &#8220;perch\u00e9 il sistema si comporta cos\u00ec?&#8221; 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 \u00e8 la differenza tra notti tranquille e turni di reperibilit\u00e0 infiniti. In questa guida vediamo come progettarlo, quanto costa davvero e quali errori evitare nei primi novanta giorni.<\/p>\n<div style=\"background:#f0f9ff;border-left:4px solid #0284c7;padding:18px 22px;margin:28px 0;border-radius:6px;\">\n<p style=\"margin:0 0 8px 0;\"><strong>TL;DR<\/strong><\/p>\n<ul style=\"margin:0;padding-left:20px;\">\n<li>Observability significa tre pilastri: <strong>metrics<\/strong> (Prometheus), <strong>logs<\/strong> (Loki), <strong>traces<\/strong> (Tempo). Grafana li unifica.<\/li>\n<li>Stack OSS self-hosted costa \u20ac500-3.000\/mese in infrastruttura cloud + 1-2 SRE; SaaS equivalenti (Datadog, New Relic, Dynatrace) costano da $30.000 a $300.000\/anno per stesso volume.<\/li>\n<li>OpenTelemetry \u00e8 lo standard CNCF per strumentare il codice una volta sola e inviare dati a qualsiasi backend.<\/li>\n<li>Adotta i 4 segnali oro Google SRE (latenza, traffico, errori, saturazione) e il <strong>RED method<\/strong> (Rate\/Errors\/Duration) per ogni servizio.<\/li>\n<li>Roadmap pragmatica 90 giorni: metriche RED + dashboard Grafana \u2192 logs centralizzati \u2192 tracing distribuito \u2192 SLO e alerting.<\/li>\n<\/ul>\n<\/div>\n<h2>I tre pilastri dell&#8217;observability: metrics, logs, traces<\/h2>\n<p>Nel 2018 Cindy Sridharan ha pubblicato il saggio fondativo &#8220;Distributed Systems Observability&#8221; e da allora i tre pilastri sono entrati nel vocabolario comune. Le <strong>metriche<\/strong> sono numeri aggregati nel tempo (richieste al secondo, errori HTTP 500, RAM consumata): bassa cardinalit\u00e0, costo storage contenuto, perfette per dashboard real-time e alert. I <strong>log<\/strong> sono eventi discreti con testo (eccezioni, audit, payload JSON): ad alta cardinalit\u00e0 e storicamente costosi da indicizzare. Le <strong>tracce<\/strong> rappresentano una singola richiesta che attraversa pi\u00f9 servizi: ogni hop \u00e8 uno &#8220;span&#8221; con timing, parent ID e metadata, e rispondono alla domanda &#8220;dove ha speso tempo questa richiesta?&#8221;.<\/p>\n<p>Nessuno dei tre pilastri basta da solo. Le metriche dicono <em>che<\/em> latenza \u00e8 cresciuta, le tracce <em>quale servizio<\/em> ha causato il rallentamento, i log <em>cosa<\/em> \u00e8 andato storto in quel servizio. La correlazione tra i tre \u2014 possibile solo condividendo trace ID via exemplars e injection \u2014 \u00e8 quello che trasforma un sistema &#8220;monitorato&#8221; in un sistema &#8220;osservabile&#8221;.<\/p>\n<p><img decoding=\"async\" src=\"https:\/\/brentasoft.com\/blog\/wp-content\/uploads\/2026\/06\/observability_inline1.jpg\" alt=\"Sviluppatore al terminale che analizza metriche e log di osservabilit\u00e0\" style=\"width:100%;height:auto;border-radius:8px;margin:20px 0;\" \/><\/p>\n<h2>I quattro segnali oro di Google SRE<\/h2>\n<p>Il libro <em>Site Reliability Engineering<\/em> di Google (O&#8217;Reilly, 2016) ha cristallizzato i &#8220;four golden signals&#8221; che ogni servizio dovrebbe esporre: <strong>latency<\/strong> (tempo di risposta separato tra successo ed errore), <strong>traffic<\/strong> (richieste al secondo o connessioni attive), <strong>errors<\/strong> (tasso di fallimento) e <strong>saturation<\/strong> (quanto \u00e8 &#8220;pieno&#8221; il servizio rispetto alla capacit\u00e0). Per la PMI che parte da zero, questo \u00e8 il minimo sindacale: se ogni microservizio espone questi quattro segnali su un endpoint <code>\/metrics<\/code> in formato Prometheus, sei gi\u00e0 al 60% della copertura observability.<\/p>\n<p>Tom Wilkie nel 2015 ha proposto un derivato pragmatico chiamato <strong>RED method<\/strong>: Rate, Errors, Duration. Si applica a qualunque servizio request-driven (HTTP API, gRPC, gestionale). Brendan Gregg in parallelo ha proposto il <strong>USE method<\/strong> per risorse hardware: Utilization, Saturation, Errors. La regola pratica \u00e8: RED per i tuoi servizi applicativi, USE per nodi\/container\/dischi. Insieme coprono il 95% dei casi d&#8217;uso di una PMI con cinque-cinquanta servizi in produzione.<\/p>\n<h2>Prometheus: la spina dorsale delle metriche<\/h2>\n<p>Prometheus, originariamente sviluppato in SoundCloud e diventato secondo progetto CNCF &#8220;graduated&#8221; nel 2018 (dopo Kubernetes), \u00e8 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 \u00e8 <strong>pull-based<\/strong>: Prometheus interroga periodicamente (default 15s) gli endpoint <code>\/metrics<\/code> dei tuoi servizi. Questo approccio capovolge l&#8217;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.<\/p>\n<p>Il linguaggio di query <strong>PromQL<\/strong> \u00e8 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 <strong>exemplars<\/strong> (Prometheus 2.26+) permettono di agganciare un trace ID a un punto della metrica, abilitando il click-through &#8220;ho un picco di latenza qui, mostrami una trace di esempio&#8221;.<\/p>\n<p>Per carichi tipici di una PMI italiana \u2014 10-50 servizi con 1.000-5.000 metriche ciascuno \u2014 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: <strong>Thanos<\/strong> (2018), <strong>Cortex<\/strong> e <strong>Grafana Mimir<\/strong>, presentato in preview a marzo 2022 e arrivato GA proprio a giugno. Mimir \u00e8 il fork &#8220;rebranded&#8221; di Cortex da parte di Grafana Labs, ottimizzato per miliardi di serie. Per la PMI tipo, Thanos resta la scelta pi\u00f9 collaudata; Mimir \u00e8 la novit\u00e0 da tenere d&#8217;occhio.<\/p>\n<p>L&#8217;ecosistema di <strong>exporters<\/strong> \u00e8 il vero superpotere di Prometheus. <code>node_exporter<\/code> per CPU\/RAM\/disco\/rete, exporter ufficiali o community per Postgres, MySQL, Redis, RabbitMQ, Kafka, Nginx; <code>kube-state-metrics<\/code> per lo stato dei pod, <code>cAdvisor<\/code> per le metriche per-container, <code>blackbox_exporter<\/code> per probe HTTP\/TCP\/ICMP. Il <strong>Pushgateway<\/strong> \u00e8 la pezza per job batch effimeri \u2014 usalo solo quando serve, non come pattern generale.<\/p>\n<h2>Grafana: il pannello di controllo unificato<\/h2>\n<p>Grafana \u00e8 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\u00e0 contano per una PMI: il supporto nativo a <strong>pi\u00f9 datasource<\/strong> (una stessa dashboard mescola Prometheus, Loki, Tempo, MySQL, CloudWatch, Elasticsearch); l&#8217;<strong>alerting unificato<\/strong> introdotto in Grafana 8 con regole multi-datasource, escalation, silenzi e integrazioni Slack\/Teams\/PagerDuty\/Opsgenie\/email; il <strong>RBAC<\/strong> per separare dashboard sviluppo\/staging\/produzione; il <strong>provisioning as code<\/strong> di dashboard, datasource e alert rules in file YAML\/JSON versionabili in Git.<\/p>\n<p>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 <strong>3-5 dashboard &#8220;service-oriented&#8221;<\/strong> con RED method per ciascun servizio critico. Sono quelle che il team user\u00e0 ogni giorno.<\/p>\n<h2>Grafana Loki: log aggregation senza l&#8217;indice gigante<\/h2>\n<p>Loki, presentato nel 2018 e arrivato a giugno 2022 alla versione 2.5, \u00e8 la risposta di Grafana Labs alla scala di Elasticsearch per i log. La filosofia \u00e8 opposta a ELK Stack: Loki <strong>non indicizza il contenuto<\/strong> dei log, indicizza solo i <strong>label<\/strong> 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\u00e0 molto pi\u00f9 semplice.<\/p>\n<p>Il prezzo da pagare \u00e8 che le query &#8220;full-text&#8221; su miliardi di righe sono pi\u00f9 lente di Elasticsearch \u2014 ma le query log che servono davvero a un team SRE sono sempre filtrate per servizio e finestra temporale. LogQL, volutamente simile a PromQL: <code>{service=\"payment\", level=\"error\"} |= \"timeout\"<\/code> filtra per label e poi cerca la stringa, con anche aggregazioni numeriche graficabili come metriche.<\/p>\n<p>L&#8217;ingestion avviene tipicamente via <strong>Promtail<\/strong>, l&#8217;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\u00e0 dei label \u2014 niente user_id o trace_id come label, vanno nel contenuto. La retention si gestisce con il <strong>compactor<\/strong>; tipicamente 30 giorni di &#8220;caldo&#8221; bastano.<\/p>\n<p><img decoding=\"async\" src=\"https:\/\/brentasoft.com\/blog\/wp-content\/uploads\/2026\/06\/observability_inline2.jpg\" alt=\"Dashboard Grafana con grafici di metriche e analytics in tempo reale\" style=\"width:100%;height:auto;border-radius:8px;margin:20px 0;\" \/><\/p>\n<h2>Grafana Tempo: distributed tracing senza sampling aggressivo<\/h2>\n<p>Tempo, arrivato alla versione 1.4 ad aprile 2022, completa il terzetto di backend Grafana. \u00c8 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 \u00e8 che puoi fare <strong>100% sampling<\/strong> (salvare ogni traccia, non solo l&#8217;1%) senza far esplodere i costi, perch\u00e9 lo storage S3\/MinIO\/GCS \u00e8 economicissimo per dati immutabili compressi.<\/p>\n<p>Tempo accetta tracce nei tre formati standard del settore: <strong>OpenTelemetry<\/strong> (OTLP, formato preferito 2022 in avanti), <strong>Jaeger<\/strong> (Thrift e gRPC, lo standard CNCF graduated del 2019) e <strong>Zipkin<\/strong> (lo storico di Twitter del 2012). Questo significa che se hai gi\u00e0 strumentato i servizi con Jaeger SDK puoi ricevere quelle tracce in Tempo senza riscrivere codice. La pratica pi\u00f9 sensata nel 2022 \u00e8 per\u00f2 migrare progressivamente a OpenTelemetry SDK perch\u00e9 \u00e8 lo standard che vincer\u00e0 \u2014 sia Jaeger che Zipkin sono in fase di &#8220;feature freeze&#8221; a favore di OTel.<\/p>\n<p>La feature killer di Tempo \u00e8 l&#8217;integrazione bidirezionale con metriche e log dentro Grafana. Dal pannello metrica, click su un exemplar \u2192 la traccia completa si apre in un nuovo tab. Dal pannello log, click su un trace ID estratto via regex \u2192 si apre la traccia. Dalla traccia, click su uno span \u2192 si filtrano i log del servizio in quella finestra temporale di 200ms. Questa correlazione &#8220;ad hoc&#8221; \u00e8 la differenza pratica tra investigare un incident in 5 minuti o in 50 minuti. Una capability che nel 2022 \u00e8 ancora rara nei tool SaaS commerciali a met\u00e0 fascia, ma che con lo stack Grafana \u00e8 gratis.<\/p>\n<h2>OpenTelemetry: strumenta una volta, esporta dove vuoi<\/h2>\n<p>OpenTelemetry (OTel) \u00e8 il progetto CNCF nato dalla fusione di OpenTracing e OpenCensus, in stato &#8220;incubating&#8221;. 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 <strong>vendor lock-in<\/strong> 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&#8217;<strong>OpenTelemetry Collector<\/strong>.<\/p>\n<p>L&#8217;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\u00f9 backend. \u00c8 un binario Go single-process, leggero, configurabile via YAML, deployabile come sidecar o DaemonSet. La <strong>auto-instrumentation<\/strong> \u00e8 la feature che fa risparmiare settimane: per Java basta <code>-javaagent:opentelemetry-javaagent.jar<\/code> 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.<\/p>\n<h2>Quanto costa davvero lo stack OSS contro i SaaS<\/h2>\n<p>Numeri concreti per una PMI italiana tipo, con 20 microservizi, 5 nodi Kubernetes, 500 GB\/mese di log, 5 milioni di tracce\/mese. <strong>Self-hosted su AWS<\/strong>: 3 nodi t3.large per Prometheus+Loki+Tempo (~\u20ac250\/mese), bucket S3 per log e tracce (~\u20ac80\/mese), storage per Mimir long-term (~\u20ac100\/mese), ALB e traffico (~\u20ac50\/mese). Totale infrastruttura: <strong>\u20ac500-700\/mese<\/strong>. Aggiungi 1 SRE part-time (30% di un FTE da \u20ac50k lordi annui) = \u20ac1.250\/mese di tempo umano. Costo annuale all-in: <strong>\u20ac20-25k<\/strong>. <strong>Grafana Cloud<\/strong> (SaaS gestita dello stesso stack): piano Pro da \u20ac49 a \u20ac549\/mese, tipicamente <strong>\u20ac300-500\/mese<\/strong> per la fascia PMI.<\/p>\n<p>Sul fronte commerciale, <strong>Datadog<\/strong> (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\u00e8 <strong>$50-80k\/anno<\/strong>. <strong>New Relic<\/strong>, con modello data-based ($0.30\/GB), si attesta su <strong>$35-55k\/anno<\/strong> per volumi PMI. <strong>Dynatrace<\/strong> ($25-65\/host) arriva a <strong>$60-150k\/anno<\/strong>. <strong>Splunk Cloud<\/strong>: pricing custom, da <strong>$80-200k\/anno<\/strong> per 500GB\/mese di log. La domanda non \u00e8 &#8220;OSS o SaaS?&#8221; in assoluto, \u00e8 &#8220;ho competenze SRE interne?&#8221; e &#8220;il TCO a 3 anni quale soluzione minimizza?&#8221;. Sotto i 30 sviluppatori e 5 nodi K8s, Grafana Cloud \u00e8 spesso la scelta pi\u00f9 razionale; sopra quella soglia, self-hosted ripaga in 12-18 mesi.<\/p>\n<h2>Correlation in pratica: exemplars, trace ID e structured logging<\/h2>\n<p>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 <strong>deve<\/strong> essere structured (JSON) e <strong>deve<\/strong> contenere <code>trace_id<\/code> e <code>span_id<\/code> quando emesso dentro un span attivo. OTel SDK iniettano automaticamente i correlation ID nel MDC (Mapped Diagnostic Context) di Logback per Java, in <code>contextvars<\/code> per Python, in <code>AsyncLocalStorage<\/code> 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 \u00e8 attivo. Terzo, Grafana va configurato con le <strong>data link<\/strong> tra i tre datasource: nella config del datasource Tempo aggiungi un link &#8220;Logs to Loki&#8221;, in Loki aggiungi un link &#8220;Trace to Tempo&#8221; che estrae <code>trace_id<\/code> dal JSON.<\/p>\n<p>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, \u00e8 la differenza tra un MTTR (Mean Time To Resolution) di 5 minuti e uno di 50.<\/p>\n<p><img decoding=\"async\" src=\"https:\/\/brentasoft.com\/blog\/wp-content\/uploads\/2026\/06\/observability_inline3.jpg\" alt=\"Team DevOps a una lavagna che disegna l'architettura observability\" style=\"width:100%;height:auto;border-radius:8px;margin:20px 0;\" \/><\/p>\n<h2>SLO, SLI, error budget: il linguaggio del management<\/h2>\n<p>Una dashboard tecnica con cento grafici non parla la lingua dell&#8217;amministratore delegato. Gli <strong>SLO<\/strong> (Service Level Objectives) s\u00ec. Un SLO \u00e8 un obiettivo misurabile sul comportamento di un servizio dal punto di vista dell&#8217;utente. Esempio: &#8220;il 99.5% delle richieste API risponde sotto 300ms in un periodo di 30 giorni&#8221;. Lo <strong>SLI<\/strong> (Service Level Indicator) \u00e8 la metrica concreta che misuri per verificare l&#8217;SLO. Lo <strong>SLA<\/strong> (Service Level Agreement) \u00e8 il contratto commerciale, tipicamente pi\u00f9 conservativo dell&#8217;SLO interno.<\/p>\n<p>L&#8217;<strong>error budget<\/strong> \u00e8 la conseguenza pratica: se prometti il 99.5% di successo, il restante 0.5% \u00e8 il &#8220;budget&#8221; 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\u00e0. Questo framework, codificato da Google SRE, \u00e8 il modo pi\u00f9 efficace di portare la discussione tecnica al tavolo della direzione senza traduzioni. Per implementarli con Prometheus, le librerie di riferimento sono <strong>sloth<\/strong> e <strong>pyrra<\/strong>, 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.<\/p>\n<h2>Errori comuni nei primi 90 giorni e come evitarli<\/h2>\n<p><strong>Dashboard sprawl<\/strong>: ogni team crea le sue venti dashboard, nessuno le mantiene, sei mesi dopo nessuno le guarda. Definisci una &#8220;shelf&#8221; di dashboard ufficiali (10-15 max) governate dal team di piattaforma, il resto va in cartella &#8220;experimental&#8221; senza alert.<\/p>\n<p><strong>Esplosione cardinalit\u00e0<\/strong> 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\u00e0 sotto 1.000 (servizio, ambiente, metodo HTTP, regione). Tutto il resto va nel contenuto della metrica.<\/p>\n<p><strong>Alert fatigue<\/strong>: troppi alert, tutti &#8220;warning&#8221;, 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&#8217;annotazione Alertmanager.<\/p>\n<p><strong>Nessun tracing<\/strong>: si parte con metriche e log, &#8220;il tracing lo facciamo dopo&#8221; \u2014 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 \u00e8 bassissimo.<\/p>\n<p><strong>Nessuna ownership<\/strong>: l&#8217;observability \u00e8 &#8220;del team DevOps&#8221;, nessun product team la usa. Antidoto: la dashboard RED del servizio \u00e8 responsabilit\u00e0 del team che possiede il servizio; la piattaforma observability \u00e8 responsabilit\u00e0 di un team dedicato (anche solo 1-2 SRE in una PMI).<\/p>\n<h2>Team e competenze: quanti SRE servono davvero<\/h2>\n<p>La buona notizia: per una PMI italiana con 15-30 sviluppatori e 20-50 servizi, <strong>1-2 SRE\/Platform Engineer<\/strong> sono sufficienti per costruire e mantenere lo stack Grafana. Il profilo richiesto \u00e8 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 \u20ac55-75k lordi in Italia nel 2022; mid-level con buona formazione interna \u20ac40-55k.<\/p>\n<p>L&#8217;alternativa &#8220;tutti devono saperlo fare&#8221; 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 \u00e8 che il mercato \u00e8 scarso: SRE con esperienza Kubernetes\/Prometheus\/OTel \u00e8 un profilo cercato e in fuga verso aziende prodotto e remote-first internazionali. Investire in formazione interna di developer senior verso il ruolo SRE \u00e8 spesso pi\u00f9 realistico di assumere dall&#8217;esterno.<\/p>\n<h2>Roadmap 90 giorni: cosa fare settimana per settimana<\/h2>\n<p><strong>Settimane 1-2: foundation.<\/strong> Deploy Prometheus + Grafana su un namespace Kubernetes dedicato (chart Helm <code>kube-prometheus-stack<\/code> 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\u00e0 sull&#8217;infrastruttura.<\/p>\n<p><strong>Settimane 3-4: metriche applicative.<\/strong> Aggiungi endpoint <code>\/metrics<\/code> ai primi 3-5 servizi critici. Per Spring Boot \u00e8 una dipendenza, per Express un middleware, per Flask un decorator. Costruisci una dashboard &#8220;Service Overview&#8221; con RED method. Definisci i primi 5 alert (error rate > 1%, latenza p99 > soglia, pod restart loop).<\/p>\n<p><strong>Settimane 5-6: log centralizzati.<\/strong> Deploy Loki + Promtail (chart Helm <code>loki-stack<\/code>). Configura retention 30 giorni su S3\/MinIO. Aggiungi un pannello &#8220;Recent Errors&#8221; a ogni dashboard di servizio che filtra <code>level=error<\/code> negli ultimi 15 minuti.<\/p>\n<p><strong>Settimane 7-8: tracing distribuito.<\/strong> 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 \u2194 tracce \u2194 log.<\/p>\n<p><strong>Settimane 9-10: alerting maturo.<\/strong> Migra a Grafana Unified Alerting. Configura escalation Slack + PagerDuty (o Opsgenie). Scrivi i runbook per ogni alert critico in un repo Git linkato.<\/p>\n<p><strong>Settimane 11-12: SLO e cultura.<\/strong> 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.<\/p>\n<h2>Tendenze 2022-2023 da tenere d&#8217;occhio<\/h2>\n<p>Tre fronti vale la pena monitorare. L&#8217;<strong>eBPF observability<\/strong> 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 \u00e8 una rivoluzione silenziosa. La <strong>maturazione di OTel logs<\/strong> \u2014 a giugno 2022 la specifica \u00e8 ancora in beta \u2014 completer\u00e0 entro 6-12 mesi il &#8220;single SDK&#8221; del telemetry. Sul fronte commerciale c&#8217;\u00e8 <strong>consolidamento<\/strong>: Datadog aggiunge error tracking e RUM, New Relic ha aperto un modello data-based aggressivo, Honeycomb spinge su event-based tracing ad alta cardinalit\u00e0, Lightstep \u00e8 stata acquisita da ServiceNow nel 2021. Per la PMI questo significa pi\u00f9 opzioni a costi calanti, ma anche pi\u00f9 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.<\/p>\n<div style=\"background:linear-gradient(135deg,#0284c7 0%,#7c3aed 100%);color:#ffffff;padding:32px 28px;margin:36px 0;border-radius:12px;text-align:center;\">\n<h3 style=\"color:#ffffff;margin:0 0 12px 0;font-size:1.4em;\">Vuoi un&#8217;architettura observability cucita sulla tua PMI?<\/h3>\n<p style=\"margin:0 0 20px 0;font-size:1.05em;\">Costruiamo lo stack Grafana, definiamo SLO e formiamo il tuo team \u2014 senza vendor lock-in.<\/p>\n<p style=\"margin:0;\"><a href=\"https:\/\/brentasoft.com\/preventivatore.php\" style=\"display:inline-block;background:#ffffff;color:#0284c7;padding:14px 32px;border-radius:8px;text-decoration:none;font-weight:600;\">Richiedi un preventivo<\/a><\/p>\n<\/div>\n<h2>Conclusione<\/h2>\n<p>L&#8217;observability open source nel 2022 non \u00e8 pi\u00f9 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 \u00e8 il tempo umano: 1-2 SRE con buone competenze, una roadmap di 90 giorni disciplinata e un management che capisce la differenza tra &#8220;monitoring&#8221; (sapere che qualcosa \u00e8 rotto) e &#8220;observability&#8221; (capire perch\u00e9). Per le aziende che hanno scelto la via dei microservizi, l&#8217;observability non \u00e8 un lusso da fase 2: \u00e8 la condizione per cui i microservizi non diventino, paradossalmente, meno affidabili del monolite che hanno sostituito.<\/p>\n<p><script type=\"application\/ld+json\">\n{\n  \"@context\": \"https:\/\/schema.org\",\n  \"@type\": \"HowTo\",\n  \"name\": \"Come implementare uno stack observability open source per microservizi in 90 giorni\",\n  \"description\": \"Roadmap operativa in 5 step per costruire un sistema di osservabilita basato su Prometheus, Grafana, Loki e Tempo in una PMI italiana.\",\n  \"totalTime\": \"P90D\",\n  \"step\": [\n    {\n      \"@type\": \"HowToStep\",\n      \"position\": 1,\n      \"name\": \"Foundation: Prometheus e Grafana\",\n      \"text\": \"Settimane 1-2. Installa kube-prometheus-stack via Helm, configura node_exporter e kube-state-metrics, importa dashboard community Kubernetes.\"\n    },\n    {\n      \"@type\": \"HowToStep\",\n      \"position\": 2,\n      \"name\": \"Metriche applicative RED method\",\n      \"text\": \"Settimane 3-4. Aggiungi endpoint \/metrics ai servizi critici, costruisci dashboard Service Overview, definisci primi 5 alert su error rate e latenza.\"\n    },\n    {\n      \"@type\": \"HowToStep\",\n      \"position\": 3,\n      \"name\": \"Log centralizzati con Loki\",\n      \"text\": \"Settimane 5-6. Deploy Loki + Promtail via Helm, configura retention 30 giorni su S3, aggiungi pannello Recent Errors alle dashboard di servizio.\"\n    },\n    {\n      \"@type\": \"HowToStep\",\n      \"position\": 4,\n      \"name\": \"Distributed tracing con Tempo e OpenTelemetry\",\n      \"text\": \"Settimane 7-8. Deploy Tempo, abilita OTel auto-instrumentation sui servizi, configura OTel Collector come DaemonSet, verifica correlation Grafana.\"\n    },\n    {\n      \"@type\": \"HowToStep\",\n      \"position\": 5,\n      \"name\": \"SLO, alerting maturo e cultura SRE\",\n      \"text\": \"Settimane 9-12. Migra a Grafana Unified Alerting, definisci 3-5 SLO sui servizi business-critical, scrivi runbook in Git, formalizza processo post-mortem blame-less.\"\n    }\n  ]\n}\n<\/script><\/p>\n<p><script type=\"application\/ld+json\">\n{\n  \"@context\": \"https:\/\/schema.org\",\n  \"@type\": \"FAQPage\",\n  \"mainEntity\": [\n    {\n      \"@type\": \"Question\",\n      \"name\": \"Quanto costa uno stack observability OSS Grafana per una PMI italiana?\",\n      \"acceptedAnswer\": {\n        \"@type\": \"Answer\",\n        \"text\": \"Per una PMI con 20 microservizi e 5 nodi Kubernetes, l'infrastruttura cloud (AWS o GCP) costa 500-700 euro al mese: 3 nodi t3.large per Prometheus, Loki e Tempo, bucket S3 per long-term storage, ALB e traffico. Aggiungendo 1 SRE part-time al 30% (su uno stipendio lordo da 50k annui) si arriva a un TCO annuale di 20-25k euro, contro 35-150k euro annui delle soluzioni SaaS equivalenti come Datadog, New Relic o Dynatrace.\"\n      }\n    },\n    {\n      \"@type\": \"Question\",\n      \"name\": \"Quali sono i tre pilastri dell'observability?\",\n      \"acceptedAnswer\": {\n        \"@type\": \"Answer\",\n        \"text\": \"I tre pilastri codificati da Cindy Sridharan nel 2018 sono: metriche (aggregati numerici nel tempo, gestiti da Prometheus), log (eventi discreti con testo, gestiti da Loki o ELK Stack) e tracce distribuite (rappresentazione di una richiesta attraverso piu servizi, gestita da Tempo o Jaeger). La correlazione tra i tre tramite trace ID condivisi e exemplars e cio che trasforma un sistema monitorato in un sistema osservabile.\"\n      }\n    },\n    {\n      \"@type\": \"Question\",\n      \"name\": \"Perche Grafana Loki costa meno di Elasticsearch per i log?\",\n      \"acceptedAnswer\": {\n        \"@type\": \"Answer\",\n        \"text\": \"Loki non indicizza il contenuto dei log, indicizza solo i label di metadata come servizio, ambiente e livello. Il payload viene compresso in chunk e salvato su object storage economico (S3, GCS, MinIO). Una pipeline log da 100GB al giorno costa su Loki circa un decimo rispetto a una soluzione Elastic equivalente. Il trade-off e che le ricerche full-text estese sono piu lente, ma nella pratica operativa le query sono sempre filtrate per servizio e finestra temporale.\"\n      }\n    },\n    {\n      \"@type\": \"Question\",\n      \"name\": \"Cos'e OpenTelemetry e perche e importante nel 2022?\",\n      \"acceptedAnswer\": {\n        \"@type\": \"Answer\",\n        \"text\": \"OpenTelemetry (OTel) e il progetto CNCF nato dalla fusione di OpenTracing e OpenCensus, con le specifiche trace dichiarate stable a febbraio 2022. Risolve il vendor lock-in della strumentazione: strumenti il codice una volta in formato OTLP e poi puoi inviare i dati a qualsiasi backend (Tempo, Jaeger, Datadog, Honeycomb) cambiando solo la configurazione dell'OTel Collector. La auto-instrumentation per Java, Python, Node.js e .NET elimina settimane di lavoro manuale.\"\n      }\n    },\n    {\n      \"@type\": \"Question\",\n      \"name\": \"Cosa sono i quattro segnali oro di Google SRE?\",\n      \"acceptedAnswer\": {\n        \"@type\": \"Answer\",\n        \"text\": \"I quattro segnali oro codificati nel libro Site Reliability Engineering (O'Reilly 2016) sono: latency (tempo di risposta, separato tra successo e errore), traffic (richieste al secondo o connessioni attive), errors (tasso di fallimento) e saturation (quanto e pieno il servizio rispetto alla capacita). Ogni microservizio dovrebbe esporre questi quattro segnali su un endpoint \/metrics in formato Prometheus. Il RED method (Rate, Errors, Duration) di Tom Wilkie e una formulazione pragmatica equivalente per servizi request-driven.\"\n      }\n    },\n    {\n      \"@type\": \"Question\",\n      \"name\": \"Quanti SRE servono davvero per gestire uno stack observability in una PMI?\",\n      \"acceptedAnswer\": {\n        \"@type\": \"Answer\",\n        \"text\": \"Per una PMI italiana con 15-30 sviluppatori e 20-50 servizi, 1-2 SRE o Platform Engineer sono sufficienti. Il profilo ideale combina 40% sysadmin Linux\/Kubernetes, 30% sviluppo software (Go o Python), 20% data analysis e PromQL, 10% facilitazione culturale verso i team di prodotto. In Italia nel 2022 un senior costa 55-75k lordi annui, un mid-level 40-55k. Formare internamente sviluppatori senior verso il ruolo SRE e spesso piu realistico che assumere dall'esterno data la scarsita di profili.\"\n      }\n    },\n    {\n      \"@type\": \"Question\",\n      \"name\": \"Quali sono gli errori piu comuni nei primi 90 giorni di adozione observability?\",\n      \"acceptedAnswer\": {\n        \"@type\": \"Answer\",\n        \"text\": \"Cinque errori ricorrenti: dashboard sprawl (proliferazione di dashboard non mantenute), esplosione cardinalita dei label (mettere user_id come label Prometheus), alert fatigue (troppi alert non azionabili), rimandare il distributed tracing (parte si poi non arriva mai) e mancanza di ownership (observability come responsabilita ambigua tra team). Antidoti: governance centrale sulle dashboard core, regole sui label con cardinalita sotto 1000, alert solo su SLO burn rate, OTel auto-instrumentation dal giorno 30, team di piattaforma dedicato.\"\n      }\n    }\n  ]\n}\n<\/script><\/p>\n","protected":false},"excerpt":{"rendered":"<p>Guida pratica 2022 all&#8217;observability per microservizi: stack open source Prometheus, Grafana, Loki e Tempo, OpenTelemetry, SLO Google SRE, costi reali per PMI italiane e roadmap rollout in 90 giorni.<\/p>\n","protected":false},"author":2,"featured_media":2013,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_seopress_titles_title":"Observability PMI 2022: Prometheus Grafana Loki | Brentasoft","_seopress_titles_desc":"Guida 2022 observability microservizi PMI italiane: stack OSS Prometheus, Grafana, Loki, Tempo. SLO Google SRE, OpenTelemetry, costi e roadmap 90 giorni.","_seopress_robots_index":"","_seopress_robots_follow":"","_seopress_robots_imageindex":"","_seopress_robots_snippet":"","_seopress_robots_primary_cat":"","_seopress_robots_breadcrumbs":"","_seopress_robots_freeze_modified_date":"","_seopress_robots_custom_modified_date":"","_seopress_robots_canonical":"https:\/\/brentasoft.com\/blog\/microservizi-observability-prometheus-grafana-loki-pmi-2022\/","_seopress_social_fb_title":"Observability PMI 2022: Prometheus Grafana Loki | Brentasoft","_seopress_social_fb_desc":"Guida 2022 observability microservizi PMI italiane: stack OSS Prometheus, Grafana, Loki, Tempo. SLO Google SRE, OpenTelemetry, costi e roadmap 90 giorni.","_seopress_social_fb_img":"https:\/\/brentasoft.com\/blog\/wp-content\/uploads\/2026\/06\/observability_featured.jpg","_seopress_social_fb_img_attachment_id":0,"_seopress_social_fb_img_width":0,"_seopress_social_fb_img_height":0,"_seopress_social_twitter_title":"Observability PMI 2022: Prometheus Grafana Loki | Brentasoft","_seopress_social_twitter_desc":"Guida 2022 observability microservizi PMI italiane: stack OSS Prometheus, Grafana, Loki, Tempo. SLO Google SRE, OpenTelemetry, costi e roadmap 90 giorni.","_seopress_social_twitter_img":"https:\/\/brentasoft.com\/blog\/wp-content\/uploads\/2026\/06\/observability_featured.jpg","_seopress_social_twitter_img_attachment_id":0,"_seopress_social_twitter_img_width":0,"_seopress_social_twitter_img_height":0,"_seopress_redirections_value":"","_seopress_redirections_enabled":"","_seopress_redirections_enabled_regex":"","_seopress_redirections_logged_status":"","_seopress_redirections_param":"","_seopress_redirections_type":0,"_seopress_analysis_target_kw":"","footnotes":""},"categories":[7],"tags":[],"class_list":["post-2021","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-trasformazione-digitale"],"_links":{"self":[{"href":"https:\/\/brentasoft.com\/blog\/wp-json\/wp\/v2\/posts\/2021","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/brentasoft.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/brentasoft.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/brentasoft.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/brentasoft.com\/blog\/wp-json\/wp\/v2\/comments?post=2021"}],"version-history":[{"count":0,"href":"https:\/\/brentasoft.com\/blog\/wp-json\/wp\/v2\/posts\/2021\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/brentasoft.com\/blog\/wp-json\/wp\/v2\/media\/2013"}],"wp:attachment":[{"href":"https:\/\/brentasoft.com\/blog\/wp-json\/wp\/v2\/media?parent=2021"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/brentasoft.com\/blog\/wp-json\/wp\/v2\/categories?post=2021"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/brentasoft.com\/blog\/wp-json\/wp\/v2\/tags?post=2021"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}