Sensors input plugin

Hey guys,

I was wondering what the rationale might be behind using the -u flag in the sensors command. From the documentation of the sensors command:

-u     Raw output. This mode is only meant for debugging.

In my use case, the output of the sensors command is a bit different than what the input plugin expects, rendering it unusable. I think the -u option makes the command’s output unreliable across different distributions/kernels and different versions of lm-sensors itself.

Isn’t it a lot better to rely on the intended command output, i.e only:

sensors -A

I’ve cross referenced the output across some of our machines with different kernels and different distributions and there seems to be a consistency in the format. Furthermore, without the -u flag, the input could perhaps extract the unit of the measurement. In the current state the field names are not very readable and the untis are not clear.

Consider the following example:

[root@XXXXXX ~]# sensors -u -A
coretemp-isa-0000
Core 0:
  temp2_input: 43.00
  temp2_max: 85.00
  temp2_crit: 95.00
  temp2_crit_alarm: 0.00
Core 1:
  temp3_input: 41.00
  temp3_max: 85.00
  temp3_crit: 95.00
  temp3_crit_alarm: 0.00
Core 9:
  temp11_input: 39.00
  temp11_max: 85.00
  temp11_crit: 95.00
  temp11_crit_alarm: 0.00
Core 10:
  temp12_input: 40.00
  temp12_max: 85.00
  temp12_crit: 95.00
  temp12_crit_alarm: 0.00

coretemp-isa-0001
Core 0:
  temp2_input: 40.00
  temp2_max: 85.00
  temp2_crit: 95.00
  temp2_crit_alarm: 0.00
Core 1:
  temp3_input: 37.00
  temp3_max: 85.00
  temp3_crit: 95.00
  temp3_crit_alarm: 0.00
Core 9:
  temp11_input: 37.00
  temp11_max: 85.00
  temp11_crit: 95.00
  temp11_crit_alarm: 0.00
Core 10:
  temp12_input: 41.00
  temp12_max: 85.00
  temp12_crit: 95.00
  temp12_crit_alarm: 0.00

Compared to this:

[root@XXXXXXX ~]# sensors -A
coretemp-isa-0000
Core 0:      +38.0°C  (high = +85.0°C, crit = +95.0°C)  
Core 1:      +38.0°C  (high = +85.0°C, crit = +95.0°C)  
Core 9:      +38.0°C  (high = +85.0°C, crit = +95.0°C)  
Core 10:     +40.0°C  (high = +85.0°C, crit = +95.0°C)  

coretemp-isa-0001
Core 0:      +37.0°C  (high = +85.0°C, crit = +95.0°C)  
Core 1:      +37.0°C  (high = +85.0°C, crit = +95.0°C)  
Core 9:      +36.0°C  (high = +85.0°C, crit = +95.0°C)  
Core 10:     +38.0°C  (high = +85.0°C, crit = +95.0°C) 

Parsing the latter would bring a consistent and meaningful output. Additionally, there will be no need of the “remove_numbers” configuration.

To summarize, I think removing the -u flag and rewriting the plugin will widen its use case and improve stability and correctness.

I will be writing a separate plugin in all cases and am willing to submit a PR. Would you consider replacing the current plugin, with a one not relying on the -u flag?

Some further thoughts,

Parsing the unit of the measurements might be a really good improvement.

The sensors package might not necessarily extract only readings of CPU temperatures. We have a couple of servers, where there are sensors for the fan speeds and voltages. In its current form, it is a bit hard to extract meaningful data from the plugin and build generic dashboards out of it. With a lot of servers using the plugin, we would have to create a custom query for each server.

Gathering the measurement unit, however, might ease this a bit. One could, for example, only query the sensor readings, which have “C” (temperature) as a unit and group by feature/chip.

Hey,

Here’s a first attempt to remove the -u flag and parse the command’s output: