-
Notifications
You must be signed in to change notification settings - Fork 155
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
X-Ray's segment does not differentiate DynamoDB tables when using ExecuteStatementCommand #524
Comments
Hi! This may be happening because in this case, instrumentation will only work properly with AWS SDK clients. When tracing calls to AWS services, "traced AWS services, and resources that you access within those services (for example, a DynamoDB table), appear as downstream nodes on the service map in the X-Ray console". The X-Ray documentation linked above contains a detailed guide on how to instrument AWS SDK clients. |
Hi @carolabadeer , Thanks for the reply, I think we've instrumented dynamodb aws SDK client properly, What I found that related to this issue was that in the aws_whitelist.json, there is nothing for "getItem": {
"request_parameters": [
"ConsistentRead",
"ProjectionExpression",
"TableName"
],
"response_parameters": [
"ConsumedCapacity"
]
},
|
I see this issue as well when performing a BatchGetItemCommand and BatchWriteCommand. The table names are not included in the trace sent to X-Ray. I am configured as such:
|
Hello @naataaniitsosie and @Blankll, if you're using AWS V3 clients, you will need PR #527, the Xray SDK doesn't correctly get information from DynamoDB requests. I added a patch file in the PR comments ready to use with |
Background
We query multi DynamoDB tables within a single Lamba event request by using partiQL though ExecuteStatementCommand, X-Ray does not differentiate queries by tableName, in the service map it only shows one DynamoDB with 2 request
Expect
X-Ray can differentiate ExecuteStatementCommand query By tableName, so Both service map and trace can separate segments data by tableName
The text was updated successfully, but these errors were encountered: