-
Notifications
You must be signed in to change notification settings - Fork 248
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
Conversation
@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. |
@ericmustin |
Updated the pr, now the tests are green and ready for review. |
instrumentation/aws_sdk/lib/opentelemetry/instrumentation/aws_sdk/messaging_helper.rb
Outdated
Show resolved
Hide resolved
Thanks @ericmustin @open-telemetry/ruby-maintainers |
@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. 🎅 😅 |
I want to update that I'm working on extracting SQS context, for creating 'process' spans. |
There was a problem hiding this 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.
instrumentation/aws_sdk/lib/opentelemetry/instrumentation/aws_sdk/messaging_helper.rb
Outdated
Show resolved
Hide resolved
instrumentation/aws_sdk/lib/opentelemetry/instrumentation/aws_sdk/handler.rb
Outdated
Show resolved
Hide resolved
…sdk/messaging_helper.rb Co-authored-by: Matthew Wear <matthew.wear@gmail.com>
@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 |
@open-telemetry/ruby-maintainers |
Do you know when this PR will be merged? |
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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
instrumentation/aws_sdk/lib/opentelemetry/instrumentation/aws_sdk/messaging_helper.rb
Outdated
Show resolved
Hide resolved
@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. |
@nvolker If you have the time to finish the changes and open PR - it will really help and you are very welcome :) |
What's added in this PR?
SQS.SendMessage
,SQS.SendMessageBatch
andSNS.Publish
methodsContext 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