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

feat: SQS / SNS messaging attributes and context propagation #1026

Merged
merged 51 commits into from
Jan 19, 2022

Conversation

YanivD
Copy link
Member

@YanivD YanivD commented Nov 21, 2021

What's added in this PR?

  • Added message attributes for SQS and SNS services
  • Added context propagation support for SQS and SNS. For SQS.SendMessage, SQS.SendMessageBatch and SNS.Publish methods

Context propagation strategy

Currently SQS doesn't natively support propagating the OTEL context.
I used JS aws-sdk instrumentation as an inspiration for this PR. It use message metadata to populate propagator fields.

Limitations

SQS support up to 10 message metadata attributes. Context attributes will not be added if there are too many attributes.

What's missing?

Currently context propagation is working only if the receiver is using JS aws-sdk. I'm planning to add support in another separated PR.


Note: This PR contain file changes from #1023

@ericmustin
Copy link
Contributor

@mottibec @blumamir @YanivD I'm not quite sure what these approvals from your colleagues are supposed to indicate. The work and motivation is absolutely appreciated, but there are currently multiple errors in this instrumentation and the test suite is clearly and loudly failing and some changes are still required. Approving PRs without reviewing them doesn't do anything except add noise, and erode confidence that you and your colleagues are carefully implementing and testing the changes in this Pull Request. I fully understand that you have product/professional obligations which rely on successfully merging and releasing this work, and I am scheduling time to review this this week. Thank you for your patience and for all the great work so far.

@YanivD
Copy link
Member Author

YanivD commented Nov 21, 2021

@ericmustin
We're excited for the opportunity to contribute and help the community. We didn't mean to make unnecessary noises.
Folks, we really appreciate all your help, guidance and your professional quick response.
I'll address the failing tests soon and make sure this pr is ready for review. Until then, marking it as draft. Any review and suggestions is welcome.

@YanivD YanivD marked this pull request as draft November 21, 2021 18:50
@YanivD
Copy link
Member Author

YanivD commented Nov 22, 2021

Updated the pr, now the tests are green and ready for review.
The failing tests were from aws-sdk version 2. The context interface changed in version 3. Appraisal tool is great!

@YanivD YanivD marked this pull request as ready for review November 22, 2021 07:54
@YanivD
Copy link
Member Author

YanivD commented Dec 19, 2021

Thanks @ericmustin
After revisiting v2.0 support, I modified service_name extraction to support 2.0 versions - 77074a1.
This PR won't change the supported versions.

@open-telemetry/ruby-maintainers
Please let me know if more changes are required

@ericmustin
Copy link
Contributor

@YanivD lgtm, ty for addressing that, will try to get some other eyes on it from approvers/maintainers this week. Just for reference in US/CA we're a bit light this week and next bc of Christmas holidays, apols if there's any delay here. 🎅 😅

@YanivD
Copy link
Member Author

YanivD commented Dec 20, 2021

I want to update that I'm working on extracting SQS context, for creating 'process' spans.
Do you prefer I'll add the extraction part to this PR? Or to create separated PR for that?

Copy link
Member

@mwear mwear left a comment

Choose a reason for hiding this comment

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

I have two minor comments / suggestions, otherwise, LGTM.

@ericmustin
Copy link
Contributor

@YanivD I'd say lets move the extract stuff into a seperate PR if possible so we can get this chunk of work merged (i see you've already pushed up some commits, apologies for the delayed response), the extract stuff is probably going to take a bit of time to review and get feedback for, and i don't want that to block the work you've already done here from getting released

@YanivD
Copy link
Member Author

YanivD commented Jan 12, 2022

@open-telemetry/ruby-maintainers
Is there anything left to do before merging this PR to main branch?

@habmic
Copy link
Contributor

habmic commented Jan 18, 2022

Do you know when this PR will be merged?

@ericmustin
Copy link
Contributor

@habmic @YanivD ack'd, will make sure this gets surfaced at SIG today

return super unless context

service_name = context.client.class.api.metadata['serviceId'] || context.client.class.to_s.split('::')[1]
service_name = context.client.class.api.metadata['serviceId'] || context.client.class.to_s.split('::')[1] rescue context.client.class.to_s.split('::')[1] # rubocop:disable Style/RescueModifier
Copy link
Contributor

Choose a reason for hiding this comment

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

What is this intended to do? The rescue clause contains the same expression as the right side of ||, so if that raised an exception, then the rescue clause will as well.

Copy link
Member Author

@YanivD YanivD Jan 19, 2022

Choose a reason for hiding this comment

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

Updated service_name extraction 1a59955

This change was to support 2.0.x versions. When using 2.0.x, metadata method expect an argument, what raised an exception.

Please review this change and approved it's safe.

@fbogsany fbogsany merged commit 658440f into open-telemetry:main Jan 19, 2022
@nvolker
Copy link

nvolker commented Apr 13, 2022

@YanivD just a question on the "What's Missing" part of your description. Specifically "I'm planning to add support in another separated PR", is this to do with extractor propagation on the receiver side? And are you actively looking into this?

I'm currently going with the following configuration and building out my own bespoke propagation extractor to allow the trace to continue in a consuming service:

  c.use "OpenTelemetry::Instrumentation::AwsSdk", {
    inject_messaging_context: true,
    # suppress_internal_instrumentation: true # I thought I'd want this but I don't, as it still sends `receive` spans
  }

If you have any advice for the interim, that would be appreciated! Really appreciate the work you've done here thus far.

@YanivD
Copy link
Member Author

YanivD commented Apr 13, 2022

@nvolker
I have implemented the extraction part on my fork, it's still a draft and not fully ready to review. You can see it here - YanivD#12

If you have the time to finish the changes and open PR - it will really help and you are very welcome :)
Otherwise, I'll probably get to it and the next few weeks and will open a PR

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.

10 participants