Amazon DEA-C01: Monitoraggio e risoluzione dei problemi delle pipeline di dati — Guida allo studio

By Laurynas Brazys · 2 August 2026 · #amazon #dea-c01 #certification #exam-prep #study-guide

Fa parte della Amazon Data Engineer Associate DEA-C01 — Guida allo studio. Esercitati con risposte verificate nel centro esami Amazon, oppure fai test cronometrati su ExamRoll.io.

Il monitoraggio e la risoluzione dei problemi delle pipeline di dati sono fondamentali per garantire la consegna puntuale e accurata di dati in streaming e batch su AWS. Questo dominio copre le tecniche di telemetria, alerting e diagnostica per servizi come Kinesis, Firehose, Glue, DMS, Lambda e le tracce di audit di AWS che supportano l’indagine sugli incidenti. Un monitoraggio efficace riduce il tempo medio di rilevamento/ripristino (Mean Time To Detect/Recover) esponendo il ritardo dei consumer (consumer lag), la pressione sulle risorse dei job, la latenza di consegna e gli accessi non autorizzati. Le sezioni seguenti forniscono segnali concreti, pattern per la CLI/console e criteri decisionali per operare e risolvere i problemi (remediate) dei flussi di dati di produzione.

Metriche e allarmi CloudWatch per i servizi di dati

CloudWatch è il piano di telemetria primario: crea filtri per le metriche, dashboard e allarmi per le metriche chiave dei servizi e integra gli allarmi con SNS, EventBridge o Systems Manager per una remediation automatizzata. Usa

undefined

per creare allarmi programmaticamente; i flag tipici includono --metric-name, --namespace, --statistic (o --extended-stat), --threshold, --evaluation-periods e --comparison-operator. Per le dashboard, invia metriche personalizzate (ad esempio, dai metadati dei job Glue) usando

undefined

con un namespace come “MyCompany/DataPipeline”.

Concentrati su queste metriche e pattern utilizzabili (actionable):

Glue: monitora BytesRead, BytesWritten, RecordsProcessed e DPUHrs per rilevare variazioni del volume dei dati, skew (asimmetria) e costi. Allarmi: calo improvviso di RecordsProcessed o picchi di DPUHrs per record.
Kinesis: monitora GetRecords.IteratorAgeMilliseconds per il ritardo del consumer (consumer lag) e IncomingBytes/IncomingRecords per la pressione sulla sorgente.
Firehose: monitora DeliveryToS3.DataFreshness e DeliveryToS3.Records per individuare la latenza di consegna e la perdita di dati.
DMS: monitora FullLoadRows, CDCLatencyMilliseconds e AppliedChanges per lo stato di salute della replica.

Criteri decisionali per l’alerting:

Usa allarmi compositi (CloudWatch composite alarms) per ridurre il rumore: combina IteratorAgeMilliseconds > X per 3 punti dati E tasso di errore del consumer > Y.
Per la selezione della soglia, deriva le baseline da dati storici di 7–14 giorni e imposta soglie dinamiche utilizzando modelli di rilevamento delle anomalie (PutAnomalyDetector) quando i carichi di lavoro sono stagionali.

Monitoraggio e gestione degli errori dei job Glue

Glue emette metriche su CloudWatch e scrive log in /aws-glue/jobs/output (log di esecuzione del job) e /aws-glue/jobs/error (errori). Usa CloudWatch Logs Insights per interrogare le esecuzioni dei job: esegui query tramite la console o

undefined

con una stringa di query come

undefined

. Tieni traccia di BytesRead, BytesWritten, RecordsProcessed e DPUHrs dalle metriche di esecuzione del job Glue: DPUHrs è direttamente correlato al costo e al parallelismo del job.

Modalità di fallimento comuni di Glue e remediation:

OutOfMemory (OOM) o Executor lost: aumenta il tipo di worker/numero di DPU, passa al tipo di worker G.2X per un maggiore utilizzo di memoria, oppure ottimizza il partizionamento di Spark (repartition/coalesce) e usa i pushdown predicates per ridurre il volume di input.
Skew dei dati che causa “stragglers” (esecuzioni lente): usa chiavi di partizione per ribilanciare, aumenta il parallelismo o usa le opzioni split/resolve di Glue DynamicFrame dove appropriato.
Stalli del job o avvio lento: abilita i bookmark del job e monitora le JobMetrics di Glue per “TimeWaitingForResources” per identificare la contesa di capacità.

Compromessi decisionali:

Aumenta le DPU quando CPU/memoria sono il bottleneck e la prevedibilità del tempo di esecuzione è importante; preferisci ottimizzazioni del codice (partizionamento, caching solo quando necessario) se i costi devono essere controllati.
Usa Glue streaming per trasformazioni quasi in tempo reale; usa Glue ETL batch per trasformazioni Spark complesse e carichi di lavoro più grandi e adatti a istanze Spot.

Monitoraggio di Kinesis e Firehose

Ritardo del Consumer (Consumer Lag) di Kinesis: affidati a GetRecords.IteratorAgeMilliseconds per rilevare quanto sono indietro i consumer. Se GetRecords.IteratorAgeMilliseconds è costantemente alto:

Scala aumentando il numero di shard (reshard/scale), oppure
Migliora le prestazioni del consumer tramite il batching, usando l’enhanced fan-out (per un throughput per consumer fino a 2 MB/sec) o la Kinesis Client Library (KCL) v2 con checkpointing migliorato.

Usa

undefined

per ispezionare il numero di shard e

undefined

per IteratorAgeMilliseconds. Nel confrontare le opzioni di remediation, considera:

Aggiungere shard: aumenta il throughput di ingestione e lettura; richiede resharding e ribilanciamento.
Enhanced fan-out: evita il throughput di lettura condiviso ma aumenta il costo per consumer.
Ottimizzazione del consumer: riduce la necessità di shard aggiuntivi e i costi, ma richiede uno sforzo di ingegneria.

Metriche di consegna di Firehose: DeliveryToS3.DataFreshness quantifica la latenza di consegna; le impostazioni tipiche di buffering_delay sono 60–900 secondi e tratterranno i record finché non viene raggiunto bufferSize o bufferInterval. Se DeliveryToS3.DataFreshness è alto:

Controlla i suggerimenti di buffering (buffer hints) di Firehose (BufferIntervalInSeconds, BufferSizeInMBs) nella console o tramite

undefined

Ispeziona gli errori di CloudWatch (DeliveryToS3.RecordsFailed) e i permessi del bucket S3 (errori KMS se crittografato).

Ricorda la semantica del buffering di Firehose: il servizio ritarda intenzionalmente fino all’intervallo di buffer; riduci l’intervallo di buffer per diminuire la latenza, al costo di scritture più frequenti su S3.

CloudTrail e audit dell’accesso ai dati

CloudTrail fornisce l’attività delle API e, opzionalmente, gli eventi dati per S3 e Lambda, che non sono abilitati di default. Per catturare gli eventi a livello di oggetto S3, abilita esplicitamente gli eventi dati su CloudTrail tramite la console o con il comando aws cloudtrail create-trail --include-global-service-events e aggiungi le risorse dati di S3. Senza abilitare gli eventi dati di S3 non vedrai GetObject/PutObject in CloudTrail, una lacuna comune durante le indagini.

Usa i log di CloudTrail in combinazione con CloudWatch Logs Insights per correlare le metriche operative (es. i log dei job di Glue) con gli eventi di accesso. Pattern di query:

CloudWatch Logs Insights: filter @message like /GetObject/ | stats count() by userIdentity.principalId
Usa le regole di EventBridge per reagire a chiamate API specifiche (es. PutBucketAcl) e inoltrarle a SNS per avvisi rapidi.

Anche i task di replica di DMS pubblicano metriche su CloudWatch: monitora FullLoadRows per la completezza della copia iniziale, CDCLatencyMilliseconds per rilevare il ritardo di replica (replication lag) e AppliedChanges per assicurarsi che le transazioni vengano applicate sulla destinazione. Imposta allarmi su CDCLatencyMilliseconds quando supera gli SLA aziendali e su un basso valore di AppliedChanges dopo un aumento delle righe del full load.

Errori Comuni e Criteri Decisionali

Un valore elevato di IteratorAgeMilliseconds su Kinesis scambiato per problemi alla sorgente — approccio corretto: controllare il checkpointing e il tempo di elaborazione del consumer; scalare aggiungendo shard o usare l’enhanced fan-out solo dopo aver profilato la CPU/IO del consumer.
Errori OOM (Out of Memory) nei job di Glue gestiti aumentando ciecamente le DPU — approccio corretto: profilare gli stage di Spark, ottimizzare il partizionamento e il filtraggio dei dati; aumentare le DPU o il tipo di worker solo se i limiti delle risorse sono confermati.
Ritardo nel buffering di Firehose che causa una percepita perdita di dati — approccio corretto: verificare BufferIntervalInSeconds e BufferSizeInMBs; ridurre l’intervallo per esigenze a bassa latenza e accettare tassi di scrittura/costi più elevati.
Presumere che CloudTrail registri di default le letture degli oggetti S3 — approccio corretto: abilitare gli eventi dati di S3 in CloudTrail per catturare GetObject/PutObject per audit forensi.
Mancanza di allarmi sul lag CDC di DMS — approccio corretto: creare allarmi CloudWatch su CDCLatencyMilliseconds e confrontare AppliedChanges con FullLoadRows; investigare la rete o il backlog delle transazioni quando il lag aumenta.
Eccesso di allarmi per picchi transitori — approccio corretto: usare periodi di valutazione (evaluation-periods), punti dati per allarme (datapoint-to-alarm) o il rilevamento delle anomalie per ridurre il rumore e usare allarmi compositi (composite alarms) per condizioni correlate.

Problema Pratico: Scenario d’Uso

Acme Analytics esegue l’ingestion in tempo reale di clickstream tramite Kinesis, arricchisce gli eventi usando job ETL di Glue, persiste i batch obsoleti su S3 tramite Firehose e replica i DB legacy con DMS. Osservano ritardi end-to-end: lag dei consumer su Kinesis, OOM nei job di Glue e Firehose che mostra un valore elevato per DeliveryToS3.DataFreshness.

Profilare i consumer di Kinesis: ottenere la metrica GetRecords.IteratorAgeMilliseconds, ispezionare i log dei consumer ed eseguire un’analisi dei costi confrontando l’enhanced fan-out di Kinesis con lo scaling degli shard.
Esaminare le metriche CloudWatch e i Logs Insights del job di Glue per le stack trace degli errori OOM; testare il ripartizionamento e il pushdown predicate localmente o in un job più piccolo; solo allora aumentare le DPU/il tipo di worker se necessario.
Ispezionare le impostazioni del buffer di Firehose (BufferIntervalInSeconds) e la metrica DeliveryToS3.DataFreshness; ridurre l’intervallo del buffer per gli SLO critici e validare i permessi di scrittura su S3/KMS.
Configurare allarmi compositi (composite alarms) su CloudWatch che combinino IteratorAgeMilliseconds, il tasso di errore dei job di Glue e la metrica DataFreshness di Firehose; inviare gli allarmi a un topic SNS di reperibilità e avviare un runbook tramite EventBridge.
Abilitare gli eventi dati di S3 in CloudTrail e correlare gli eventi GetObject/PutObject con gli orari di avvio dei job di Glue e gli applied changes di DMS per rilevare accessi non autorizzati o ritardati.

Questo approccio segue le best practice di AWS: monitorare le metriche di servizio corrette con la giusta granularità, preferire correzioni mirate al codice e alla configurazione prima di scalare le risorse e assicurarsi che il logging a livello di audit sia abilitato esplicitamente per consentire un’analisi rapida della causa radice (root-cause analysis) e una remediation automatizzata.

← Sicurezza dei dati · Tutti i domini · Ottimizzazione dei costi per i carichi di lavoro dei dati →

Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →