Cater for more messaging operations

[thompson-tomo]

Area(s)

area:messaging

What's missing?

I want to have clear consistent & easy to follow information as to what spans are to be implemented and by whom when looking at messging. As currently the docs are not clear and hard to follow.

Describe the solution you'd like

Diagram showing the relations between the spans for both consumer & producer. Greater clarity for how single messages are different to batches.

Introduce new operation types for messaging:

• Connect
• Disconnect
• Publish: described in https://opentelemetry.io/docs/specs/semconv/messaging/messaging-spans/#producer-spans but missing from the tables
• Check: when the connection is being checked

These operations can then flow to metrics.

My thinking is when sending message directly would result in the below spans

• Publish: covers the entire operation ie publish & send. Attribute used to indicate publish type is direct
• Create: covers the process to generate the content ie serialisation
• Send: covers sending of the message

[joaopgrassi]

We deliberately moved from publish to `send in this PR (where you can also see the reasoning and discussion #1285. So I believe we won't go back to adding publish as an operation type.

Publish: described in opentelemetry.io/docs/specs/semconv/messaging/messaging-spans#producer-spans but missing from the tables

That is a mistake, I will fix it. I will also give another try to make the example tables a bit more aligned/clear.

The idea is that we have the the messaging.operation.type as a generic as possible, so we went with send there after many discussions. Then there's messaging.operation.name which is system-specific and open, which means, for systems such as Kafka, where the term publish is more common, then that should be used. That's why you can see that in the example tables.

And that is also nice, since messaging.operation.name is part of the span name, you will get publish X.