What's changed: In-scope service coverage (axis B): added Athena/OpenSearch Service large-scale log-analysis definitions, roles, and selection criteria to s1 (CloudWatch).
5.2Distributed Tracing and Debugging with X-Ray
Understand debugging with AWS X-Ray: distributed tracing (request path and per-segment latency), pinpointing bottlenecks/errors, and the service map.
In multi-service flows, it gets hard to see where it’s slow or failing. AWS X-Ray traces requests and visualizes per-segment latency and errors.
5.2.1Traces and the service map
- Trace: records the segments and latency of each service a single request passes through.
- Service map: visualizes dependencies and health between services.
- Identify slow or error-prone segments to isolate bottlenecks.
Master X-Ray’s structure. A whole request is a trace, each service’s processing span is a segment, and fine-grained work inside it (e.g., a DB call) is a subsegment. Recording every request is heavy, so sampling captures a subset, balancing cost and coverage. Annotations are indexed and filterable; metadata is extra info not searchable. Lambda and API Gateway can enable active tracing via configuration; on EC2/ECS the X-Ray daemon (or a sidecar) sends traces. Instrument the app with the SDK to measure external calls. To stitch traces across services, the trace header (X-Amzn-Trace-Id) must propagate. The visual service map makes nodes with high error rates or latency obvious at a glance.
Continue reading — free sign-up
You're reading the free preview. Sign up free to read this section in full, plus every chapter (including 4+) and all questions.