Open ghost opened 3 years ago
@anuraaga FYI :)
@kubawach, I would be interested in working on this one.
For the auto-generation portion of this, I am thinking of targeting the following types of files. For example:
I am interested if you have any thoughts on not instrumenting specific fields like the message in an SQS SendMessage or the Dynamodb item in a PutItem request? I would assume some deny list in the code-gen file, but curious if you had any thoughts on it or prior art you were thinking about following. Also curious about your opinions on adding hints for the code generator on messaging spec on SQS or DB spec on Dynamodb or aurora?
For context of anyone finding this issue, the hard coded parameters are
In X-Ray's Java SDK, AWS SDK attributes extractor are also hard coded but using JSON files such as https://github.com/aws/aws-xray-sdk-java/blob/8161976ab0495a1b3d9a1d87a0bbe08fcc75dcc9/aws-xray-recorder-sdk-aws-sdk/src/main/resources/com/amazonaws/xray/handlers/DefaultOperationParameterWhitelist.json#L3 and used in https://github.com/aws/aws-xray-sdk-java/blob/3c15d4030e0381bef9445c2fa2ce78aad184d10e/aws-xray-recorder-sdk-aws-sdk-v2/src/main/java/com/amazonaws/xray/interceptors/TracingInterceptor.java#L143
Is your feature request related to a problem? Please describe. Currently AWS SDK field to span attribute mappings are hard coded for DynamoDB. It would be good to have those generated automatically from a YAML file for all AWS SDK request types.
Describe the solution you'd like Spec: https://github.com/open-telemetry/opentelemetry-specification/pull/1422/files Existing prop generator: https://github.com/open-telemetry/opentelemetry-java/blob/main/buildscripts/semantic-convention/generate.sh
Describe alternatives you've considered
Additional context Add any other context or screenshots about the feature request here.