Amazon CloudWatch: metriche e custom metrics

CloudWatch raccoglie di default metriche per la maggior parte dei servizi AWS. Per EC2 le metriche native sono raccolte a livello di hypervisor: CPUUtilization, NetworkIn/NetworkOut, DiskReadOps sono disponibili senza alcun agent. Ma la memoria (RAM) e lo spazio del filesystem guest-OS non sono visibili all’hypervisor. Per ottenerle serve il CloudWatch agent installato dentro l’istanza, che pubblica custom metrics come mem_used_percent e disk_used_percent. L’agent si configura tipicamente tramite un file salvato in SSM Parameter Store e si distribuisce su flotte di istanze con AWS Systems Manager. Le custom metrics si organizzano per namespace e dimensioni; valuta il costo per metrica e la risoluzione (standard 1 minuto vs high-resolution fino a 1 secondo).

Alarm e tuning

Un CloudWatch alarm valuta una metrica su periodi consecutivi. I parametri chiave sono il Period (ampiezza del datapoint), gli Evaluation Periods (quanti periodi considerare) e i Datapoints to Alarm (logica M out of N: quanti dei periodi devono violare la soglia). Richiedere, ad esempio, 3 datapoint su 5 rende l’alarm più tollerante agli spike transitori e riduce i falsi positivi, senza dover semplicemente allargare il periodo.

Il trattamento del missing data è una decisione operativa cruciale: notBreaching (il dato mancante non contribuisce alla violazione), breaching (lo tratta come violazione), ignore (mantiene lo stato precedente) e missing (default). Per metriche sporadiche o custom che possono avere buchi, imposta notBreaching per evitare alarm che scattano solo perché non arrivano datapoint.

Gli alarm attivano azioni: notifica SNS, azioni EC2 (recover, stop, terminate, reboot) o Auto Scaling. L’azione recover è tipica quando fallisce il system status check (problema sull’infrastruttura AWS sottostante), mentre l’instance status check failed indica problemi interni all’istanza. Un composite alarm aggrega più alarm con logica booleana per ridurre il rumore delle notifiche.

CloudWatch Logs: metric filter, subscription filter, Logs Insights

CloudWatch Logs centralizza i log; il CloudWatch agent invia i log applicativi e di sistema ai log group. Un metric filter estrae un pattern dai log e lo trasforma in una metrica CloudWatch numerica, su cui poi costruire un alarm (es. contare le occorrenze di ERROR o di 404 e allarmare oltre soglia). Serve quando devi allarmare su qualcosa presente nei log ma non esposto come metrica.

Un subscription filter, invece, fa streaming in tempo reale dei log verso una destinazione (Lambda, Kinesis Data Streams, Firehose, OpenSearch) per elaborazione o archiviazione downstream. Sono due strumenti diversi: uno crea metriche, l’altro instrada il flusso.

Logs Insights è il linguaggio di query ad hoc per l’analisi interattiva: ideale per troubleshooting puntuale (filtrare, aggregare, stats) senza creare metriche permanenti. Ricorda le retention policy dei log group: di default i log non scadono mai, generando costi crescenti.

AWS X-Ray: distributed tracing

X-Ray fornisce il distributed tracing per applicazioni, in particolare microservizi. Traccia le richieste end-to-end producendo una service map e evidenziando latenza, error e fault per ogni segmento. Mentre CloudWatch risponde a “questo componente è sano?” e i log a “cosa è successo qui?”, X-Ray risponde a “in quale punto della catena di chiamate c’è il collo di bottiglia?”. Richiede instrumentazione (X-Ray SDK/daemon o AWS Distro for OpenTelemetry); servizi come API Gateway e Lambda offrono instrumentazione integrata attivabile.

Trappole tipiche d’esame

  • Metrica memoria/disco EC2 mancante → CloudWatch agent: RAM e filesystem guest-OS non esistono senza agent, perché l’hypervisor non li vede. Distribuisci il CloudWatch agent via Systems Manager.
  • Alarm scatta per assenza di dati → treat missing data as notBreaching: su metriche sporadiche imposta notBreaching per non far scattare falsi allarmi quando semplicemente non arrivano datapoint.
  • Troppi falsi positivi su spike → Datapoints to Alarm (M out of N): aumenta i datapoint richiesti (es. 3 su 5) invece di allargare solo Evaluation Periods.
  • Allarmare su una stringa nei log → metric filter, non subscription filter: il subscription filter fa streaming/elaborazione, il metric filter crea la metrica su cui costruire l’alarm.
  • Analisi interattiva sui log senza metriche permanenti → Logs Insights: per troubleshooting ad hoc non serve creare un metric filter.
  • Latenza distribuita fra microservizi → AWS X-Ray: CloudWatch mostra la salute del singolo componente, X-Ray la service map end-to-end per isolare il bottleneck.