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

Instrumentation for SNS/ SQS #1613

Open
febinrejoe opened this issue Jan 28, 2022 · 5 comments
Open

Instrumentation for SNS/ SQS #1613

febinrejoe opened this issue Jan 28, 2022 · 5 comments
Labels
enhancement New feature or request instrumentation: otelaws question Further information is requested

Comments

@febinrejoe
Copy link

Problem Statement

This could be more of a question rather than a feature request. I was wondering if we have a way to instrument Go for SNS/ SQS transactions. To give some background, I have a Go service (Service A) which talks to another service (Service B) via SQS and I would like to do tracing across these services. Any help with this will be greatly appreciated.

@MrAlias
Copy link
Contributor

MrAlias commented Jan 28, 2022

Would the AWS client instrumentation work?

@Aneurysm9
Copy link
Member

I think that might trace the interaction with the SNS/SQS service, but it sounds like what's needed here is context propagation in messages carried by those services. Is that correct?

If so, there are a few options. You could use the propagation API to inject trace context data into the messages at the producer and extract it at the consumer. This could also be done using message attributes instead of the message body.

The second option would be to create a middleware for the AWS SDK v2 that could identify SQS requests/responses and handle the propagation automatically. Not quite sure how this would hand back an extracted span context to a consumer, but it might be an avenue worth exploring if you're using the v2 SDK.

The third approach would be to wrap the SDK client, similar to the Sarama instrumentation.

@Aneurysm9 Aneurysm9 transferred this issue from open-telemetry/opentelemetry-go Jan 28, 2022
@febinrejoe
Copy link
Author

Thanks @Aneurysm9, I will need message propagation as well. I will look into the options provided.

@MrAlias MrAlias added instrumentation: otelaws enhancement New feature or request question Further information is requested labels Nov 2, 2022
@mtcherni95
Copy link

I have a very similar use-case to yours, @febinrejoe . Any advancement in your solution? Thank you!

@udhos
Copy link

udhos commented Jun 25, 2023

I am currently sketching this carrier to perform context propagation across SQS messages using message attributes.

// ContextFromSqsMessageAttributes gets a tracing context from SQS message attributes.
// `sqsMessage` is incoming, received SQS message (possibly) carring trace information in the message attributes.
// Use ContextFromSqsMessageAttributes right after receiving an SQS message.
func ContextFromSqsMessageAttributes(sqsMessage *types.Message) context.Context

// InjectIntoSqsMessageAttributes inserts tracing from context into the SQS message attributes.
// `ctx` holds current context with trace information.
// `sqsMessage` is outgoing SQS message that will be set to carry trace information.
// Use InjectIntoSqsMessageAttributes right before sending out the SQS message.
func InjectIntoSqsMessageAttributes(ctx context.Context, sqsMessage *types.Message)

https://pkg.go.dev/github.com/udhos/opentelemetry-trace-sqs@main/otelsqs

It might be useful to some.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request instrumentation: otelaws question Further information is requested
Projects
None yet
Development

No branches or pull requests

5 participants