Perché l’osservabilità conta nel DVA-C02

Come sviluppatore cloud-native devi saper rispondere a tre domande su un’applicazione distribuita: cosa sta succedendo (metriche), perché (log) e dove si perde tempo lungo la catena di chiamate (tracing). L’esame — che si supera con un punteggio di 700/1000 — verte spesso su scenari di troubleshooting in cui devi scegliere lo strumento giusto fra AWS X-Ray, Amazon CloudWatch e le dead-letter queue. Confondere il loro ambito è la trappola più comune.

AWS X-Ray: tracing distribuito e latency

X-Ray serve a seguire una singola richiesta mentre attraversa più servizi (AWS Lambda, Amazon API Gateway, Amazon DynamoDB, chiamate HTTP a downstream). Ogni componente produce un segment; all’interno di un segment puoi creare subsegment custom per isolare porzioni di codice — ad esempio la chiamata a un database o a un’API esterna — e vedere esattamente dove si concentra la latency. La service map aggrega questi dati in un grafo visuale con tempi di risposta ed error rate per nodo, ideale per individuare il collo di bottiglia.

Punti che l’esame ama verificare:

  • Permessi: l’X-Ray daemon (o la execution role di Lambda con active tracing) deve poter chiamare PutTraceSegments e PutTelemetryRecords. La managed policy tipica è AWSXRayDaemonWriteAccess. Se i trace non compaiono, quasi sempre mancano questi permessi.
  • Daemon: su Lambda il supporto è integrato (basta abilitare il tracing); su Amazon EC2 o Amazon ECS devi eseguire tu il daemon.
  • Sampling: per contenere costi e overhead X-Ray non traccia il 100% delle richieste ma applica sampling rule (un reservoir di base più una percentuale del traffico aggiuntivo). Aumenti il campionamento solo dove serve.

Amazon CloudWatch: metriche, alarm e log

CloudWatch è il piano di monitoraggio. Le metriche possono essere quelle emesse nativamente dai servizi oppure custom metric che pubblichi tu (via PutMetricData o, in modo più efficiente, tramite l’Embedded Metric Format che estrae metriche direttamente dai log). Le metriche vivono in un namespace e sono qualificate da dimensions; la risoluzione standard è al minuto, quella high-resolution al secondo.

Gli alarm valutano una metrica contro una soglia e passano fra gli stati OK, ALARM e INSUFFICIENT_DATA, innescando azioni come una notifica Amazon SNS o un’azione di Auto Scaling. I log sono organizzati in log group e log stream; Lambda ci scrive automaticamente se la execution role ha i permessi di logging.

CloudWatch Logs Insights e troubleshooting

Per cercare dentro grandi volumi di log usi CloudWatch Logs Insights, un linguaggio di query interattivo (con fields, filter, stats, sort, limit) pensato per analisi ad hoc durante un incidente. È diverso da un metric filter, che invece estrae in modo continuativo una metrica da un pattern nei log: il metric filter serve per allarmare nel tempo, Logs Insights per investigare qui e ora.

Dead-letter queue: catturare i fallimenti

Quando una Lambda viene invocata in modo asincrono e la funzione fallisce, il servizio ritenta automaticamente (due retry dopo il primo tentativo). Se anche i retry falliscono, l’evento andrebbe perso: per non perderlo lo indirizzi a una dead-letter queue (una coda Amazon SQS o un topic Amazon SNS) oppure, opzione più moderna e ricca di contesto, a una on-failure destination. Per le code SQS consumate come event source, invece, i messaggi falliti tornano in coda e finiscono nella DLQ collegata solo dopo aver superato maxReceiveCount definito nella redrive policy. La DLQ non è un meccanismo di retry: è il posto dove ispezioni gli eventi problematici per il troubleshooting.

Trappole tipiche d’esame

  • I trace non compaiono in X-Ray → aggiungi i permessi, non altro codice: verifica che la role possa chiamare PutTraceSegments (policy AWSXRayDaemonWriteAccess); il codice instrumentato senza permessi resta muto.
  • Serve capire dove va la latency dentro una funzione → subsegment custom: un segment mostra il servizio, ma solo i subsegment isolano la singola chiamata lenta (es. la query DynamoDB) all’interno del codice.
  • Ricerca una tantum sui log durante un incidente → Logs Insights, non un metric filter: il metric filter è per allarmi continui nel tempo; per investigare on-demand usi le query di Logs Insights.
  • Invocazione asincrona Lambda che fallisce e non deve perdere l’evento → DLQ o on-failure destination: i retry da soli non bastano; la DLQ (SQS/SNS) o la destination catturano l’evento fallito per l’analisi.
  • Messaggi SQS che “spariscono” senza DLQ → configura redrive policy con maxReceiveCount: senza redrive policy e DLQ i messaggi ripetutamente falliti vengono scartati alla scadenza della retention.
  • Metrica applicativa non standard (es. business KPI) → custom metric, non una metrica di default: i servizi non emettono nativamente le tue metriche di dominio; devi pubblicarle tu (PutMetricData o Embedded Metric Format).