Non-namespaced attributes for metrics

[pmm-sumo]

What are you trying to achieve?

Attribute naming conventions specify that all names SHOULD be part of a namespace.

However, for many of the collector database receivers this is usually not the case and they list non-namespaced attributes (which are not part of the specification). For example, this is the case for mysqlreceiver, mongodbreceiver, postgresqlreceiver and others

On the other hand, some of the database metrics receivers follow the requirement. E.g. sqlserverreceiver (only two attributes listed though)

This brings a question if new metrics receivers should follow the other receivers implementation (non-namespaced attributes) or semantic conventions recommendations (namespaced attributes). This will further lead to either of two actions:

Option 1: the recommendations might be changed and e.g. allow for non-namespaced names being used for the attributes (perhaps only at the record-level). This might be sound for metrics when the metric name is already namespaced.

Option 2: the metric receivers implementation should follow the specification and add namespaces.

[pmm-sumo]

Some notes from the SIG:

• Metrics had "labels" in the past, which were something different than attribute
• We need to be cautious of the attribute name, which might impact e.g. Prometheus
• Having consistent naming (with namespaces) would avoid confusion across the signals though

It would be beneficial to bring some examples of attributes with/without namespaces and see how they look

[jamesmoessis]

Option 2: the metric receivers implementation should follow the specification and add namespaces.

I like this option. Is there any reason that the metric receivers can't follow the datbabase semantic convention? If there doesn't exist a semantic convention for an attributes, and it is a general-enough use case, then IMO it should be added to the semantic convention. This means the same metric will be consistent elsewhere.