RabbitMQ: Specify how to populate messaging.destination.name

[joaopgrassi]

Fixes #1529

Changes

Specify in more detail how to populate messaging.destination.name for RabbitMQ. I based it on the Default exchange docs. My understanding is that a routing key is always present, even when using the default exchange (empty in this case). The routing key then is the queue name.

For all other cases, I left it as amq.default which is what RabbitMQ uses. I saw reference for it for example here: https://www.rabbitmq.com/docs/access-control

For convenience RabbitMQ maps AMQP 0-9-1's default exchange's blank name to 'amq.default' when performing permission checks.

Merge requirement checklist

• CONTRIBUTING.md guidelines followed.
• Change log entry added, according to the guidelines in When to add a changelog entry.
  • If your PR does not need a change log, start the PR title with [chore]
• schema-next.yaml updated with changes to existing conventions.

[lmolkova]

I think we have a problem on the consumer (even before this PR).

If someone publishes a message to exchange with a routing key and then there are bindings that route messages with this key to a queue (or queues) with a different name, then we have 3 things on the consumer side:

• we still have access to exchange and routing key - https://www.rabbitmq.com/docs/consumers#message-properties
• plus we have a queue name from which we got the message

and we have just two attributes (mesasging.destination.name and messaging.rabbitmq.routing_key) to store them

[joaopgrassi]

Yes, I also stumbled on the same thing, where does the queue fits into these two attributes. To make matters worse, for example in the Java instrumentation the Queue name is what is used for the Span name, not the exchange nor the routing key.

For the notes on messaging.destination.name we have

Destination name SHOULD uniquely identify a specific queue, topic or other entity within the broker

It seems that for RabbitMQ (at least on the consumer side) that should be a combination of the three: exchange:routing_key:queue. And it seems the same should also be used for {destination} on the span name. I'm not sure it makes much sense to add a queue attribute, given the destination description already includes it.

[joaopgrassi]

I pushed a change, let me know what you think. b02ff2a

[lmolkova]

let's consider . to match what we do in DBs

[lmolkova]

maybe check if routing key and queue are the same and populate just one