Question

Difficulty: MediumInstrumenting Distributed Tracing with AWS X-Ray

A developer has a Python-based worker application running on Amazon EC2 instances. The application manually polls an Amazon SQS queue for incoming messages, processes them, and writes the results to an Amazon DynamoDB table. The AWS X-Ray daemon is running on the EC2 instances, and the AWS SDK for Python (boto3) is instrumented. However, in the AWS X-Ray console, the developer observes that the traces for the SQS queue and the DynamoDB operations appear as separate, disconnected traces rather than a single end-to-end trace.

Which action should the developer take to correlate these traces?

  1. Extract the tracing header from the Amazon SQS message's `AWSTraceHeader` attribute, and use the AWS X-Ray SDK to create a segment using that header as the parent context before invoking the Amazon DynamoDB API.Answer
  2. B
    Enable active tracing on the Amazon DynamoDB table, which automatically instructs the AWS SDK to retrieve the trace context from the SQS message attributes and associate it with the DynamoDB write request.
  3. C
    Modify the application to initialize the boto3 DynamoDB client by passing the AWS access key and secret access key retrieved from the SQS message metadata directly into the client constructor.
  4. D
    Increase the Amazon SQS visibility timeout to be at least double the database write execution time to allow the X-Ray daemon to flush the segment data before the message becomes visible again.

Answer

Extract the tracing header from the Amazon SQS message's `AWSTraceHeader` attribute, and use the AWS X-Ray SDK to create a segment using that header as the parent context before invoking the Amazon DynamoDB API.
When a worker application manually polls an Amazon SQS queue, the tracing context from the producer is carried in the message's `AWSTraceHeader` attribute. Because context propagation is not automatic for manual polling, the developer must programmatically extract this header and use the AWS X-Ray SDK to create a segment with the correct parent trace ID. This links the worker's processing and any downstream AWS calls (like DynamoDB) to the original trace.

Step-by-Step Solution

1
Identify the mechanism for tracing context propagation through message queues.
Amazon SQS messages contain a trace header in the `AWSTraceHeader` attribute when sent from an instrumented upstream service.
Because the worker polls SQS manually, the context does not propagate automatically like it does in a direct AWS Lambda SQS event source trigger.
2
Use the AWS X-Ray SDK to parse the retrieved tracing header.
The SDK creates a new segment or subsegment using the extracted header as the parent context.
This establishes the parent-child relationship between the message producer and the worker's processing steps.
3
Execute downstream AWS SDK calls (DynamoDB write) within the context of the newly created segment.
The downstream calls are recorded as subsegments of the parent trace.
This ensures that all operations are correlated into a single, continuous trace on the X-Ray service map.

Key Concept

Manual propagation of AWS X-Ray tracing context across Amazon SQS message boundaries using the `AWSTraceHeader` attribute.
Estimated Time:1m 30s
Rate this question