Improve guidelines for sensor_location attribute in hardware section

[sebastien-rosset]

What are you trying to achieve?

Improve semantic guidelines for sensor_location attribute.

What did you expect to see?

In the hardware semantic guidelines:

1. Provide optional attributes to link the temperature metrics to hardware components such as CPU, fan or battery.
2. The name of the sensor_location attribute should be hierarchical. See Attribute names in semantic guidelines should be hierarchical #3131.

Additional context.

In Semantic Conventions for Hardware Metrics, some components have a sensor_location attribute. For example, fan, temperature and voltage have a sensor_location attribute.

The example values include cpu0, ps1, INLET, PS0 V3_3, CPU0_DIE. Some of these examples are sensor values that are reported by IPMI.

It makes sense to use sensor_location for temperature and voltage, as this indicates the precise location of the sensor that measures the temperature metric or voltage metric. However, without additional attributes, it would be difficult to determine which physical component that temperature/voltage sensor is associated with. For example, if sensor_location is CPU0_DIE, I may be able to lookup a data sheet and find out it's the temperature sensor of the CPU in socket 0. But it wouldn't be easy to map it to a CPU slot or CPU vendor/model/serial.

Fan

The fan component section defines the sensor_location of a fan to be:

sensor_location: Location of the fan in the computer enclosure

It's confusing to overload the sensor_location attribute to be the location of the fan. A Fan is not a sensor. It's a physical component that may have zero or more sensors for temperature, rpm, etc.

Proposal

It would be helpful to provide guidance and examples for the id, name and parent attributes, and how the values related to the hardware component. For example, if a CPU has id="cpu_12345abc35_0", what should be the id, name and parent attribute value reported by the temperature instrument? Should the value of parent for the temperature instrument be set to "cpu_12345abc35_0" (the id of the CPU)? If not, how does a user know the temperature metric is associated with the CPU?

How about adding vendor, model and serial_number as optional attributes?

[bertysentry]

Unfortunately, it's difficult to mandate the proper identification of the location of a temperature sensor. Sometimes it's not even associated to another electronic component (like the sensors measuring the ambient temperature, in or out).

But when the instrumentation layer can determine the component the sensor is attached to, then yes, as you suggested, the parent attribute should be used to properly associate a temperature metric (hw.temperature{parent="cpu0"}) with the corresponding device (when monitored with another metric, like hw.status{id="cpu0"}). To be even more precise, the parent type should be specified as well: hw.temperature{parent_type="cpu", parent="cpu0"}. But then, that make me think that the parent attributes should be properly namespaced:

• hw.parent.id
• hw.parent.type

What do you think?

WRT extra attributes like vendor, model, and serial_number, they are rarely available for temperature sensors, but the developer always has the ability to add such additional attributes, when they are relevant.

[sebastien-rosset]

To be even more precise, the parent type should be specified as well: hw.temperature{parent_type="cpu", parent="cpu0"}

I agree, because it's possible that the same name may exist across two different parent types. This would help to disambiguate.

But then, that make me think that the parent attributes should be properly namespaced

I'm not sure I'm following why adding a "parent_type" implies the attribute should be namespaced? Is it motivated by the fact there would be a new "hw.parent" namespace, and that namespace has at least two attributes (id and type)? If yes, I agree.

As a related topic, we have multiple scenarios where there is an ancestor hierarchy. For example the parent of a physical Ethernet port may be a network adapter, which may be the child of a server. Having the denormalized ancestor hierarchy is often useful when querying data efficiently.