Messaging: generalize common attributes to future-proof metrics

[lmolkova]

See #760 (comment)

One of the options to minimize future breaking for generic metrics when specific messaging extension decides to add an attribute, is to generalize a few common attributes.

While in general this approach is problematic, there are several common patterns we should consider:

• Partition Id. Partitioning is common technique used by Kafka, Azure EventHubs, Apache Pulsar, GCP PubSub. Partitioning is the first-class citizen exposed through public API and important for observability. Things like throughput, consumer lag, other important properties can be quite different per partition.
• Consumer group. Another common approach to have multiple groups of consumers that process different positions in the topic and synchronize checkpoint/loadbalance within the group. Supported by Kafka, Azure EventHubs, rocketmq, NATS
• A very similar thing called subscription (ability to fan-out messages to multiple groups of subscribers) exists for GCP PubSub, Azure ServiceBus, Apache Pulsar
• Delivery/commit mode (auto-commit). Review Kafka and RabbitMQ attributes  #751 for the details on Kafka and RabbitMQ, aka Receive-And-Delete on Azure Service Bus. Not clear if it's useful on metrics

[pyohannes]

Partitions and consumer groups are concepts usually associated with systems that do checkpoint-based settlement (instead of individual message settlement).

Currently, all attributes we've defined for generic metrics apply to all messaging systems independently of the settlement style.

While I'm all in favor of generalizing attribute naming (e. g. to messaging.destination.partition.id), let's further discuss adding such attributes to generic metrics. I'm not yet sure if we should attributes that are of no use at all to certain systems.

[lmolkova]

I'm not yet sure if we should attributes that are of no use at all to certain systems.

I wonder if we can entertain an idea of messaging.destination.path that would fully identify destination from the consumer side and include subscription name, consumer group, partition or anything else.

Essentially the somewhat catch-all attribute of the highest cardinality, You can still add messaging.pulsar.subscription.name to the same metric if subscription name already appears in the generic messaging.destination.path.

This also pushes a problem to pick a good messaging.destination.path onto the instrumentation (or semconv extension) author and if they didn't put fully qualified thing there, they might need to do breaking changes in the library. Spec in the case remains stable. Sounds not great, but minimizes the blast radius of breaking changes.

[pyohannes]

I wonder if we can entertain an idea of messaging.destination.path that would fully identify destination from the consumer side and include subscription name, consumer group, partition or anything else.

There are two things that should be separated:

1. A consistent definition of a destination that can apply to both producers and consumers. For checkpoint-based systems, this would involve a destination name (a topic name) and a server address.
2. A complete definition of a destination for consumers. This involves the destination name (topic name), the server address, the partition id, and a consumer group.

We should be able to separately identify both.