-
Notifications
You must be signed in to change notification settings - Fork 586
Description
Is your feature request related to a problem? Please describe
Currently the aws-lambda instrumentation does not support context propagation when using an sqs event source mapping. The aws lambda instrumentation offers the possibility of providing a custom context extractor. I've considered using this when initializing the aws-lambda instrumentation. However I believe it is not sufficient.
When a lambda function processes sqs messages, according to semantic conventions we should be linking all the sqs process spans back to their producer span: https://opentelemetry.io/docs/specs/semconv/messaging/messaging-spans/#consumer-spans
SQS Messages can contain batches of messages, so there is no easy way of extracting 1 context to set as parent or link back to, unless your batch only contains 1 message. That's why I believe the custom context extractor can not be sufficient for this usecase.
Describe the solution you'd like to see
In aws-lambda instrumentation, we should identify whether an input event contains sqs records. If it does we should do something similar to what the aws-sdk instrumentation is already doing, to link processing spans back to the producing spans by extracting context from the message system attributes.
Describe alternatives you've considered
Initializing the aws lambda instrumentation with a custom context extractor when dealing with sqs input events (in opentelemetry-lambda nodejs layer: https://github.com/open-telemetry/opentelemetry-lambda/blob/main/nodejs/packages/layer/src/wrapper.ts#L309). However, as explained above I don't see this working as we possibly need to link multiple processing spans (for each message in a batch) back to their respective producer span.