Amazon DVA-C02: Monitoring, Logging und Debugging (CloudWatch, X-Ray, Tracing, Alarme) — Lernleitfaden

By Laurynas Brazys · 27 July 2026 · #amazon #dva-c02 #certification #exam-prep #study-guide

Teil des AWS Developer Associate DVA-C02 — Lernleitfaden. Üben Sie mit verifizierten Antworten im Amazon-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

CloudWatch Logs, Metriken und Protokollmetrikfilter

CloudWatch Logs ist die primäre Pipeline für Anwendungs- und Plattform-Telemetrie. Entwickler sollten Protokolle strukturiert (JSON) gestalten, damit Metrics und Insights sie zuverlässig parsen können. Für benutzerdefinierte Anwendungsmetriken bevorzugen Sie das CloudWatch Embedded Metric Format (EMF) oder PutMetricData für sofortige Dimensionen und hochauflösende Anforderungen. EMF bettet _aws JSON in Protokollzeilen ein und ermöglicht es CloudWatch, viele Metriken in einem einzigen PutLogEvents-Aufruf zu extrahieren, was Kosten- und Durchsatzeffizienz steigert. Wenn Sie serverseitig Metriken aus textuellen Protokollen ableiten müssen, erstellen Sie Metrikfilter (PutMetricFilter) für eine Protokollgruppe, die Filtermuster auf MetricTransformations abbilden. Diese erzeugen CloudWatch-Metriken, die in Diagrammen dargestellt und für Alarme verwendet werden können. Gängige operative APIs sind CreateLogGroup, CreateLogStream und PutLogEvents (achten Sie auf den sequenceToken und die Batch-Größenbeschränkungen von PutLogEvents) sowie AssociateKmsKey, um einen kundenseitig verwalteten KMS-Schlüssel zur Verschlüsselung im Ruhezustand (Encryption at Rest) an eine Protokollgruppe anzuhängen. Achten Sie auf IAM: PutLogEvents und PutMetricData erfordern explizite Berechtigungen, und KMS-Grants müssen dem Service-Prinzipal die Verwendung von Schlüsseln zur Verschlüsselung gestatten. Verwenden Sie Aufbewahrungsrichtlinien (Retention Policies) zur Kostenkontrolle und bevorzugen Sie hochauflösende Metriken (PutMetricData mit StorageResolution=1) nur dann, wenn Sie eine Sichtbarkeit im Sub-Minuten-Bereich benötigen.

Tracing und X-Ray für verteilte Systeme

Verteilte Ablaufverfolgung (Distributed Tracing) instrumentiert Anforderungsflüsse über Dienste hinweg, um aufzudecken, wo Latenz und Fehler auftreten. AWS X-Ray ist die integrierte Option. Aktivieren Sie das aktive Tracing für Lambda-Funktionen (Lambda TracingConfig Mode: Active) und aktivieren Sie X-Ray für API Gateway Stages, um den X-Ray-Trace-Header weiterzugeben. Verwenden Sie das AWS X-Ray SDK in Ihrer Laufzeitumgebung (aws-xray-sdk-core für Node, aws_xray_sdk für Python, AWSXRayRecorder für Java), um Subsegmente zu erstellen, Annotationen (indiziert, kleine Werte) und Metadaten (nicht indiziert, größere Objekte) hinzuzufügen. Erfassen Sie nachgelagerte SDK-Aufrufe, indem Sie AWS SDK-Clients mit dem X-Ray-Recorder umschließen (wrappen), sodass das SDK Anfragen an S3, DynamoDB und HTTP-Aufrufe automatisch instrumentiert. Führen Sie für containerisierte Workloads den X-Ray-Daemon als Sidecar aus oder verwenden Sie den Daemon-Layer; er akzeptiert UDP-Pakete (Standardport 2000) und bündelt sie für den X-Ray-Dienst. Konfigurieren Sie Sampling-Regeln (CreateSamplingRule), um Rauschen zu vermeiden, aber passen Sie die Regeln an oder verwenden Sie den SDK-Override für kritische Abläufe, die Sie immer verfolgen möchten. Achten Sie auf die Größenbeschränkungen für Segmentdokumente und fügen Sie niemals PII in Annotationen ein, da diese indiziert und durchsuchbar sind.

Alarme, Benachrichtigungen und Alerting-Design

Alarme sollten handlungsrelevante Ereignisse erkennen, Rauschen reduzieren und in Runbooks integriert werden. Verwenden Sie CloudWatch Alarms für native Metriken, benutzerdefinierte Metriken (aus PutMetricData oder Metrikfiltern) oder metrische mathematische Ausdrücke (Metric Math). Passen Sie DatapointsToAlarm und EvaluationPeriods an, um „Flapping“ (schnell wechselnde Alarmzustände) zu vermeiden, und bevorzugen Sie Composite Alarms für Bedingungen mit mehreren Signalen (nachgelagerter Dienst gestört + erhöhte Fehlerrate), um das Alarmaufkommen zu reduzieren. Alarmaktionen können an SNS-Themen für menschliche/automatisierte Workflows veröffentlichen, Auto Scaling oder Systems Manager OpsCenter (Erstellung von OpsItems) aufrufen oder über EventBridge-Regeln für komplexe Playbooks weiterleiten (Quelle: aws.cloudwatch). Für schnelle Bereitschaftsanforderungen (On-Call) verwenden Sie SNS -> HTTP-Endpunkt oder PagerDuty-Integration; für die automatisierte Behebung verwenden Sie EventBridge -> Step Functions oder Lambda mit den geringsten erforderlichen IAM-Berechtigungen (Least Privilege). Ziehen Sie Anomalieerkennungsmodelle für das Baselining des Traffics in Betracht und legen Sie OK-Schwellenwerte mit Hysterese fest. Häufige Fehler sind das Erstellen zu vieler dimensionierter Alarme (Kostenexplosion bei der Überwachung), das alleinige Verlassen auf Auslöser durch einzelne Datenpunkte und die unzureichende Absicherung von Benachrichtigungsthemen (SNS-Zugriffsrichtlinien), sodass Warnungen nicht an unbeabsichtigte Empfänger gelangen.

Muster zur Fehlerbehebung und Best Practices für SDK/API

Beginnen Sie die Fehlerbehebung, indem Sie eine erwartete mit einer beobachteten Zeitachse vergleichen und dann Protokolle, Metriken und Traces korrelieren. Verwenden Sie CloudWatch Logs Insights für Ad-hoc-Abfragen (Felder @timestamp, @message | parse … | stats count() by bin(1m)), um Spitzen (Spikes) zu finden und dann zu X-Ray-Traces für detaillierte Latenzzeiten zu wechseln. Überprüfen Sie bei Lambda-gestützten APIs Kaltstarts (Cold-Starts), die VPC ENI-Anbindungszeiten (für Funktionen in einer VPC) und ob Lambda Destinations oder DLQs für die Erfassung fehlgeschlagener asynchroner Aufrufe konfiguriert sind. Zur Erfassung fehlgeschlagener Aufrufe verwenden Sie Lambda Destinations (onFailure an SNS, SQS oder EventBridge) oder eine asynchrone DLQ, um die Payloads zu erhalten. Bei der Instrumentierung von Code sollten Sie API-Drosselungen (Throttles) durch die Implementierung von exponentiellem Backoff mit Jitter handhaben und 429-Fehler über Metrikfilter oder EMF-Zähler überwachen. Häufige Fallstricke: PutLogEvents erfordert zuerst das korrekte Sequenz-Token und CreateLogStream; PutMetricData kann gedrosselt werden – bündeln Sie Daten und senden Sie aggregierte Metriken; X-Ray erfordert die Berechtigungen xray:PutTraceSegments und xray:PutTelemetryRecords (verwaltete Richtlinie AWSXRayDaemonWriteAccess); und Sampling kann Probleme verbergen, es sei denn, Sie passen die Regeln für selten auftretende, aber kritische Abläufe an.

Praktisches Problem: Anwendungsfallszenario

Szenario: Acme Retail betreibt einen serverlosen Checkout-Service auf AWS, der API Gateway -> Lambda -> DynamoDB verwendet. Das Team nutzt zentralisierte CloudWatch Logs und X-Ray, es fehlen jedoch Metriken zum Gerätedurchsatz pro Minute und es werden zuverlässige Alarme bei Spitzen in der API-Latenz benötigt, ohne dabei rauschanfällige Alarme (Noisy Alerts) zu erzeugen.

Herausforderung: Erfassen Sie Geräte-/Nachrichtenzahlen pro Minute nahezu in Echtzeit, stellen Sie End-to-End-Tracing für langsame Anfragen sicher und erstellen Sie einen rauscharmen Alarm, der eine automatisierte Lambda-Funktion zur Problembehebung auslöst und die Rufbereitschaft benachrichtigt.

Empfohlener Ansatz:

Instrumentieren Sie die Checkout-Lambda-Funktion, um eine benutzerdefinierte, hochauflösende Metrik mit der PutMetricData-API auszugeben: Namespace=Acme/Checkout, MetricName=DeviceReportsPerMinute, Timestamp=now, Value=1 und StorageResolution=1. Bündeln Sie diese im Speicher (In-Memory) und leeren Sie den Puffer alle 30 Sekunden, um API-Drosselung zu vermeiden.
Betten Sie außerdem EMF-JSON in die Lambda-Protokolle ein, um reichhaltigere Dimensionen (customerId, region) zu erhalten, und verlassen Sie sich auf CloudWatch Logs, um über PutLogEvents und Metrikfilter (PutMetricFilter) zusätzliche Metriken für Fehlerzählungen zu extrahieren.
Aktivieren Sie das X-Ray-Tracing: Setzen Sie den Lambda TracingConfig-Modus auf Active, aktivieren Sie X-Ray auf der API-Gateway-Stage und verwenden Sie das X-Ray SDK, um Annotationen (keine personenbezogenen Daten/PII) und Subsegmente um externe HTTP-Aufrufe an Drittanbieter-APIs hinzuzufügen.
Erstellen Sie einen zusammengesetzten CloudWatch-Alarm (Composite Alarm), der eine hohe Latenzmetrik des 95. Perzentils (Metrik-Mathematik) mit einer Spitze bei DeviceReportsPerMinute kombiniert. Setzen Sie EvaluationPeriods=3, DatapointsToAlarm=2 und als Aktion ein SNS-Thema, das einen Endpunkt der Rufbereitschaft sowie eine EventBridge-Regel auslöst, die eine Lambda-Funktion zur Problembehebung aufruft (Rolle mit den geringsten Rechten).

Begründung: Das Ausgeben von hochauflösenden Metriken und EMF liefert sowohl sofortige Zählungen pro Minute als auch eine reichhaltigere Dimensionalität. X-Ray ermöglicht die Ursachenanalyse von Latenzzeiten bis hin zu nachgelagerten Aufrufen. Zusammengesetzte Alarme reduzieren das Rauschen (Noise), indem sie korrelierte Bedingungen vor dem Alarmieren erfordern und eine Automatisierung über EventBridge ermöglichen.

← Sicherheit · Alle Domänen · Speicher →

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