Amazon CloudWatch: metriche, alarm e dashboard

Amazon CloudWatch raccoglie metriche standard dai servizi AWS a risoluzione tipicamente di 5 minuti (1 minuto con detailed monitoring). Quando ti serve misurare qualcosa che AWS non espone nativamente — profondità di una coda applicativa, numero di transazioni fallite, latenza interna — pubblichi custom metrics, scegliendo tra standard resolution e high-resolution (fino al secondo) per allarmi reattivi. Il costo cresce con il numero di metriche uniche, quindi attenzione al cardinality delle dimensions.

Gli alarm valutano una metrica (o una metric math expression) su un numero di data point consecutivi. Il tuning chiave è evaluation periods più datapoints to alarm (M-of-N) per assorbire spike transitori, e la scelta del treat missing data per metriche sparse. Un alarm in stato ALARM può notificare via Amazon SNS, avviare un’azione EC2/Auto Scaling o innescare una risposta automatica. I composite alarm combinano più alarm con logica booleana (AND/OR): servono a ridurre il rumore delle notifiche, alzando un solo allarme aggregato invece di decine di alert simultanei. Le dashboard offrono la vista operativa cross-region e cross-account, utili per correlare visivamente più segnali.

CloudWatch Logs: metric filter, subscription filter e Logs Insights

I log applicativi e di sistema confluiscono in CloudWatch Logs (log group → log stream), con retention configurabile per log group. Da qui hai tre strumenti da distinguere bene, perché l’esame li confonde di proposito.

Il metric filter trasforma pattern testuali nei log in una metrica numerica CloudWatch: è il modo per far scattare un alarm su un evento nei log (es. contare le occorrenze di “ERROR 500” o gli accessi negati). È retrospettivo e periodico, non real-time.

Il subscription filter invece fa streaming near real-time degli eventi che matchano un pattern verso una destinazione: Amazon Kinesis Data Streams, Amazon Data Firehose o AWS Lambda. È il meccanismo giusto per elaborazione in tempo reale, inoltro cross-account e ingestion verso un data lake o un SIEM.

CloudWatch Logs Insights è il motore di query interattive per analisi ad hoc: filtri, aggregazioni e parsing su uno o più log group, ideale per l’indagine durante un incident. Non è però il canale per esportare o instradare log verso altri sistemi — quello è compito del subscription filter.

Logging centralizzato multi-account

In un’organizzazione con molti account (tipico contesto AWS Organizations) vuoi un centralized logging in un account dedicato di sicurezza/osservabilità. Il pattern standard usa subscription filter a livello di account o di singolo log group che spingono verso un Kinesis Data Streams o un Amazon Data Firehose nell’account centrale, con Firehose che deposita su Amazon S3 per storage durevole e query con Amazon Athena. In alternativa, i log destinati all’audit (AWS CloudTrail, VPC Flow Logs) vengono consolidati direttamente su un bucket S3 centrale con bucket policy cross-account. La cross-account observability di CloudWatch permette inoltre di leggere metriche, log e trace di più source account da un unico monitoring account senza spostare i dati.

AWS X-Ray e correlazione per la root cause

AWS X-Ray fornisce il distributed tracing: il service map mostra le dipendenze tra microservizi, e le trace evidenziano dove si concentrano latenza ed errori lungo la richiesta. Abiliti X-Ray strumentando l’applicazione con l’SDK/ADOT e usando trace header propagati tra i servizi; su Lambda basta attivare active tracing. L’abilità che l’esame premia è correlare: l’alarm segnala il sintomo (latenza alta), X-Ray isola il servizio o la downstream call colpevole, e Logs Insights sui log di quel componente conferma la root cause. Metriche, trace e log sono strati complementari, non alternativi.

Trappole tipiche d’esame

  • Contare eventi nei log e allarmare → metric filter + alarm: il subscription filter fa streaming, non genera direttamente un alarm; per far scattare una notifica su un pattern serve un metric filter che produce la metrica.
  • Inoltro near real-time dei log verso un altro account o un data lake → subscription filter: Logs Insights serve solo per query interattive e non instrada nulla verso destinazioni esterne.
  • Troppe notifiche simultanee durante un incident → composite alarm: aggrega più alarm con logica booleana in un unico segnale, invece di aumentare le evaluation periods e perdere reattività.
  • Individuare quale microservizio causa la latenza end-to-end → AWS X-Ray: metriche e log da soli non mostrano la catena di dipendenze; serve il distributed tracing con service map.
  • Centralizzare log da molti account → subscription filter verso Kinesis/Firehose nell’account centrale (o S3 con bucket policy): non copiare manualmente né affidarsi a Logs Insights cross-region come meccanismo di consolidamento.
  • Allarme reattivo al secondo → high-resolution custom metric + high-resolution alarm: la risoluzione standard a 1-5 minuti è troppo lenta per certi SLA operativi.