Amazon DVA-C02: Monitoring, Logging & Debugging (CloudWatch, X‑Ray, Tracing, Alarms) — Study Guide
Part of the AWS Developer Associate DVA-C02 — Study Guide. Practice with verified answers in the Amazon exam hub, or take timed practice tests on ExamRoll.io.
CloudWatch Logs, Metrics and Log Metric Filters
CloudWatch Logs is the primary pipeline for application and platform telemetry; developers should design logs to be structured (JSON) so Metrics and Insights can parse them reliably. For custom application metrics prefer CloudWatch Embedded Metric Format (EMF) or PutMetricData for immediate dimensions and high-resolution needs; EMF embeds _aws JSON in log lines and lets CloudWatch extract many metrics in a single PutLogEvents call for cost and throughput efficiency. When you need to derive metrics from textual logs on the service side, create metric filters (PutMetricFilter) against a log group that map filter patterns to MetricTransformations; these yield CloudWatch metrics that can be graphed and alarmed. Common operational APIs are CreateLogGroup, CreateLogStream, and PutLogEvents (watch for sequenceToken and PutLogEvents batch size limits), and AssociateKmsKey to attach a customer-managed KMS key to a log group for encryption at rest. Watch IAM: PutLogEvents and PutMetricData require explicit permissions, and KMS grants must allow the service principal to use keys for encryption. Use retention policies to control costs and prefer high-resolution metrics (PutMetricData with StorageResolution=1) only when you need sub-minute visibility.
Tracing and X‑Ray for Distributed Systems
Distributed tracing instruments request flows across services to reveal where latency and errors occur; AWS X-Ray is the integrated option. Enable Active tracing on Lambda functions (Lambda TracingConfig Mode: Active) and enable X‑Ray for API Gateway stages to propagate the X‑Ray trace header. Use the AWS X‑Ray SDK in your runtime (aws-xray-sdk-core for Node, aws_xray_sdk for Python, AWSXRayRecorder for Java) to create subsegments, add annotations (indexed, small values) and metadata (non-indexed, larger objects). Capture downstream SDK calls by wrapping AWS SDK clients with the X‑Ray recorder so the SDK auto-instruments requests to S3, DynamoDB, and HTTP calls. For containerized workloads run the X‑Ray daemon as a sidecar or use the daemon layer; it accepts UDP packets (default port 2000) and batches them to the X‑Ray service. Configure sampling rules (CreateSamplingRule) to avoid noise but adjust rules or use the SDK override for critical flows you always want traced. Be mindful of segment document size limits and never put PII in annotations because they are indexed and searchable.
Alarms, Notifications and Alerting Design
Alarms should detect actionable events, reduce noise, and integrate with runbooks. Use CloudWatch Alarms on native metrics, custom metrics (from PutMetricData or metric filters), or metric math expressions; tune DatapointsToAlarm and EvaluationPeriods to avoid flapping and prefer composite alarms for multi-signal conditions (broken downstream + increased error rate) to reduce alert volume. Alarm actions can publish to SNS topics for human/automation workflows, invoke Auto Scaling or Systems Manager OpsCenter (create OpsItems), or route through EventBridge rules for complex playbooks (source: aws.cloudwatch). For rapid on-call needs use SNS -> HTTP endpoint or PagerDuty integration; for automated remediation use EventBridge -> Step Functions or Lambda with least-privilege IAM. Consider anomaly detection models for baselining traffic and set OK thresholds with hysteresis. Common traps include creating too many dimensioned alarms (explosion of monitoring costs), relying solely on single-data-point triggers, and failing to secure notification topics (SNS access policies) so alerts don’t leak to unintended consumers.
Troubleshooting Patterns and SDK/API Practices
Start troubleshooting by framing an expected vs observed timeline and then correlate logs, metrics, and traces. Use CloudWatch Logs Insights for ad-hoc queries (fields @timestamp, @message | parse … | stats count() by bin(1m)) to find spikes and then pivot to X‑Ray traces for detailed latencies. For Lambda-backed APIs check cold-starts, VPC ENI attach times (for functions in a VPC), and whether Lambda destinations or DLQs are configured for capturing failed asynchronous invocations. For capturing failed invocations use Lambda Destinations (onFailure to SNS, SQS, or EventBridge) or an async DLQ to preserve payloads. When instrumenting code, handle API throttles by implementing exponential backoff with jitter and monitoring 429s via metric filters or EMF counters. Common gotchas: PutLogEvents requires the correct sequence token and CreateLogStream first; PutMetricData can be throttled—batch and emit aggregate metrics; X‑Ray requires xray:PutTraceSegments and xray:PutTelemetryRecords permissions (managed policy AWSXRayDaemonWriteAccess); and sampling may hide issues unless you adjust rules for low-frequency but critical flows.
Practical Problem: Use-Case Scenario
Scenario: Acme Retail operates a serverless checkout service on AWS using API Gateway -> Lambda -> DynamoDB. The team runs centralized CloudWatch Logs and X‑Ray but is missing per-minute device throughput metrics and needs reliable alerts on spikes in API latency without creating noisy alerts.
Challenge: Capture near-real-time device/message counts per minute, ensure end-to-end tracing for slow requests, and create a low-noise alarm that triggers an automated remediation Lambda and notifies on-call.
Recommended Approach:
- Instrument the checkout Lambda to emit a custom high-resolution metric using the PutMetricData API with Namespace=Acme/Checkout, MetricName=DeviceReportsPerMinute, Timestamp=now, Value=1, and StorageResolution=1; batch these in-memory and flush every 30s to avoid API throttling.
- Also embed EMF JSON into Lambda logs for richer dimensions (customerId, region) and rely on CloudWatch Logs to extract additional metrics via PutLogEvents and metric filters (PutMetricFilter) for error counts.
- Enable X‑Ray tracing: set Lambda TracingConfig Mode to Active, enable X‑Ray on the API Gateway stage, and use the X‑Ray SDK to add annotations (non-PII) and subsegments around external HTTP calls to third-party APIs.
- Create a composite CloudWatch Alarm that combines a high 95th-percentile latency metric (metric math) with a spike in DeviceReportsPerMinute; set EvaluationPeriods=3, DatapointsToAlarm=2, Action to SNS topic that triggers an on-call endpoint plus an EventBridge rule that invokes a remediation Lambda (least-privileged role).
Rationale: Emitting high-resolution metrics and EMF gives both immediate per-minute counts and richer dimensionality; X‑Ray provides latency root-cause down to downstream calls; composite alarms reduce noise by requiring correlated conditions before alerting and allow automation via EventBridge.
← Security · All domains · Storage →
Practice these questions → · Timed practice on 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.
Pass your exam →