Amazon DEA-C01: Monitoring en probleemoplossing van datapipelines — Studiegids

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

Onderdeel van de Amazon Data Engineer Associate DEA-C01 — Studiegids. Oefen met geverifieerde antwoorden in het Amazon-examencentrum, of doe getimede oefentests op ExamRoll.io.

Monitoring en troubleshooting van datapipelines is cruciaal om een tijdige en accurate levering van streaming- en batchdata binnen AWS te garanderen. Dit domein omvat de telemetrie, alarmering en diagnostische technieken voor services zoals Kinesis, Firehose, Glue, DMS, Lambda, en de AWS audit trails die incidentonderzoek ondersteunen. Effectieve monitoring reduceert de Mean Time To Detect/Recover door het blootleggen van consumer lag, resource-druk op jobs, leveringslatentie en ongeautoriseerde toegang. De volgende secties geven concrete signalen, CLI/console-patronen en beslissingscriteria om productie-dataflows te beheren en te herstellen.

CloudWatch metrics en alarmen voor dataservices

CloudWatch is de primaire telemetrie-laag: maak metric filters, dashboards en alarmen aan voor belangrijke service-metrics en integreer alarmen met SNS, EventBridge of Systems Manager voor geautomatiseerd herstel. Gebruik aws cloudwatch put-metric-alarm om alarmen programmatisch aan te maken; typische flags zijn –metric-name, –namespace, –statistic (of –extended-stat), –threshold, –evaluation-periods en –comparison-operator. Voor dashboards kunt u custom metrics (bijv. uit Glue job-metadata) pushen met aws cloudwatch put-metric-data en een namespace zoals “MyCompany/DataPipeline”.

Focus op deze bruikbare metrics en patronen:

Glue: monitor BytesRead, BytesWritten, RecordsProcessed en DPUHrs om veranderingen in datavolume, skew en kosten te detecteren. Alarmen: een plotselinge daling in RecordsProcessed of pieken in DPUHrs per record.
Kinesis: monitor GetRecords.IteratorAgeMilliseconds voor consumer lag en IncomingBytes/IncomingRecords voor brondruk.
Firehose: monitor DeliveryToS3.DataFreshness en DeliveryToS3.Records om leveringslatentie en dataverlies te signaleren.
DMS: monitor FullLoadRows, CDCLatencyMilliseconds en AppliedChanges voor de replicatiestatus.

Beslissingscriteria voor alarmering:

Gebruik samengestelde alarmen (CloudWatch composite alarms) om ruis te verminderen: combineer IteratorAgeMilliseconds > X voor 3 datapunten EN een consumer error rate > Y.
Voor de selectie van drempelwaarden: leid basislijnen af uit 7–14 dagen aan historische data en stel dynamische drempelwaarden in met behulp van anomaliedetectiemodellen (PutAnomalyDetector) wanneer workloads seizoensgebonden zijn.

Monitoring en foutafhandeling van Glue-jobs

Glue verstuurt metrics naar CloudWatch en schrijft logs naar /aws-glue/jobs/output (job run logs) en /aws-glue/jobs/error (fouten). Gebruik CloudWatch Logs Insights om job runs te query’en: voer query’s uit via de console of met aws logs start-query met een query string zoals fields @timestamp, @message | filter @message like /ERROR/ | sort @timestamp desc | limit 20. Volg BytesRead, BytesWritten, RecordsProcessed en DPUHrs uit de Glue job run metrics—DPUHrs correleert direct met de kosten en de parallelliteit van de job.

Veelvoorkomende Glue-fouten en herstelmaatregelen:

OutOfMemory (OOM) of Executor lost: verhoog het worker-type/aantal DPU’s, schakel over naar het G.2X worker-type voor zwaarder geheugengebruik, of optimaliseer Spark-partitionering (repartition/coalesce) en gebruik pushdown predicates om het inputvolume te verminderen.
Data-skew die ‘stragglers’ (achterblijvers) veroorzaakt: gebruik partitiesleutels om te herverdelen, verhoog de parallelliteit, of gebruik waar van toepassing de split/resolve-keuzes van Glue DynamicFrame.
Job loopt vast of start traag op: schakel job bookmarks in en monitor Glue JobMetrics voor “TimeWaitingForResources” om capaciteitsconflicten te identificeren.

Afwegingen bij beslissingen:

Verhoog het aantal DPU’s wanneer CPU/geheugen de bottleneck is en de voorspelbaarheid van de runtime belangrijk is; geef de voorkeur aan code-optimalisaties (partitionering, alleen cachen wanneer nodig) als de kosten beheerst moeten worden.
Gebruik Glue streaming voor near-real-time transformaties; gebruik Glue ETL batch voor complexe Spark-transformaties en grotere workloads die geschikt zijn voor spot instances.

Monitoring van Kinesis en Firehose

Kinesis Consumer Lag: vertrouw op GetRecords.IteratorAgeMilliseconds om te detecteren hoe ver consumers achterlopen. Als GetRecords.IteratorAgeMilliseconds consistent hoog is:

Schaal op door het aantal shards te verhogen (reshard/scale), of
Verbeter de prestaties van de consumer door te batchen, gebruik te maken van enhanced fan-out (voor een doorvoersnelheid per consumer tot 2 MB/sec) of de Kinesis Client Library (KCL) v2 met verbeterde checkpointing.

Gebruik aws kinesis describe-stream om het aantal shards te inspecteren en aws cloudwatch get-metric-statistics voor IteratorAgeMilliseconds. Houd bij het vergelijken van herstelopties rekening met het volgende:

Shards toevoegen: verhoogt de ingest- en leesdoorvoer; vereist resharding en herverdeling.
Enhanced fan-out: vermijdt gedeelde leesdoorvoer, maar verhoogt de kosten per consumer.
Consumer-optimalisatie: vermindert de noodzaak voor extra shards en kosten, maar vereist engineering-inspanning.

Firehose leveringsmetrics: DeliveryToS3.DataFreshness kwantificeert de leveringslatentie; typische buffering_delay-instellingen zijn 60–900 seconden en houden records vast totdat bufferSize of bufferInterval is bereikt. Als DeliveryToS3.DataFreshness hoog is:

Controleer de Firehose buffer hints (BufferIntervalInSeconds, BufferSizeInMBs) in de console of via aws firehose describe-delivery-stream.
Inspecteer CloudWatch Errors (DeliveryToS3.RecordsFailed) en S3-bucketpermissies (KMS-fouten indien versleuteld).

Onthoud de buffer-semantiek van Firehose: de service vertraagt opzettelijk tot het bufferinterval; verlaag het bufferinterval om de latentie te verkleinen, ten koste van frequentere schrijfacties naar S3.

CloudTrail en auditing van datatoegang

CloudTrail levert API-activiteit en, optioneel, data-events voor S3 en Lambda, die niet standaard zijn ingeschakeld. Om S3-events op objectniveau vast te leggen, moet je expliciet data-events inschakelen op de CloudTrail via de console of met aws cloudtrail create-trail --include-global-service-events en S3-dataresources toevoegen. Zonder S3 data-events in te schakelen, zie je geen GetObject/PutObject in CloudTrail, wat een veelvoorkomend hiaat is tijdens onderzoeken.

Gebruik CloudTrail-logs in combinatie met CloudWatch Logs Insights om operationele metrics (bijv. logs van Glue-jobs) te correleren met toegangs-events. Query-patronen:

CloudWatch Logs Insights: filter @message like /GetObject/ | stats count() by userIdentity.principalId
Gebruik EventBridge-regels om te reageren op specifieke API-calls (bijv. PutBucketAcl) en stuur deze door naar SNS voor snelle alarmering.

DMS-replicatietaken publiceren ook CloudWatch-metrics: monitor FullLoadRows voor de volledigheid van de initiële kopie, CDCLatencyMilliseconds om replicatievertraging (lag) te detecteren, en AppliedChanges om te verzekeren dat transacties worden toegepast op de doel-database. Stel een alarm in voor CDCLatencyMilliseconds die de zakelijke SLA’s overschrijden en voor lage AppliedChanges na een toename in het aantal ‘full load rows’.

Veelvoorkomende valkuilen en beslissingscriteria

Hoge IteratorAgeMilliseconds op Kinesis wordt onterecht aangezien voor problemen aan de bron — juiste aanpak: controleer de checkpointing en verwerkingstijd van de consumer; schaal op door shards toe te voegen of gebruik enhanced fan-out pas na het profilen van de CPU/IO van de consumer.
OOM-fouten (Out of Memory) in Glue-jobs worden aangepakt door blindelings het aantal DPU’s te verhogen — juiste aanpak: profileer de Spark-stages, optimaliseer partitionering en datafiltering; verhoog het aantal DPU’s of het worker-type alleen als is bevestigd dat resourcelimieten worden bereikt.
Vertraging door buffering in Firehose veroorzaakt vermeend dataverlies — juiste aanpak: verifieer BufferIntervalInSeconds en BufferSizeInMBs; verlaag het interval voor lage-latentie-eisen en accepteer de hogere schrijfvolumes/kosten.
Aannemen dat CloudTrail standaard S3-object-leesacties registreert — juiste aanpak: schakel S3 data-events in CloudTrail in om GetObject/PutObject vast te leggen voor forensische audits.
Ontbrekende alarmen voor DMS CDC-lag — juiste aanpak: maak CloudWatch-alarmen aan voor CDCLatencyMilliseconds en vergelijk AppliedChanges met FullLoadRows; onderzoek het netwerk of de transactie-backlog wanneer de vertraging toeneemt.
Te veel alarmering bij tijdelijke pieken — juiste aanpak: gebruik evaluatieperioden, ‘datapoints-to-alarm’ of ‘anomaly detection’ om ruis te verminderen en gebruik ‘composite alarms’ voor gecorreleerde condities.

Praktijkprobleem: Use-Case Scenario

Acme Analytics voert real-time clickstream-ingestie uit via Kinesis, verrijkt events met Glue ETL-jobs, persisteert verouderde batches via Firehose naar S3, en repliceert legacy databases met DMS. Ze constateren end-to-end vertragingen: consumer-lag op Kinesis, OOM-fouten bij Glue-jobs, en Firehose die een hoge DeliveryToS3.DataFreshness laat zien.

Profileer Kinesis-consumers: haal de GetRecords.IteratorAgeMilliseconds-metric op, inspecteer de consumer-logs, en voer een kostenanalyse uit van Kinesis enhanced fan-out versus het opschalen van shards.
Onderzoek de CloudWatch-metrics en Logs Insights van de Glue-job op OOM-stacktraces; test herpartitionering + ‘pushdown predicate’ lokaal of in een kleinere job; verhoog pas daarna het aantal DPU’s/worker-type indien nodig.
Inspecteer de bufferinstellingen van Firehose (BufferIntervalInSeconds) en DeliveryToS3.DataFreshness; verlaag het bufferinterval voor kritieke SLO’s en valideer de S3-schrijfrechten/KMS.
Configureer CloudWatch ‘composite alarms’ die IteratorAgeMilliseconds, de foutratio van de Glue-job en Firehose DataFreshness combineren; lever de meldingen af bij een on-call SNS-topic en trigger een runbook via EventBridge.
Schakel CloudTrail S3 data-events in en correleer GetObject/PutObject-events met de starttijden van Glue-jobs en DMS ‘applied changes’ om ongeautoriseerde of vertraagde toegang te detecteren.

Deze aanpak volgt de best practices van AWS: monitor de juiste service-metrics op de correcte granulariteit, geef de voorkeur aan gerichte oplossingen in code en configuratie voordat je resources opschaalt, en zorg ervoor dat logging op auditniveau expliciet is ingeschakeld om snelle root-cause-analyse en geautomatiseerde herstelacties mogelijk te maken.

← Databeveiliging · Alle domeinen · Kostenoptimalisatie voor dataworkloads →

Oefen deze vragen → · Getimede oefening op ExamRoll.io →