DB/messaging: do we want to have generic client (instance) id attribute

[lmolkova]

We have db.cosmosdb.client_id and messaging.client_id.
they are used to record unique identifier of a client instance - usually something random.
Kafka or other messaging systems have limits on number of consumers per partition and it could be helpful during debugging to see how many instances are created. Also useful to know if application creates clients too frequently (e.g. per request instead of a singleton instance).

If we're going to have more of individual systems/semconvs introducing it, it could make sense to have a generic attribute.

Related: open-telemetry/opentelemetry-specification#2015

[pyohannes]

I agree that a general definition would be good. However, there might be challenges to find a generic definition of what a "client instance" is.

[pyohannes]

From the messaging SIG: this doesn't necessarily block stability, as we can exempt the messaging.client_id from the initial set of stable attributes.

[lmolkova]

Based on DB and Messaging SIG discussions:

• it's very hard to describe what client instance id means in a generic case.
• client namespace is used to describe initiator of a remote call
• the use-case for SDK client instance id does not seem to be very generic
  • it helps to detect if someone creates excessive amount of client instances, but it might be visible by other means such as number of open connections, memory usage, profiling, etc
  • it also helpful as a correlation mechanism to debug SDK client state issues, but again the same information might be available by other means (correlated logs, connection level details, etc)
• It's unlikely that someone would build dashboards or alerts using the SDK client instance id attribute.

Given that we don't have a compelling use-case for a generic attribute or a descriptive and non-controversial name for it, I'm going to close this issue.