A developer has a Java-based microservice running on Amazon ECS on AWS Fargate. The microservice reads messages from an Amazon SQS queue, processes them, and writes results to an Amazon DynamoDB table. The developer needs to instrument the application with AWS X-Ray to trace the processing from the SQS queue to the DynamoDB calls. The X-Ray daemon is deployed as a sidecar container in the same task definition. Which two actions should the developer take to configure AWS X-Ray tracing and resolve the missing downstream segments?
- Add the AWSXRayDaemonWriteAccess policy to the IAM ECS Task Role used by the ECS container.Answer
- Configure the AWS SDK for Java client with the TracingInterceptor to intercept and trace calls to DynamoDB.Answer
- CAdd the AWSXRayDaemonWriteAccess policy to the IAM ECS Task Execution Role.
- DRely on the Amazon SQS queue to automatically propagate the trace context to DynamoDB without instrumenting the AWS SDK client inside the Java application.
- EInitialize the DynamoDB client inside the application code by hardcoding temporary IAM user access keys that have X-Ray write permissions.
Answer
To configure AWS X-Ray tracing for this application, the developer must attach the AWSXRayDaemonWriteAccess policy to the IAM ECS Task Role used by the ECS container, and configure the AWS SDK for Java client with the TracingInterceptor to intercept and trace calls to DynamoDB.
To trace downstream requests to DynamoDB, the developer must instrument the AWS SDK client inside the Java microservice using the AWS X-Ray SDK (for example, by adding TracingInterceptor). In addition, since the X-Ray daemon runs in a sidecar container, it needs permissions to upload segment data to the AWS X-Ray service. These permissions must be attached to the ECS Task Role.
Step-by-Step Solution
Key Concept
Instrumenting microservices running on ECS with AWS X-Ray requires both configuring the container's IAM Task Role for write permissions and instrumenting the application's SDK client to record downstream calls.