Out of the box DT for SQS

[kbford56]

Is your feature request related to a problem? Please describe.

Would it be possible for the Java Agent to provide support for Distributed Tracing for SQS out of the box? Customer has described 2 use cases:

1. Simple SQS – I’ve seen a few of our services enqueue message in SQS because of an incoming source HTTP request. Today, when we pull down the SQS message, it’s not linked to the source HTTP request, which could be helpful.
2. SNS to SQS Subscriptions – A for more common pattern, at least specific to my team, is that we have async services that are interconnected to each other via SNS topics that broadcast out to a set of SQS queues. Because my team uses this pattern so much, I’m manually writing logic to inject the NR transaction headers into the SNS topic and then reinsert them into the destination service that continues processing the request.

Feature Description

Distributed Tracing supported across SQS & SNS as described above.

Note : During initial spiking, we should consider other potential scenarios above/beyond those above.

Describe Alternatives

N/A

Additional context

N/A

Priority

Please help us better understand this feature request by choosing a priority from the following options: [Really Want]

[workato-integration[bot]]

https://new-relic.atlassian.net/browse/NR-258710

[kbford56]

There may be an agent extension available from the NR Labs team that can serve as a starting point

[elucus]

NR Labs version: https://github.com/newrelic-experimental/newrelic-java-aws-sqs

[obenkenobi]

It is possible for us to set up distributed tracing for producers where we add new message attributes. For consumers on the other hand it is not possible due to how the SDK works. Whenever we receive messages, it is in bulk. If the recieveMessage gives us 1 message from one app but another from a different app, we can only pick one to accept as the parent app. This is fundamental to how distributed tracing works.

This is a similar issue faced with our Kafka instrumentation. So the solution to only add out of the box DT for producers replicates an existing pattern.

[obenkenobi]

@elucus In contrast, NR Lab's approach adds DT for consumers, however it accepts every message's inbound headers and only assumes one entity is producing to a queue.

However, since you receive more than one message using the sdk, if one or more message comes from two different New Relic entities, only one parent entity will be linked leading to the other(s) not to be linked for a certain trace. In that scenario, manual instrumentation is preferred.

This is also why we did not add out of the box DT for SQS.

[obenkenobi]

Another update, our decision is to support out of the box DT for producers but not for consumers.