Examkin

Question

Difficulty: Very hardInstrumenting Distributed Tracing with AWS X-Ray

A developer has a distributed application where a producer service running on Amazon ECS Fargate sends tasks to an Amazon SQS queue. A consumer service, also running on Amazon ECS Fargate, polls the queue and processes the tasks. Both services use the AWS SDK and are configured with the AWS X-Ray SDK, with active tracing enabled where applicable and the AWS SDK clients properly patched.

When viewing the traces in the AWS X-Ray console, the developer observes two disconnected traces: one for the producer service sending the message, and another separate trace for the consumer service processing the task. The end-to-end transaction is not correlated.

Which action should the developer take to resolve this issue and trace the request end-to-end?

  1. A
    Enable active tracing on the Amazon SQS queue configuration via the AWS Management Console to allow the queue to act as a segment coordinator.
  2. Modify the consumer service code to extract the AWSTraceHeader from the SQS message system attributes, and use it to construct and set the parent segment context in the AWS X-Ray SDK.Answer
  3. C
    Increase the visibility timeout of the Amazon SQS queue to ensure that the consumer service has enough time to write trace segments to the AWS X-Ray daemon before the message returns to the queue.
  4. D
    Configure the AWS X-Ray SDK on the consumer service using hardcoded AWS IAM credentials with xray:PutTraceSegments permissions in the application source code to authorize the segment creation.

Answer

Modify the consumer service code to extract the AWSTraceHeader from the SQS message system attributes, and use it to construct and set the parent segment context in the AWS X-Ray SDK.
The correct answer is to modify the consumer service code to extract the AWSTraceHeader from the SQS message system attributes, and use it to construct and set the parent segment context. When using a self-managed worker (such as on ECS Fargate or EC2) to process SQS messages, the SDK does not automatically extract the tracing header. The developer must manually parse the AWSTraceHeader system attribute and initialize the segment context with it, which links the consumer's trace to the producer's trace.

Step-by-Step Solution

1
Identify the boundary where tracing context is lost.
The boundary is the Amazon SQS queue, where the producer sends a message and the consumer on ECS Fargate retrieves it. The trace splits into two disconnected traces.
Since the consumer is running on ECS Fargate (rather than AWS Lambda, which automatically handles SQS trace context propagation), the X-Ray SDK on the consumer does not automatically know how to link the processing logic to the incoming message's trace context.
2
Locate where the tracing header is transmitted within Amazon SQS.
The AWS SDK automatically injects the AWSTraceHeader into the message's system attributes when the producer sends the message.
This header contains the trace ID, parent segment ID, and sampling decision.
3
Extract the trace header and initialize the segment in the consumer service code.
The consumer reads the AWSTraceHeader from the SQS message attributes and initializes a new segment (or subsegment) with this header as the parent context.
By explicitly setting the parent context using the extracted trace header, the X-Ray SDK links the consumer's execution to the producer's trace, restoring end-to-end correlation.

Key Concept

Manual trace context propagation across asynchronous boundaries with non-Lambda consumers
Rate this question

Topics

Instrumenting Distributed Tracing with AWS X-Ray

More questions from this topic