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