Troubleshooting and Optimization
Root Cause Analysis with Logs, Metrics, Traces, and Service Output
CoreCorrelate code behavior, CloudWatch telemetry, X-Ray request paths, dashboards, queries, and deployment output to isolate the smallest failing boundary.
Aligned to AWS Certified Developer - Associate (DVA-C02) Version 2.1, verified August 23, 2026.
Why this matters
A metric can reveal when a problem started, a log can show what happened in one event, and a trace can show where a distributed request slowed or failed. Root cause comes from correlating the right evidence, not from widening permissions or scaling at random.
Must Know
- Reproduce a code defect with the smallest representative input, then use stack context and structured application state to isolate the failing branch.
- Metrics are aggregate time series, logs are event records, and traces correlate work across request paths. Use each for the question it can answer.
- Start with a metric or dashboard to locate the affected interval, query structured logs for specific events, and use traces to identify a slow or failing service hop.
- CloudWatch Logs Insights queries fields across selected log groups and time ranges; consistent structured fields make queries more reliable than searching free-form prose.
- CloudWatch embedded metric format lets structured log events instruct CloudWatch to extract custom metrics without a separate PutMetricData call.
- Use bounded, low-cardinality dimensions for metrics. Request, user, or unbounded identifiers belong in logs or trace context rather than metric dimensions.
- Dashboards summarize application health across latency, errors, throughput, saturation, and dependencies but still require drill-down evidence.
- Deployment services emit stage and resource output that can identify artifact, template, permission, configuration, and health-check failures.
- Integration failures should be classified as identity/authorization, payload/contract, throttling, timeout, network, or downstream-service behavior before correction.
Compare and Distinguish
- Logs vs metrics vs traces: detailed events, aggregate trends, and correlated request paths answer different diagnostic questions.
- Dashboard vs root cause evidence: a dashboard points to an unhealthy signal; logs and traces usually establish the failing operation or boundary.
- Plain-text log vs structured log: structured fields support consistent filtering, aggregation, and correlation.
- EMF event vs arbitrary JSON log: EMF follows the required structure that declares metric namespaces, dimensions, and values.
- Application defect vs service integration defect: reproduce internal logic separately from the configured downstream call.
- Retryable throttling/timeout vs authorization/validation error: retries can help transient capacity failures but do not repair a denied or invalid request.
Scenario examples
- Scenario: Error rate spiked for ten minutes. Use metrics to find the interval, query logs for affected request IDs, then follow traces across downstream services.
- Scenario: A single input produces the wrong result while service health is normal. Reproduce it and fix the narrow application branch rather than adding capacity.
- Scenario: A deployment stops before traffic changes. Read the failed pipeline or stack event and correct the reported artifact, template, role, or configuration issue.
- Scenario: A downstream call sometimes returns AccessDenied and sometimes times out. Classify and correlate the two errors instead of applying one retry policy to both.
Exam traps
- A green CPU graph does not prove application health.
- More log volume is not a substitute for consistent queryable fields and correlation IDs.
- Any JSON log is not automatically a valid or safe embedded-metric event.
- High-cardinality metric dimensions can create an unusable metric surface.
- Retries do not fix authorization, schema, or deterministic code defects.
- Do not redesign VPCs, servers, or enterprise architecture while assisting with an application root cause.
Key takeaways
- Select telemetry from the diagnostic question, then correlate it by time and request context.
- Use structured fields and bounded dimensions intentionally.
- Read service output at the first failing boundary.
- Classify an integration error before choosing retry, configuration, permission, or code correction.
- Make the least invasive evidence-supported correction.
How it works
- An alarm or dashboard identifies the affected signal and interval.
- A Logs Insights query narrows events by structured fields, time, status, and correlation.
- An X-Ray trace follows the request through supported services and instrumented code.
- The combined evidence identifies the failing code path, integration, deployment stage, or resource constraint.
When to use it
- Use CloudWatch metrics and dashboards for trends, thresholds, and health overview.
- Use CloudWatch Logs and Logs Insights for event-level state and searchable errors.
- Use AWS X-Ray for request-path timing and cross-service correlation.
- Use pipeline, stack, and service events for deployment-stage failure diagnosis.
- Use a minimal reproducible test for deterministic application defects.
Security and governance implications
- Redact secrets, complete tokens, and classified payloads before logging or tracing.
- Scope telemetry and deployment-log access to the teams and roles that need it.
- Use safe correlation identifiers rather than user data as metric dimensions.
- Do not respond to an unclear denial by granting broad permissions.
Failure signals and diagnosis
- If evidence does not correlate, standardize timestamps and propagate one safe correlation identifier.
- If traces have gaps, confirm supported tracing is enabled and custom code propagates context and records subsegments.
- If logs are unqueryable, add consistent fields at emission rather than downloading and scanning everything.
- If a dashboard and user impact disagree, inspect business outcomes and dependency health rather than trusting one green metric.
More detail
- Application health combines service and business signals; infrastructure utilization alone can miss failed user outcomes.
- A correlation ID carried across logs and trace context links related work without using sensitive values.
- EMF supports logs and metrics in one structured event, but dimensions must remain controlled.
- Service output logs describe where deployment failed; runtime logs describe what deployed code did.
Ready for the quiz?
- Which signal locates an aggregate spike, and which inspects one request?
- What makes Logs Insights queries reliable?
- When should a value be a log field rather than a metric dimension?
- Which deployment output should you inspect first?
- Why is adding retries to AccessDenied usually wrong?
Related objectives
- D4.1 — Assist in a root cause analysis
- 4.1.1 — Debug code to identify defects
- 4.1.2 — Interpret application metrics, logs, and traces
- 4.1.3 — Query logs to find relevant data
- 4.1.4 — Implement custom metrics (for example, Amazon CloudWatch embedded metric format [EMF])
- 4.1.5 — Review application health by using dashboards and insights
- 4.1.6 — Troubleshoot deployment failures by using service output logs
- 4.1.7 — Debug service integration issues in applications