What problem do you want to solve?
Currently context propagation from sqs to aws lambda is not supported yet by the aws lambda instrumentation. It's possible to provide a custom context extractor to extract context from the incoming event the lambda is invoked with. However, it is not possible to do proper sqs context propagation and represent the trace in the right way prescribed by the spec.
The messaging spec prescribes having a separate process span, that has (a) span link(s) back to all messages within the batch of that event. (fyi due to batching, decoupling, and other nuances it's actually impossible to properly represent a trace with the producer span as parent of the consumer span)
Describe the solution you'd like
My previous work in the js instrumentation: open-telemetry/opentelemetry-js-contrib#2981 could be used as a reference implementation. This will build the right trace structure, adhering to the messaging spec. There's a dual-mode extraction setup: X-Ray TraceHeader by default to adhere to spec, opt-in for using global propagator and message attributes. The latter is what is used by most other aws-sdk instrumentation libs on the producing end, so it wouldn't make sense to only support X-Ray TraceHeader even though that would be spec-compiant.
Describe alternatives you've considered
No response
Additional Context
No response
Would you like to implement a fix?
Yes
Tip
React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it. Learn more here.
What problem do you want to solve?
Currently context propagation from sqs to aws lambda is not supported yet by the aws lambda instrumentation. It's possible to provide a custom context extractor to extract context from the incoming event the lambda is invoked with. However, it is not possible to do proper sqs context propagation and represent the trace in the right way prescribed by the spec.
The messaging spec prescribes having a separate process span, that has (a) span link(s) back to all messages within the batch of that event. (fyi due to batching, decoupling, and other nuances it's actually impossible to properly represent a trace with the producer span as parent of the consumer span)
Describe the solution you'd like
My previous work in the js instrumentation: open-telemetry/opentelemetry-js-contrib#2981 could be used as a reference implementation. This will build the right trace structure, adhering to the messaging spec. There's a dual-mode extraction setup: X-Ray TraceHeader by default to adhere to spec, opt-in for using global propagator and message attributes. The latter is what is used by most other aws-sdk instrumentation libs on the producing end, so it wouldn't make sense to only support X-Ray TraceHeader even though that would be spec-compiant.
Describe alternatives you've considered
No response
Additional Context
No response
Would you like to implement a fix?
Yes
Tip
React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding
+1orme too, to help us triage it. Learn more here.