-
Notifications
You must be signed in to change notification settings - Fork 893
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
Context and baggage propagation over Queues is loosely defined #2516
Comments
This is something we have been actively discussing in the messaging workgroup (meeting weekly Thursdays 8am PST). In the OTEP we are currently working on we explicitly state basic requirements for context propagation, without going into details of how those requirements can be met for every single messaging system or protocol. Those details will be a future work item, as laid out in the same draft document. It is not even clear yet whether these details should be part of OpenTelemetry semantic conventions. For example, for AMQP and MQTT there are W3C draft documents specifying mechanisms for propagating context. |
@oxeye-nikolay I think this belongs to |
You're right @reyang . My bad |
This is partly covered by #2750, which lays out general requirements for context propagation in messaging scenarios. As mentioned in a comment above, this doesn't go into details of how those requirements can be met for every single messaging system or protocol. |
I am looking into creating instrumentation in python that will propagate traces over SQS messages. I have begun looking into the specification and noticed that the context propagation way is loosely defined. Therefore I have decided to look into how was it implemented in other languages. I looked into ruby and nodejs.
I noticed that both set up to 10 attributes, to comply with SQS's attributes requirements. This, however, means that a message can be sent with partial context. Also, there are additional rules to SQS's MessageAttributes (like
Can't start with AWS. or Amazon. (or any casing variations)
) that are not being enforced.It seems that there is no specification defined that settles exactly how should this information be propagated over messages and takes into consideration limits from queue systems like this.
I would expect to see an explicit definition in the spec, naming the exact headers that appear in the message attributes.
The text was updated successfully, but these errors were encountered: