I tre pilastri del cloud monitoring
Infrastructure monitoring
Questo è il fondamento: compute (CPU, memoria, I/O disco), storage (throughput, IOPS, latenza) e salute della piattaforma sottostante (hypervisor, container runtime, ambiente di esecuzione serverless). Ogni cloud provider espone queste metriche nativamente:
- AWS CloudWatch — metriche per EC2, RDS, EBS, Lambda, più custom metrics via CloudWatch agent o StatsD
- Azure Monitor — metriche di piattaforma raccolte automaticamente per tutte le risorse Azure, con Log Analytics workspace per query più approfondite (KQL)
- GCP Cloud Monitoring (ex Stackdriver) — raccolta automatica di metriche per Compute Engine, GKE, Cloud SQL e Cloud Functions
La trappola è monitorare le medie. Una CPU con media al 45% sembra sana, ma se va in spike al 98% per 10 secondi ogni minuto, i vostri utenti stanno subendo ritardi da accodamento che la media nasconde. Monitorate sempre i percentili (p95, p99) per latenza e metriche legate alla saturazione.
Application Performance Monitoring (APM)
L'APM strumenta il codice per tracciare le richieste end-to-end attraverso microservizi, database, cache e API esterne. I segnali standard sono le metriche RED: Request rate, Error rate e Duration (distribuzione della latenza).
OpenTelemetry è diventato lo standard de facto per la strumentazione. È vendor-neutral, supporta l'auto-instrumentation in Java, Python, .NET, Go, Node.js e altri linguaggi, ed esporta verso qualsiasi backend — Datadog, Dynatrace, Grafana Tempo, AWS X-Ray, Azure Application Insights o GCP Cloud Trace. Se partite da zero nel 2026, strumentate con gli SDK OpenTelemetry e scegliete il backend separatamente. Questo evita il vendor lock-in sul livello di strumentazione, che è la parte più difficile da rimuovere in seguito.
Ciò che conta operativamente: trace distribuite che permettono di vedere che una richiesta di checkout ha impiegato 12 ms nell'API gateway, 45 ms nel servizio ordini, 800 ms in attesa di un'API di pagamento di terze parti e 3 ms nella scrittura su DynamoDB. Senza questa scomposizione, "il checkout è lento" è tutto ciò che sapete.
Network monitoring
L'osservabilità di rete è il punto cieco della maggior parte delle strategie di cloud monitoring. All'interno di una VPC, ci si affida ai flow log (VPC Flow Logs su AWS, NSG Flow Logs su Azure, VPC Flow Logs su GCP) per visualizzare pattern di traffico, pacchetti scartati e volumi di trasferimento dati cross-AZ/cross-region.
Per configurazioni ibride — Direct Connect, ExpressRoute, Cloud Interconnect — monitorare lo stato del tunnel, la sessione BGP e jitter/packet loss attraverso il link è fondamentale. Un circuito Direct Connect degradato non comparirà nelle metriche applicative fino a quando la latenza non raddoppierà e i clienti chiameranno.
Strumenti come Kentik, ThousandEyes (ora parte di Cisco) e i servizi nativi di network monitoring dei provider gestiscono bene questo aspetto. Se il vostro ambiente è single-cloud e semplice, gli strumenti nativi bastano. Multi-cloud o ibrido? Serve un livello dedicato di network observability.
Metriche che contano davvero in produzione
Non tutte le metriche meritano un alert. Ecco ciò che il nostro NOC prioritizza, classificato per valore operativo:
| Metrica | Perché è importante | Soglia alert indicativa |
|---|---|---|
| Latenza p95/p99 | Rappresenta l'esperienza degli utenti più lenti (e spesso più preziosi) | >2× la baseline per 5 minuti |
| Tasso di errore (5xx) | Indicatore diretto di funzionalità interrotte | >0,5% delle richieste totali per 2 minuti |
| Saturazione (CPU/Memoria/Disco) | Predice un guasto imminente prima che accada | >85% sostenuto per 10 minuti |
| Request Rate (RPS) | Cali improvvisi segnalano problemi a monte o traffico instradato male | >30% di deviazione dalla baseline prevista |
| Time to First Byte (TTFB) | Proxy della performance percepita dall'utente, specialmente per app globali | >500 ms al CDN edge |
| Tempo di risoluzione DNS | Spesso trascurato; un lookup DNS lento aggiunge latenza a ogni richiesta | >100 ms in media |
| Replication lag | Per database (RDS, Cloud SQL, Cosmos DB) — rischio di consistenza dei dati | >5 secondi per carichi transazionali |
| Container restart count | Pattern OOMKilled o CrashLoopBackOff segnalano configurazioni risorse errate | >3 restart in 15 minuti |
Il metodo USE (Utilization, Saturation, Errors) funziona bene per le risorse infrastrutturali. Il metodo RED (Rate, Errors, Duration) funziona bene per i servizi. Usateli entrambi. Sono complementari — USE descrive la macchina, RED descrive il lavoro che la macchina sta svolgendo.
Confronto tra strumenti: nativi vs. terze parti
Strumenti di monitoring cloud nativi
| Funzionalità | AWS CloudWatch | Azure Monitor | GCP Cloud Monitoring |
|---|---|---|---|
| Metriche auto-raccolte | Sì (base) | Sì (metriche piattaforma) | Sì (base) |
| Custom metrics | Sì (CloudWatch API / embedded metric format) | Sì (custom metrics API) | Sì (custom metrics API) |
| Aggregazione log | CloudWatch Logs / Logs Insights | Log Analytics (KQL) | Cloud Logging |
| Distributed tracing | X-Ray | Application Insights | Cloud Trace |
| Alerting | CloudWatch Alarms + SNS | Action Groups + Logic Apps | Alerting Policies + Pub/Sub |
| Dashboard | CloudWatch Dashboards | Azure Dashboards / Workbooks | Cloud Monitoring Dashboards |
| Costo a scala | Elevato (custom metrics, log ingestion) | Moderato (pricing ingestion Log Analytics) | Moderato |
La visione di Opsio: gli strumenti nativi sono il punto di partenza corretto e restano essenziali per metriche specifiche delle risorse che gli strumenti di terze parti non possono raccogliere (ad es. Lambda concurrent executions, Azure Service Bus dead-letter counts). Tuttavia, se eseguite workload su due o più provider — il che, secondo il report Flexera State of the Cloud, è il caso della grande maggioranza delle aziende — serve un livello cross-cloud.
Piattaforme di observability di terze parti
- Datadog — la soluzione all-in-one più completa: infrastruttura, APM, log, synthetic monitoring, segnali di sicurezza e dashboard FinOps. Ampio catalogo di integrazioni. Svantaggio: il costo scala in modo aggressivo con il numero di host e la cardinalità delle custom metrics.
- Dynatrace — l'analisi root-cause guidata da AI (Davis AI) è genuinamente utile per ambienti complessi. Forte auto-instrumentation per Java/.NET. Svantaggio: il modello di licensing può essere poco trasparente.
- Grafana Cloud (stack LGTM) — Grafana + Loki (log) + Tempo (trace) + Mimir (metriche). Core open-source con opzione di hosting gestito. Ideale per team che vogliono controllo ed evitare il vendor lock-in. Svantaggio: richiede maggiore competenza operativa per tuning e manutenzione.
- New Relic — tier gratuito generoso, pricing a consumo. Buon APM. Svantaggio: network monitoring e profondità infrastrutturale inferiori a Datadog.
- Elastic Observability — costruito su Elasticsearch. Valido se già utilizzate lo stack ELK per il logging. Svantaggio: scalare cluster Elasticsearch per metriche ad alta cardinalità non è banale.
Per team attenti ai costi, lo stack Grafana LGTM con strumentazione OpenTelemetry offre il miglior rapporto controllo/costo. Per team che vogliono un servizio completamente gestito e sono disposti a pagarlo, Datadog o Dynatrace sono le scelte pragmatiche.
Best practice da un NOC 24/7
Non sono raccomandazioni teoriche. Derivano da pattern che osserviamo su centinaia di workload monitorati.
1. Definite gli SLO prima di definire gli alert
Un alert senza un Service Level Objective è rumore. Partite definendo cosa significa "sano" per ciascun servizio — ad esempio "il 99,9% delle richieste di checkout si completa entro 800 ms con tasso di errore <0,1%." Poi impostate gli alert sul burn rate di quel budget di errore. Il libro SRE di Google ha formalizzato questo approccio e funziona. L'alerting multi-window, multi-burn-rate (fast burn per le page, slow burn per i ticket) riduce drasticamente l'alert fatigue.
2. Centralizzate in un'unica pipeline di observability
Negli ambienti multi-cloud, il più grande spreco di tempo è il context-switching tra tre console diverse. Usate OpenTelemetry Collector come router di telemetria vendor-neutral: riceve metriche, trace e log da qualsiasi sorgente e li esporta verso il backend scelto. Questo disaccoppia la strumentazione dallo storage e mantiene aperte le opzioni future.
3. Monitorate il monitoring
La vostra pipeline di observability è essa stessa infrastruttura. Se il vostro server Prometheus esaurisce il disco, o il vostro agent Datadog si arresta silenziosamente, avete un punto cieco proprio nel momento in cui avete bisogno di visibilità. Eseguite un controllo heartbeat/canary leggero che validi che il vostro stack di monitoring stia ingerendo dati. Noi eseguiamo check sintetici ogni 60 secondi che inviano una metrica nota e generano un alert se non arriva entro 120 secondi.
4. Correlate i costi con le metriche di performance
È qui che il Cloud FinOps incontra il performance monitoring. Un'istanza che gira all'8% di CPU non è un problema di performance — è un problema di costi. Un'istanza al 92% di CPU non è un problema di costi — è un rischio di affidabilità. Presentare entrambi nella stessa dashboard permette ai team di prendere decisioni di right-sizing con il contesto completo. AWS Compute Optimizer, Azure Advisor e GCP Recommender forniscono suggerimenti nativi di right-sizing, ma mancano del contesto applicativo. Sovrapponeteli ai dati APM per raccomandazioni realmente utili.
5. Gestite la retention dei log in modo strategico
Conservare ogni log di debug di ogni container per sempre è il modo più rapido per accumulare una bolletta di observability a sei cifre. Organizzate la retention a livelli: hot storage (7-14 giorni) per il troubleshooting operativo, warm storage (30-90 giorni) per l'analisi dei trend e cold/archive storage per la compliance. Il GDPR — direttamente applicabile in Italia e vigilato dal Garante per la protezione dei dati personali — richiede che i dati personali nei log siano trattati con lo stesso rigore dei dati nei database: mascherate o pseudonimizzate i PII al livello di raccolta, non dopo l'ingestione. I requisiti di logging previsti dalla NIS2 per le entità essenziali significano che non potete semplicemente cancellare tutto dopo 7 giorni. Progettate policy di retention che soddisfino sia le esigenze operative sia quelle regolatorie.
6. Strumentate per la performance regionale
Se servite utenti sia in Italia/Europa sia in India, monitorate da entrambe le aree geografiche. Un servizio che performa bene misurato da eu-south-1 (Milano) potrebbe avere 400 ms di latenza aggiuntiva se acceduto da ap-south-1 (Mumbai). Il synthetic monitoring con checkpoint a Milano, Francoforte, Mumbai e Bangalore vi fornisce la verità dal punto di vista dell'utente. Il NOC di Opsio esegue check sintetici da più aree geografiche proprio perché il degrado regionale è invisibile da un singolo punto di osservazione.
Monitoring in ambienti ibridi e multi-cloud
La maggior parte delle aziende non è single-cloud, indipendentemente da quanto dichiari la propria strategia ufficiale. Secondo il report Flexera State of the Cloud, l'adozione multi-cloud è rimasta il pattern dominante per diversi anni consecutivi. La sfida di monitoring si moltiplica: le metriche hanno nomi diversi, granularità diverse e API diverse tra i provider.
Architettura pratica di monitoring multi-cloud
1. Livello di raccolta: deploy di OpenTelemetry Collector in ciascun ambiente (AWS, Azure, GCP, on-premises). Configurateli per normalizzare i nomi delle metriche e aggiungere tag del cloud provider.
2. Livello di aggregazione: instradate tutta la telemetria verso un backend centralizzato — Datadog, Grafana Cloud o uno stack self-hosted Mimir/Loki/Tempo.
3. Livello di correlazione: utilizzate service map e grafi di dipendenza che attraversino i provider. Una richiesta potrebbe partire da un Azure Front Door CDN, colpire un'API in esecuzione su AWS EKS e interrogare un database su GCP Cloud SQL. Senza una trace cross-cloud, non troverete mai il collo di bottiglia.
4. Livello di alerting: alerting centralizzato con PagerDuty, Opsgenie o Grafana OnCall come singolo punto di instradamento. Evitate silos di alerting cloud-native — un Azure Action Group che allerta un team mentre un CloudWatch Alarm allerta un altro porta a duplicazione degli sforzi e correlazioni mancate.
Specifiche per il cloud ibrido
Per workload che si estendono tra on-premises e cloud (comune in settori come manifatturiero, sanità e pubblica amministrazione), monitorate l'interconnessione come componente di prima classe. I circuiti Direct Connect, ExpressRoute e Cloud Interconnect hanno SLA, ma tali SLA non coprono la sensibilità della vostra applicazione al jitter. Implementate probe di latenza bidirezionali attraverso il link e generate alert sul degrado prima che impatti il traffico reale.
Compliance e residenza dei dati
UE e Italia: NIS2 e GDPR
La Direttiva NIS2, applicabile dal ottobre 2024 e recepita in Italia con il D.Lgs. 138/2024 sotto la vigilanza dell'ACN (Agenzia per la Cybersicurezza Nazionale), richiede alle entità nei settori essenziali e importanti di implementare misure appropriate di gestione del rischio — che includono esplicitamente capacità di monitoring e rilevamento degli incidenti. La vostra architettura di monitoring è auditabile. Se non potete dimostrare di aver avuto visibilità sull'incidente, la conversazione regolatoria diventa molto più difficile.
Il GDPR — vigilato in Italia dal Garante per la protezione dei dati personali — vincola dove i dati di monitoring possono essere conservati ed elaborati. Se i log applicativi contengono indirizzi IP, ID utente o token di sessione, quei log sono dati personali ai sensi del GDPR. Inviarli a un SaaS con hosting negli Stati Uniti senza meccanismi di trasferimento appropriati (SCC, decisioni di adeguatezza) è un rischio di compliance. Scegliete backend di monitoring che offrano elaborazione dati in hosting UE, o fatene il self-hosting in region europee come eu-south-1 (Milano) su AWS o Italy North su Azure. Grafana Cloud offre cluster dedicati UE; Datadog offre il site EU1 (Francoforte).
La strategia Cloud Italia e la qualificazione dei servizi cloud per la PA, gestita da ACN, impongono ulteriori requisiti per le organizzazioni del settore pubblico italiano che devono garantire la sovranità dei dati: assicuratevi che la vostra pipeline di observability sia conforme ai livelli di qualificazione richiesti.
India: DPDPA 2023
Il Digital Personal Data Protection Act (DPDPA) 2023 introduce obblighi di trattamento dati basati sul consenso e requisiti di localizzazione dei dati per determinate categorie. I dati di monitoring che contengono identificatori personali di data principal indiani devono essere trattati con attenzione. L'impatto pratico: se monitorate applicazioni rivolte agli utenti che servono clienti indiani, assicuratevi che la vostra pipeline di log-masking elimini o pseudonimizzi i dati personali prima che lascino il livello di raccolta.
Abilitare il cloud monitoring: un percorso di partenza pratico
Per i team nelle prime fasi di maturità del monitoring, ecco una sequenza concreta — non un esercizio del tipo "bollire l'oceano":
Settimana 1-2: Abilitate il monitoring nativo per tutte le risorse cloud. Attivate il CloudWatch detailed monitoring (intervalli di 1 minuto), la diagnostica di Azure Monitor o GCP Cloud Monitoring. Di solito è una singola riga in Terraform/Bicep/Config Connector per risorsa.
Settimana 3-4: Strumentate i tre servizi più critici con OpenTelemetry. Fate il deploy dell'OTel Collector come sidecar (Kubernetes) o daemon (EC2/VM). Esportate trace e metriche verso il backend scelto.
Mese 2: Definite gli SLO per quei tre servizi. Implementate alerting basato su error-budget. Connettete gli alert a PagerDuty o Opsgenie con rotazioni di reperibilità.
Mese 3: Aggiungete synthetic monitoring da almeno due posizioni geografiche (ad esempio Milano e Francoforte). Stabilite dashboard di baseline. Iniziate la centralizzazione dei log con livelli di retention.
In continuo: Espandete la strumentazione ai servizi rimanenti. Aggiungete il network monitoring. Integrate i dati di costo. Revisionate e regolate le soglie degli alert trimestralmente — soglie obsolete sono peggio di nessuna soglia perché addestrano i team a ignorare gli alert.
Virtual Machine Monitor e performance cloud
Un virtual machine monitor (VMM), detto anche hypervisor, è il livello software che gestisce l'allocazione delle risorse fisiche — CPU, memoria, storage, rete — alle macchine virtuali. Nel cloud computing, l'hypervisor (AWS Nitro, Azure Hyper-V, il KVM customizzato di GCP) è il fondamento che rende possibile la multi-tenancy. Dal punto di vista del monitoring, raramente si interagisce direttamente con l'hypervisor sul cloud pubblico — il provider lo astrae. Ma se ne osservano gli effetti: lo "steal time" su un'istanza Linux (la metrica %steal in top o sar) indica che l'hypervisor sta allocando cicli CPU ad altri tenant. Se lo steal time supera costantemente il 5-10%, state sperimentando effetti noisy-neighbor e dovreste valutare istanze dedicate o bare metal.
Cloud logging vs. cloud monitoring: chiarire la relazione
Logging e monitoring sono discipline distinte ma interdipendenti. Il monitoring risponde a "c'è qualcosa che non va in questo momento?" attraverso metriche real-time e alert. Il logging risponde a "cosa è successo esattamente?" attraverso record di eventi discreti. Le trace aggiungono la terza dimensione: "come ha attraversato il sistema la richiesta?"
Il termine moderno "observability" unifica tutti e tre — metriche, log e trace — in una pratica coesa. In termini di strumenti: CloudWatch Metrics + CloudWatch Logs + X-Ray; Azure Monitor Metrics + Log Analytics + Application Insights; GCP Cloud Monitoring + Cloud Logging + Cloud Trace. Oppure, con stack di terze parti: Datadog Infrastructure + Logs + APM; Grafana Mimir + Loki + Tempo.
Il consiglio pratico: non costruite logging e monitoring come progetti separati con team separati. Condividono l'infrastruttura, condividono il contesto e vengono interrogati insieme durante ogni incidente.
Domande frequenti
Come si misurano le performance del cloud?
Le performance cloud si misurano con il metodo RED (Rate, Errors, Duration) per i servizi e il metodo USE (Utilization, Saturation, Errors) per l'infrastruttura. Le applicazioni vanno strumentate con distributed tracing (OpenTelemetry), le metriche infrastrutturali raccolte tramite agent nativi del provider, e vanno stabilite baseline per latenza p95, tasso di errore e disponibilità. Il synthetic monitoring aggiunge una validazione esterna che verifica che gli utenti reali riescano a raggiungere gli endpoint entro le soglie SLA.
Quali sono le tre componenti del cloud monitoring?
Le tre componenti sono: infrastructure monitoring (compute, storage, salute della rete), application performance monitoring (tracciamento transazioni, tassi di errore, tempi di risposta) e log management/analytics (aggregazione centralizzata dei log, ricerca e alerting). Alcuni framework aggiungono una quarta componente — il security monitoring — ma nella pratica i segnali di sicurezza confluiscono nella stessa pipeline di observability.
Cos'è la regola 3-4-5 nel cloud computing?
La regola 3-4-5 è un'euristica per backup e disaster recovery: mantenere 3 copie dei dati, su 4 tipi diversi di supporto di archiviazione, con 5 copie conservate off-site o in una region diversa. Sebbene sia nata come linea guida per la protezione dei dati, influisce direttamente sulla progettazione del monitoring perché è necessario verificare continuamente la salute della replica, la compliance RPO e la prontezza del failover regionale.
Quali sono i cinque tipi di monitoring?
I cinque tipi comunemente citati sono: infrastructure monitoring, application performance monitoring (APM), network monitoring, security monitoring (SIEM/SOC) e real-user/synthetic monitoring. In ambito cloud si sovrappongono ampiamente — un picco di latenza potrebbe derivare da un problema di rete, un bug applicativo o un effetto noisy-neighbor su infrastruttura condivisa — motivo per cui le piattaforme di observability unificate stanno sostituendo gli strumenti a silos.
Qual è la differenza tra cloud logging e cloud monitoring?
Il monitoring raccoglie metriche time-series (CPU, latenza, conteggio errori) e genera alert al superamento di soglie. Il logging cattura record di eventi discreti — errori applicativi, access log, audit trail — da interrogare a posteriori. In pratica sono complementari: un alert si attiva da una metrica di monitoring e gli ingegneri passano ai log per diagnosticare la causa radice. L'observability moderna unifica metriche, log e trace in un unico flusso di lavoro.
