A developer is troubleshooting an AWS Lambda function written in Python that is triggered by an Amazon API Gateway REST API. When a client sends a request, the function queries Amazon DynamoDB and then queries an external PostgreSQL database. The developer has enabled active tracing on the Lambda function. Although the API Gateway and Lambda service execution segments appear in the AWS X-Ray service map, downstream calls to DynamoDB and the PostgreSQL database are completely missing. Which two actions must the developer take to capture these downstream calls in the X-Ray trace?
- Call patch_all() from the aws_xray_sdk.core module at application startup to automatically instrument downstream calls made via the boto3 library.Answer
- Wrap the PostgreSQL database connection library using the AWS X-Ray SDK's patch function or database wrappers to instrument SQL queries.Answer
- CInitialize the AWS SDK clients by hardcoding an AWS IAM access key and secret access key that have the xray:PutTraceSegments permission.
- DIncrease the execution timeout of the Lambda function to allow the X-Ray daemon helper thread to flush traces before the runtime container freezes.
- EConfigure API Gateway to use a custom Lambda integration instead of a Lambda proxy integration to ensure that the trace header is parsed and passed in the JSON payload.
Answer
To capture downstream AWS SDK and database calls in AWS X-Ray, the developer must call patch_all() to instrument boto3 and wrap the database connection library with the X-Ray SDK's database wrappers.
To trace downstream dependencies with AWS X-Ray in a Python Lambda function, active tracing must be paired with application-level SDK instrumentation. Calling the patch_all function from the X-Ray SDK dynamically patches boto3, enabling tracing for all AWS SDK calls (like DynamoDB). To trace external database queries, the database client library must also be wrapped or patched by the X-Ray SDK.
Step-by-Step Solution
Key Concept
AWS X-Ray SDK instrumentation for downstream dependencies