Amazon DEA-C01: Überwachung und Fehlerbehebung von Datenpipelines — Lernleitfaden

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

Teil des Amazon Data Engineer Associate DEA-C01 — Lernleitfaden. Üben Sie mit verifizierten Antworten im Amazon-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Die Überwachung und Fehlerbehebung von Datenpipelines ist entscheidend, um die rechtzeitige und genaue Bereitstellung von Streaming- und Batch-Daten in AWS sicherzustellen. Dieser Bereich umfasst die Telemetrie-, Alarmierungs- und Diagnoseverfahren für Dienste wie Kinesis, Firehose, Glue, DMS, Lambda sowie die AWS-Audit-Protokolle, die die Untersuchung von Vorfällen unterstützen. Eine effektive Überwachung reduziert die mittlere Zeit bis zur Erkennung/Wiederherstellung (Mean Time To Detect/Recover), indem sie Consumer-Lag, Ressourcendruck bei Jobs, Zustelllatenz und unbefugten Zugriff aufdeckt. Die folgenden Abschnitte bieten konkrete Signale, CLI/Konsolen-Muster und Entscheidungskriterien für den Betrieb und die Behebung von Produktions-Datenflüssen.

CloudWatch-Metriken und -Alarme für Datendienste

CloudWatch ist die primäre Telemetrie-Ebene: Erstellen Sie Metrikfilter, Dashboards und Alarme für wichtige Dienstmetriken und integrieren Sie Alarme mit SNS, EventBridge oder Systems Manager für eine automatisierte Behebung. Verwenden Sie aws cloudwatch put-metric-alarm, um Alarme programmgesteuert zu erstellen; typische Flags sind --metric-name, --namespace, --statistic (oder --extended-stat), --threshold, --evaluation-periods und --comparison-operator. Für Dashboards können Sie benutzerdefinierte Metriken (z. B. aus Glue-Job-Metadaten) mit aws cloudwatch put-metric-data und einem Namespace wie „MyCompany/DataPipeline“ übertragen.

Konzentrieren Sie sich auf diese handlungsrelevanten Metriken und Muster:

Glue: Überwachen Sie BytesRead, BytesWritten, RecordsProcessed und DPUHrs, um Änderungen des Datenvolumens, Daten-Skew (Schieflage) und Kosten zu erkennen. Alarme: plötzlicher Abfall bei RecordsProcessed oder Spitzen bei DPUHrs pro Datensatz.
Kinesis: Überwachen Sie GetRecords.IteratorAgeMilliseconds für Consumer-Lag und IncomingBytes/IncomingRecords für den Druck auf der Quellseite.
Firehose: Überwachen Sie DeliveryToS3.DataFreshness und DeliveryToS3.Records, um Zustelllatenz und Datenverlust zu erkennen.
DMS: Überwachen Sie FullLoadRows, CDCLatencyMilliseconds und AppliedChanges für den Zustand der Replikation.

Entscheidungskriterien für die Alarmierung:

Verwenden Sie zusammengesetzte Alarme (CloudWatch composite alarms), um Fehlalarme zu reduzieren: Kombinieren Sie IteratorAgeMilliseconds > X für 3 Datenpunkte UND Consumer-Fehlerrate > Y.
Leiten Sie für die Auswahl von Schwellenwerten Basislinien aus historischen Daten der letzten 7–14 Tage ab und setzen Sie dynamische Schwellenwerte mithilfe von Anomalieerkennungsmodellen (PutAnomalyDetector), wenn die Workloads saisonal sind.

Überwachung und Fehlerbehandlung von Glue-Jobs

Glue gibt Metriken an CloudWatch aus und schreibt Protokolle in /aws-glue/jobs/output (Job-Ausführungsprotokolle) und /aws-glue/jobs/error (Fehler). Verwenden Sie CloudWatch Logs Insights, um Job-Ausführungen abzufragen: Führen Sie Abfragen über die Konsole oder mit aws logs start-query mit einem Abfrage-String wie fields @timestamp, @message | filter @message like /ERROR/ | sort @timestamp desc | limit 20 aus. Verfolgen Sie BytesRead, BytesWritten, RecordsProcessed und DPUHrs aus den Glue-Job-Ausführungsmetriken – DPUHrs korreliert direkt mit den Kosten und der Parallelität des Jobs.

Häufige Glue-Fehlermodi und deren Behebung:

OutOfMemory (OOM) oder Executor verloren: Erhöhen Sie den Worker-Typ/die DPU-Anzahl, wechseln Sie zum Worker-Typ G.2X bei höherem Speicherbedarf oder optimieren Sie die Spark-Partitionierung (repartition/coalesce) und verwenden Sie Pushdown-Prädikate, um das Eingabevolumen zu reduzieren.
Daten-Skew, der zu Nachzüglern (Stragglers) führt: Verwenden Sie Partitionierungsschlüssel zum Neuausbalancieren, erhöhen Sie die Parallelität oder nutzen Sie gegebenenfalls die split/resolve choices des Glue DynamicFrame.
Job-Stillstand oder lange Startzeiten: Aktivieren Sie Job-Lesezeichen (Bookmarks) und überwachen Sie die Glue JobMetrics auf „TimeWaitingForResources“, um Kapazitätskonflikte zu identifizieren.

Entscheidungsabwägungen:

Erhöhen Sie die DPUs, wenn CPU/Speicher der Engpass sind und die Vorhersagbarkeit der Laufzeit wichtig ist; bevorzugen Sie Code-Optimierungen (Partitionierung, Caching nur bei Bedarf), wenn die Kosten kontrolliert werden müssen.
Verwenden Sie Glue Streaming für Nahezu-Echtzeit-Transformationen; nutzen Sie Glue ETL Batch für komplexe Spark-Transformationen und größere, Spot-freundliche Workloads.

Überwachung von Kinesis und Firehose

Kinesis Consumer-Lag: Verlassen Sie sich auf GetRecords.IteratorAgeMilliseconds, um zu erkennen, wie weit die Consumer zurückliegen. Wenn GetRecords.IteratorAgeMilliseconds durchgängig hoch ist:

Skalieren Sie durch Erhöhen der Shard-Anzahl (Resharding/Skalierung), oder
Verbessern Sie die Consumer-Leistung durch Batch-Verarbeitung, die Nutzung von Enhanced Fan-Out (für einen Durchsatz von bis zu 2 MB/Sek. pro Consumer) oder die Kinesis Client Library (KCL) v2 mit verbessertem Checkpointing.

Verwenden Sie aws kinesis describe-stream, um die Shard-Anzahl zu überprüfen, und aws cloudwatch get-metric-statistics für IteratorAgeMilliseconds. Berücksichtigen Sie beim Vergleich von Behebungsoptionen:

Hinzufügen von Shards: Erhöht den Ingest- und Lese-Durchsatz; erfordert Resharding und ein neues Ausbalancieren.
Enhanced Fan-Out: Vermeidet den geteilten Lese-Durchsatz, erhöht aber die Kosten pro Consumer.
Consumer-Optimierung: Reduziert den Bedarf an zusätzlichen Shards und Kosten, erfordert aber Entwicklungsaufwand.

Firehose-Zustellmetriken: DeliveryToS3.DataFreshness quantifiziert die Zustelllatenz; typische buffering_delay-Einstellungen liegen zwischen 60 und 900 Sekunden und halten Datensätze zurück, bis entweder bufferSize oder bufferInterval erreicht ist. Wenn DeliveryToS3.DataFreshness hoch ist:

Überprüfen Sie die Firehose-Pufferhinweise (BufferIntervalInSeconds, BufferSizeInMBs) in der Konsole oder über aws firehose describe-delivery-stream.
Prüfen Sie CloudWatch-Fehler (DeliveryToS3.RecordsFailed) und S3-Bucket-Berechtigungen (KMS-Fehler bei Verschlüsselung).

Beachten Sie die Puffer-Semantik von Firehose: Der Dienst verzögert die Zustellung absichtlich bis zum Erreichen des Pufferintervalls; reduzieren Sie das Pufferintervall, um die Latenz auf Kosten von häufigeren S3-Schreibv

CloudTrail und Überwachung von Datenzugriffen

CloudTrail liefert API-Aktivitäten und optional Datenereignisse für S3 und Lambda, die standardmäßig nicht aktiviert sind. Um S3-Ereignisse auf Objektebene zu erfassen, aktivieren Sie explizit Datenereignisse im CloudTrail über die Konsole oder mit aws cloudtrail create-trail --include-global-service-events und fügen Sie S3-Datenressourcen hinzu. Ohne die Aktivierung von S3-Datenereignissen sehen Sie keine GetObject/PutObject-Aufrufe in CloudTrail, was eine häufige Lücke bei Untersuchungen darstellt.

Verwenden Sie CloudTrail-Protokolle in Kombination mit CloudWatch Logs Insights, um Betriebsmetriken (z. B. Protokolle von Glue-Jobs) mit Zugriffsereignissen zu korrelieren. Abfragemuster:

CloudWatch Logs Insights: filter @message like /GetObject/ | stats count() by userIdentity.principalId
Verwenden Sie EventBridge-Regeln, um auf bestimmte API-Aufrufe (z. B. PutBucketAcl) zu reagieren und diese für schnelle Benachrichtigungen an SNS weiterzuleiten.

DMS-Replikationsaufgaben veröffentlichen ebenfalls CloudWatch-Metriken: Überwachen Sie FullLoadRows für die Vollständigkeit der initialen Kopie, CDCLatencyMilliseconds zur Erkennung von Replikationsverzögerungen (Lag) und AppliedChanges, um sicherzustellen, dass Transaktionen auf dem Ziel angewendet werden. Lösen Sie Alarme aus, wenn CDCLatencyMilliseconds die Geschäfts-SLAs überschreitet und wenn AppliedChanges nach einem Anstieg der Full-Load-Zeilen niedrig ist.

Häufige Fallstricke und Entscheidungskriterien

Hohe IteratorAgeMilliseconds bei Kinesis wird fälschlicherweise für ein Problem auf Quellseite gehalten – korrekter Ansatz: Überprüfen Sie das Checkpointing und die Verarbeitungszeit des Consumers; skalieren Sie durch Hinzufügen von Shards oder verwenden Sie Enhanced Fan-Out erst nach einem Profiling der CPU/IO des Consumers.
OOM-Fehler (Out-of-Memory) bei Glue-Jobs werden durch blindes Erhöhen der DPU behoben – korrekter Ansatz: Führen Sie ein Profiling der Spark-Stages durch, optimieren Sie die Partitionierung und die Datenfilterung; erhöhen Sie die DPU oder den Worker-Typ nur, wenn Ressourcenlimits bestätigt sind.
Pufferverzögerung bei Firehose führt zu wahrgenommenem Datenverlust – korrekter Ansatz: Überprüfen Sie BufferIntervalInSeconds und BufferSizeInMBs; reduzieren Sie das Intervall für Anforderungen mit geringer Latenz und akzeptieren Sie höhere Schreibraten/Kosten.
Annahme, dass CloudTrail S3-Objektlesezugriffe standardmäßig aufzeichnet – korrekter Ansatz: Aktivieren Sie S3-Datenereignisse in CloudTrail, um GetObject/PutObject für forensische Prüfungen zu erfassen.
Fehlende Alarme für DMS CDC-Lag – korrekter Ansatz: Erstellen Sie CloudWatch-Alarme für CDCLatencyMilliseconds und vergleichen Sie AppliedChanges mit FullLoadRows; untersuchen Sie Netzwerkprobleme oder einen Transaktionsstau, wenn der Lag zunimmt.
Übermäßiges Alarmieren bei vorübergehenden Spitzen – korrekter Ansatz: Verwenden Sie Auswertungszeiträume (evaluation-periods), Datenpunkte bis zum Alarm (datapoint-to-alarm) oder Anomalieerkennung (anomaly detection), um das Rauschen zu reduzieren, und nutzen Sie zusammengesetzte Alarme (composite alarms) für korrelierte Bedingungen.

Praktisches Problem: Anwendungsfallszenario

Acme Analytics betreibt eine Echtzeit-Clickstream-Erfassung über Kinesis, reichert Ereignisse mit Glue-ETL-Jobs an, speichert veraltete Batches über Firehose in S3 und repliziert Altdatenbanken mit DMS. Sie beobachten End-to-End-Verzögerungen: Consumer-Lag bei Kinesis, OOM-Fehler bei Glue-Jobs und Firehose zeigt einen hohen Wert für DeliveryToS3.DataFreshness.

Profiling der Kinesis-Consumer: Rufen Sie die Metrik GetRecords.IteratorAgeMilliseconds ab, überprüfen Sie die Consumer-Protokolle und führen Sie eine Kostenanalyse für Kinesis Enhanced Fan-Out im Vergleich zur Skalierung über Shards durch.
Untersuchen Sie die CloudWatch-Metriken und Logs Insights des Glue-Jobs auf OOM-Stack-Traces; testen Sie eine Neupartitionierung und Pushdown-Prädikate lokal oder in einem kleineren Job; erhöhen Sie erst dann bei Bedarf die DPU/den Worker-Typ.
Überprüfen Sie die Puffereinstellungen von Firehose (BufferIntervalInSeconds) und DeliveryToS3.DataFreshness; reduzieren Sie das Pufferintervall für kritische SLOs und validieren Sie die S3-Schreibberechtigungen/KMS.
Konfigurieren Sie zusammengesetzte CloudWatch-Alarme (composite alarms), die IteratorAgeMilliseconds, die Fehlerrate des Glue-Jobs und die Firehose-Metrik DataFreshness kombinieren; senden Sie Alarme an ein SNS-Thema für den Bereitschaftsdienst und lösen Sie über EventBridge ein Runbook aus.
Aktivieren Sie CloudTrail-S3-Datenereignisse und korrelieren Sie GetObject/PutObject-Ereignisse mit den Startzeiten von Glue-Jobs und den angewendeten Änderungen von DMS, um unbefugten oder verzögerten Zugriff zu erkennen.

Dieser Ansatz folgt den AWS Best Practices: Überwachen Sie die richtigen Service-Metriken mit der korrekten Granularität, bevorzugen Sie gezielte Code- und Konfigurationskorrekturen vor der Skalierung von Ressourcen und stellen Sie sicher, dass eine Protokollierung auf Audit-Niveau explizit aktiviert ist, um eine schnelle Ursachenanalyse und automatisierte Behebung zu ermöglichen.

← Datensicherheit · Alle Domänen · Kostenoptimierung für Daten-Workloads →

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →