Amazon SQS: How to Represent HTTP Span?

[astorm]

The Amazon SQS APIs are queue operations, but the API communication protocol is REST/HTTPS based. This means a call to an SQS method (receiveMessage, sendMessage, etc.) creates a span for the message send, but also a span for the HTTPS request.

It's unclear how this should be represented in the span tree. Do users want to see the spans for HTTP messages AND the SQS API calls, or do they want to see a single span for the entire operation. This is similar to the issue we face with the @elastic/elasticsearch instrumentation in #2000

We need to decide on "hide the HTTP span, show the HTTP span, or 'it depends on the specific message'", and whether there should be a generic way of handling this increasingly common use case for APIs.

[trentm]

This was discussed on the APM Agents call yesterday. The pretty strong consensus seemed to be to not emit HTTP spans (or whatever other transport span) underneath higher-level instrumentation spans: e.g. no HTTP span underneath an SQS span, no HTTP span underneath an Elasticsearch span.

Also this note from eyal:

Still, as @axw mentioned, there may be value in keeping lower-span-data (like HTTP status code or URL) when you have such, and the way we chose doing that for ES client spans is by populating context.http fields, even though the span type is not HTTP.

[trentm]

This was resolve in #2645