Skip to content
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

aws-sdk-2.2: Support non-X-Ray propagation for SQS #8405

Conversation

Oberon00
Copy link
Member

@Oberon00 Oberon00 commented May 3, 2023

Changes

This PR, despite being large, tries to do just what the title says: Adding support only for the v2 SDK (not v1 yet) only for SQS (not SNS yet) to inject into sent message attributes (no support for batch send yet) and the other side, adding support for extracting with the configured text map propagator (usually W3C) instead of X-Ray.

It also adds an option to the autoconfigure library to expose the (off-by-default) feature: otel.instrumentation.aws-sdk.experimental-use-propagator-for-messaging

As mentioned in the README of the aws-sdk-2.2 library at https://github.com/open-telemetry/opentelemetry-java-instrumentation/tree/main/instrumentation/aws-sdk/aws-sdk-2.2/library#trace-propagation:

The AWS SDK instrumentation currently only supports injecting the trace header into the request using the AWS Trace Header format. This format is the only format recognized by AWS managed services, and populating will allow propagating the trace through them. If this does not fulfill your use case, perhaps because you are using the same SDK with a different non-AWS managed service, let us know so we can provide configuration for this behavior.

Motivation & Prior art

The concrete use-case that triggered this PR was that for Dynatrace we need certain tracestate entries for more efficient span routing & linking so we'd like tracestate support, but I think it is also generally useful (e.g. (limited) baggage could also be propagated this way, or you could bypass X-Ray created intermediate spans if there are any.

If you are interested, this is the Dynatrace documentation for the scenario for Python that we'd like to enable for Java: https://www.dynatrace.com/support/help/shortlink/opentel-lambda#python-sqs-sns

Note that the AWS SDK instrumentations for Python & Node.js also support this feature (or even have it always-on) and should be wire-compatible with this (as long as the configured propagator matches of course):

Challenges

Obviously, this PR is rather large for implementing such a minimal feature set. There are two things that I think could be improved, but didn't dare to without discussion (I'm personally also OK with not improving them yet, as for me it's most important to get the functionality added in this PR supported):

  • HTTP + AWS SDK two-in-one span: There are a few TODO comments in this PR, see here. Basically, I had to move the point of span creation ahead to be able to inject into message attributes, which made it extremely awkward to capture HTTP attributes, and also they aren't available to onStart or samplers anymore this way.
  • Reflection boilerplate: The AWS SDK interface surface for the change wasn't small, and I had to add quite a few reflection helper methods/classes with boring boilerplate code. I asked about moving this to compileOnly/library + @NoMuzzle but for this PR I was following the previous approach with reflection. Please see this separate GH discussion: Addressing aws-sdk + plugin library muzzle issues / reflection creep #8394

Testing done

I extended the library unit tests, also ensuring that it works w/o additional X-Ray. I also manually tested sending to an actual SQS queue and verified the attributes are set as expected.

Further follow-ups

As mentioned initially, I tried to keep this PR minimal. If I can get this accepted in some form, I'd like to extend the non-X-Ray propagation support to

  • SDK 1.1
  • SQS batch send
  • SNS

@Oberon00 Oberon00 requested a review from a team as a code owner May 3, 2023 15:40
// Specific AWS SDK conventions also don't mention this peculiar hybrid span convention, see
// https://github.com/open-telemetry/opentelemetry-specification/blob/v1.20.0/specification/trace/semantic_conventions/instrumentation/aws-sdk.md
//
// TODO: Consider removing net+http conventions & relying on lower-level client instrumentation
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Oberon00 Oberon00 changed the title aws-sdk-2.2: Support non-XRay propagation for SQS. aws-sdk-2.2: Support non-X-Ray propagation for SQS May 3, 2023
Copy link
Member

@mateuszrzeszutek mateuszrzeszutek left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LEGTM, but left a couple of minor messages

Oberon00 and others added 5 commits May 8, 2023 16:53
Apply suggestions from code review

Co-authored-by: Mateusz Rzeszutek <mrzeszutek@splunk.com>
…pentelemetry/instrumentation/awssdk/v2_2/TracingExecutionInterceptor.java

Co-authored-by: Mateusz Rzeszutek <mrzeszutek@splunk.com>
@github-actions github-actions bot requested a review from theletterf May 8, 2023 15:55
@Oberon00
Copy link
Member Author

Is there anything more I should do to get this merged?

@trask trask merged commit f98a97f into open-telemetry:main May 16, 2023
44 checks passed
@Oberon00 Oberon00 deleted the feature/add-aws-sdk-2-sqs-inject branch May 16, 2023 08:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants