Amazon DVA-C02: Monitoraggio, Logging e Debugging (CloudWatch, X-Ray, Tracciamento, Allarmi) — Guida allo studio
Fa parte della AWS Developer Associate DVA-C02 — Guida allo studio. Esercitati con risposte verificate nel centro esami Amazon, oppure fai test cronometrati su ExamRoll.io.
Log, Metriche e Filtri di Metrica di CloudWatch
CloudWatch Logs è la pipeline principale per la telemetria delle applicazioni e della piattaforma; gli sviluppatori dovrebbero progettare i log in modo strutturato (JSON) affinché Metrics e Insights possano analizzarli in modo affidabile. Per le metriche personalizzate delle applicazioni, preferire il CloudWatch Embedded Metric Format (EMF) o
undefined
per esigenze di dimensioni immediate e alta risoluzione; EMF incorpora JSON _aws nelle righe di log e consente a CloudWatch di estrarre più metriche in una singola chiamata
undefined
per efficienza in termini di costi e throughput. Quando è necessario derivare metriche da log testuali lato servizio, creare filtri di metrica (
undefined
) su un gruppo di log che mappano i pattern di filtro a
undefined
; questi producono metriche CloudWatch che possono essere visualizzate in grafici e usate per gli allarmi. Le API operative comuni sono
undefined
,
undefined
e
undefined
(fare attenzione ai limiti di
undefined
e alla dimensione del batch di
undefined
), e
undefined
per associare una chiave KMS gestita dal cliente a un gruppo di log per la crittografia at-rest. Attenzione a IAM:
undefined
e
undefined
richiedono autorizzazioni esplicite, e le concessioni (grant) di KMS devono consentire al service principal di utilizzare le chiavi per la crittografia. Utilizzare le policy di conservazione (retention policy) per controllare i costi e preferire le metriche ad alta risoluzione (
undefined
con
undefined
) solo quando è necessaria una visibilità inferiore al minuto.
Tracing e X-Ray per Sistemi Distribuiti
Il tracciamento distribuito (distributed tracing) strumenta i flussi di richieste tra i servizi per rivelare dove si verificano latenza ed errori; AWS X-Ray è l’opzione integrata. Abilitare il tracciamento attivo (Active tracing) sulle funzioni Lambda (Lambda
undefined
undefined
) e abilitare X‑Ray per gli stage di API Gateway per propagare l’header di traccia di X‑Ray. Utilizzare l’SDK di AWS X‑Ray nel proprio runtime (
undefined
per Node,
undefined
per Python,
undefined
per Java) per creare sottosegmenti (subsegment), aggiungere annotazioni (indicizzate, valori piccoli) e metadati (non indicizzati, oggetti più grandi). Catturare le chiamate SDK downstream eseguendo il wrapping dei client AWS SDK con il recorder di X‑Ray, in modo che l’SDK strumenta automaticamente le richieste a S3, DynamoDB e le chiamate HTTP. Per i carichi di lavoro containerizzati, eseguire il demone X‑Ray come sidecar o utilizzare il layer del demone; accetta pacchetti UDP (porta predefinita 2000) e li raggruppa in batch per inviarli al servizio X‑Ray. Configurare le regole di campionamento (
undefined
) per evitare il rumore, ma regolare le regole o usare l’override dell’SDK per i flussi critici che si desidera tracciare sempre. Prestare attenzione ai limiti di dimensione dei documenti di segmento e non inserire mai PII nelle annotazioni, poiché sono indicizzate e ricercabili.
Progettazione di Allarmi, Notifiche e Alerting
Gli allarmi dovrebbero rilevare eventi che richiedono un’azione (actionable), ridurre il rumore e integrarsi con i runbook. Utilizzare i CloudWatch Alarms su metriche native, metriche personalizzate (da
undefined
o filtri di metrica) o espressioni di metrica matematica (metric math); ottimizzare
undefined
e
undefined
per evitare il “flapping” (stati intermittenti) e preferire allarmi compositi per condizioni multi-segnale (servizio downstream non funzionante + aumento del tasso di errore) per ridurre il volume degli alert. Le azioni degli allarmi possono pubblicare su topic SNS per workflow umani o di automazione, invocare Auto Scaling o Systems Manager OpsCenter (creando
undefined
), oppure instradare tramite regole EventBridge per playbook complessi (sorgente:
undefined
). Per esigenze rapide di reperibilità (on-call), usare SNS -> endpoint HTTP o l’integrazione con PagerDuty; per la remediation automatizzata, usare EventBridge -> Step Functions o Lambda con il principio del privilegio minimo (least-privilege) IAM. Considerare i modelli di rilevamento delle anomalie (anomaly detection) per definire una baseline del traffico e impostare soglie di stato OK con isteresi. Le trappole comuni includono la creazione di troppi allarmi con dimensioni (esplosione dei costi di monitoraggio), l’affidarsi esclusivamente a trigger basati su un singolo punto dati e la mancata messa in sicurezza dei topic di notifica (policy di accesso SNS) per evitare che gli alert vengano divulgati a destinatari non autorizzati.
Pattern di Risoluzione dei Problemi e Best Practice per SDK/API
Iniziate la risoluzione dei problemi inquadrando una timeline prevista rispetto a quella osservata, quindi correlate log, metriche e tracce. Utilizzate CloudWatch Logs Insights per query ad-hoc (campi @timestamp, @message | parse … | stats count() by bin(1m)) per trovare picchi e poi passare alle tracce X-Ray per latenze dettagliate. Per le API supportate da Lambda, verificate i cold start, i tempi di collegamento delle ENI VPC (per funzioni in una VPC) e se sono configurate Lambda Destinations o DLQ per catturare le invocazioni asincrone fallite. Per catturare le invocazioni fallite, usate Lambda Destinations (onFailure verso SNS, SQS o EventBridge) o una DLQ asincrona per preservare i payload. Quando si strumenta il codice, gestite il throttling delle API implementando l’exponential backoff con jitter e monitorando gli errori 429 tramite filtri di metrica o contatori EMF. Errori comuni: PutLogEvents richiede il sequence token corretto e prima CreateLogStream; PutMetricData può subire throttling—raggruppate ed emettete metriche aggregate; X-Ray richiede i permessi xray:PutTraceSegments e xray:PutTelemetryRecords (policy gestita AWSXRayDaemonWriteAccess); e il campionamento potrebbe nascondere problemi a meno che non si modifichino le regole per flussi a bassa frequenza ma critici.
Problema Pratico: Scenario d’Uso
Scenario: Acme Retail gestisce un servizio di checkout serverless su AWS utilizzando API Gateway -> Lambda -> DynamoDB. Il team utilizza log CloudWatch e X-Ray centralizzati, ma mancano metriche di throughput dei dispositivi al minuto e necessita di allarmi affidabili sui picchi di latenza delle API senza creare allarmi superflui.
Sfida: Acquisire conteggi quasi in tempo reale di dispositivi/messaggi al minuto, garantire il tracciamento end-to-end per le richieste lente e creare un allarme a basso rumore che attivi una Lambda di remediation automatizzata e notifichi il personale di turno.
Approccio Raccomandato:
- Strumentare la Lambda di checkout per emettere una metrica personalizzata ad alta risoluzione utilizzando l’API PutMetricData con Namespace=Acme/Checkout, MetricName=DeviceReportsPerMinute, Timestamp=now, Value=1 e StorageResolution=1; raggrupparli in memoria e inviarli ogni 30 secondi per evitare il throttling dell’API.
- Incorporare anche JSON EMF nei log di Lambda per dimensioni più ricche (customerId, region) e affidarsi a CloudWatch Logs per estrarre metriche aggiuntive tramite PutLogEvents e filtri di metrica (PutMetricFilter) per i conteggi degli errori.
- Abilitare il tracciamento X-Ray: impostare TracingConfig Mode della Lambda su Active, abilitare X-Ray sullo stage di API Gateway e utilizzare l’SDK X-Ray per aggiungere annotazioni (non PII) e sottosegmenti attorno alle chiamate HTTP esterne verso API di terze parti.
- Creare un Allarme composito di CloudWatch che combini una metrica elevata di latenza al 95° percentile (metric math) con un picco in DeviceReportsPerMinute; impostare EvaluationPeriods=3, DatapointsToAlarm=2, Action su un topic SNS che attiva un endpoint per il personale di turno più una regola EventBridge che invoca una Lambda di remediation (ruolo con i privilegi minimi indispensabili).
Logica: L’emissione di metriche ad alta risoluzione e EMF fornisce sia conteggi immediati al minuto sia una dimensionalità più ricca; X-Ray fornisce la causa radice della latenza fino alle chiamate downstream; gli allarmi compositi riducono il rumore richiedendo condizioni correlate prima di allertare e consentono l’automazione tramite EventBridge.
← Sicurezza · Tutti i domini · Archiviazione →
Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Supera l'esame →