db.cluster namespace for RDBs

[mathias]

Area(s)

area:db

Is your change request related to a problem? Please describe.

We'd like to be able to standardize in our services on an attr for naming MySQL clusters. This should just be a short name identifier, not a hostname+port. And it is not a specific instance (we have many instances in one cluster.)

Describe the solution you'd like

The two things we've discussed are db.cluster.name or something namespaced (like ElasticSearch does with db.elasticsearch.cluster.name) as db.mysql.cluster.name. But this could also be more generally applied to RDBs beyond just MySQL, and it would still mean the same thing.

Describe alternatives you've considered

As described above. Alternatively we have a number of internal apps using our own namespace and variations like:

• namespace.db -- too short to indicate what's in it
• namespace.db.connection.cluster.name -- verbose
• namespace.env -- confusingly, this was actually cluster names internally, and so we need to work with them to change it either way.

But I'm hoping to propose and get a db.* namespaced attr that we can all agree on, to standardize these use cases on.

Additional context

Prior art: #345 for our instances, but now we need to identify MySQL clusters by name.

[mathias]

Once I'm advised on how to proceed here, I can open a PR to add it to the conventions. I just wanted to ask for guidance here. Thanks in advance!

[lmolkova]

A couple of questions:

• could you elaborate on why the combination of host:port (assuming it's the same for all nodes in the cluster) would not work?
• how would instrumentation libraries learn that they're connecting to a cluster and what's the cluster name?

[mathias]

Hello, a cluster is a collection of multiple servers that all have the same cluster name. For example, we may have a users cluster that contains a leader and many replicas. The host and port are not the same for all of those database services. It is not as useful here to use host:port when we want to group together metrics by cluster.

We plan to send this information based on the queries being set in our application, as exception metadata. It would be set while reporting other details in an exception. I am not sure if that answers your second question.

[lmolkova]

so, if I understand correctly, this attribute is intended for your own manual instrumentation within your application?
Would anything stopped working if you defined an attribute within your project (e.g. {company}.{project}.db.cluster)?

The reason I'm asking is that most of attributes defined in DB semconv are populated by instrumentation libraries automatically without knowing any application specific details. I'm trying to understand what's the value (to you) of adding this very specific manually populated attribute to semconv (given it can be changed, removed, deprecated, etc in the future) instead of documenting one within your project.

[mathias]

We will go ahead with defining our own .cluster.name attribute. We were just trying to standardize given other things fit into the db.<attr> namespace. 👍