Potentially unbounded dimensions in Hardware metrics?

[joaopgrassi]

trafficstars

In https://github.com/open-telemetry/semantic-conventions/pull/17 we discussed the problem with the http.request.method attribute being problematic because it could be a potential candidate for unbounded dimension values. It is subject to users sending requests with different methods and the instrumentation recording metrics using that value.

As others have pointed out, this could be a general problem with attribute in other metrics. I took then a look at all of our existing metrics semantic conventions with the same "eye" looking for attributes suffering from the same problems.

I was only able to find these attributes under the Hardware metric conventions:

• hw.type: Have several examples, but since it's "open" I wonder if this could cause problems?
• hw.error.type: Same thing as above: Not defined in an enum or something, so could be unbounded
• logical_addresses: Could the address change frequently on a device/adapter?

Creating this issue to revisit these before declaring it stable.

[eero-t]

• hw.type: Have several examples, but since it's "open" I wonder if this could cause problems?
• hw.error.type: Same thing as above: Not defined in an enum or something, so could be unbounded

I don't see how there could "infinite" amount of HW types or HW error types. Could you give an example of a such situation?

(While there can be bugs in metric exporters, but that's a concern for all labels, not just these.)