[collectd] 3.10.1 - proposed patch to extend sensors plugin

[Luboš Staněk]

Hi -octo,
your message explained me a lot about your expectations in the future
without reading the code.

I sent the second version of the patch which behaves better than the
first. (I sent it from the wrong account and it probably sits elsewhere
for approval.)
But according to your comments it is not the behavior you expect. I have
a better idea also (including your comments) and I will try to implement it.
So please do not use it (you can approve the message though for others
to see the progress). You can study it to see where I have got so far if
you have a spare time.


>>> Wouldn't it be reasonable, to do this the way it's done in the `traffic'
>>> plugin, i. e. have two config keys?:
>>> - `Sensor' to select the sensors that are interesting
>>> - `IgnoreSelected' to invert the selection
> 
>> I decided to implement only "Ignore" because I thought that the user
>> could either Ignore or IgnoreSelected about the half of the sensors.
>> The plugin gathers voltages, temperatures and fans. If you select old
>> behavior (e.g. only temperatures and fans), whichever method you use,
>> it is about the half of the sensors. On the other side, you can
>> exclude only several sensors from the full list, whis is saving in
>> comparion to IgnoreSelected. I believe that users will appreciate the
>> full list of sensors and really Ignore only some of them.
> 
> okay, maybe it's not worth the work, since
> a) sensors don't come and go, as interfaces might, and
> b) the number is usually small, i. e. <10, so listing (nearly) all of
>    them should still be no problem.
> 

I fixed it in the second version with options "Sensor" and
"IgnoreSelected". I intend to preserve it.


>> I intended to write to the mailing list that almost all plugins should
>> provide some way of Ignore or IgnoreSelected.
> 
> It's definitely a good addition to nearly every plugin.. Maybe some
> generic methods could be added to `common.[ch]' which can then be used
> by the plugins..?
> 

Yes, it would be definitely good.
It would be better to discuss it with other plugin authors.


>>> The instance should propably be `<chip>-<feature>', e. g.
>>> `w83781d-i2c-0-2d-temp2'.
> 
>> The patch assumes both instance and filename the same
>> (chip-bus-feature) similar to lm_sensors's sensors application.
>> Do you think that it would be better to rewrite the sensors_read,
>> sensors_submit and sensors_write to support double naming different
>> for instance and filename for versions <4?
> 
> Well, the _filename_ should start with `temperature', `fanspeed' or
> something that's the _type_ of the graph.
> 
> Having one directory for each (sensor-)chip is worth thinking about.. We
> could insert some sort of delimiter or design the new protocol so it can
> handle one instance for the plugin and one instance for the type. The
> name could then be something like this:
>   lm_sensors-<chip>/temperature-<feature>.rrd
>   lm_sensors-<chip>/fanspeed-<feature>.rrd
> 

I think looks like a good idea.
It would be acceptable and it would only partially solve my second
problem (I will mention it later).

lm_sensors-it8712-isa-0290/fanspeed-fan1.rrd
lm_sensors-it8712-isa-0290/fanspeed-fan3.rrd
lm_sensors-it8712-isa-0290/voltage-in0.rrd
lm_sensors-it8712-isa-0290/voltage-in2.rrd
lm_sensors-it8712-isa-0290/voltage-in3.rrd
lm_sensors-it8712-isa-0290/voltage-in4.rrd
lm_sensors-it8712-isa-0290/voltage-in7.rrd
lm_sensors-it8712-isa-0290/voltage-in8.rrd
lm_sensors-it8712-isa-0290/temperature-temp1.rrd
lm_sensors-it8712-isa-0290/temperature-temp2.rrd
lm_sensors-it8712-isa-0290/temperature-temp3.rrd
lm_sensors-it8712-isa-0290/voltage-vid.rrd

or from the second machine:

lm_sensors-lm85-i2c-0-2e/fanspeed-fan1.rrd
lm_sensors-lm85-i2c-0-2e/fanspeed-fan3.rrd
lm_sensors-lm85-i2c-0-2e/fanspeed-fan4.rrd
lm_sensors-lm85-i2c-0-2e/voltage-in0.rrd
lm_sensors-lm85-i2c-0-2e/voltage-in1.rrd
lm_sensors-lm85-i2c-0-2e/voltage-in2.rrd
lm_sensors-lm85-i2c-0-2e/voltage-in3.rrd
lm_sensors-lm85-i2c-0-2e/voltage-in4.rrd
lm_sensors-lm85-i2c-0-2e/temperature-temp1.rrd
lm_sensors-lm85-i2c-0-2e/temperature-temp2.rrd
lm_sensors-lm85-i2c-0-2e/temperature-temp3.rrd
lm_sensors-lm85-i2c-0-2e/voltage-vid.rrd
lm_sensors-lm85-i2c-0-2e/voltage-vrm.rrd


>> I have checked the contrib/collection.cgi and found that all sensors
>> (fans, temperatures and voltages) are "Celsius". I do not know who is
>> responsible for this code but my knowledge of Perl is desperately low.
> 
> That's exactly the flaw in the current naming: Since the files are named
> `sensors-*.rrd' they are all assumed to present the same type of data,
> and `sensors' is handled as if it was a temperature. That's precisely
> the reason why I want to have the files named `temperature-*.rrd' or
> `fanspeed-*.rrd'.
> 

The example above solves your problem (collection.cgi) but not mine (I
will mention it later).
It is very simple hack to know at least the type for units.


>> The lm_sensors's features naming scheme is consistent. It would last
>> forever. :)
> 
> I thought you could label the outputs whatever you felt like having them
> named?
> 

Yes this is the time to mention my second problem.

Frankly, I think that .rrd filename is not the proper place for the
source of graph titles, units and legends.

The filename like "sensors-lm85-i2c-0-2e/fanspeed-fan4.rrd" offers only
chip-bus-address, type and feature information. It is not enough for
really good-looking textual information in graphs like "Rear Fan". Or
what can you imagine under the label "partition 8-33" without my local
information?

Yes, I can dig into the local system information (sensors.conf and/or
libsensors API in my case) on the local machine to get such information.
But I cannot do the same in case of the server gathering sensors data
from client machines. I cannot do the same for a machine that R.I.P.
several years. I would have get the full access to system resources to
get such information - either remote access or in advance prepared
informations (always old). Or become a ghost in the case my machine has
gone.
And this is the problem I think about.

Every plugin could provide such information. In my case the "sensors"
plugin could provide the type, units, label, limits.
Thus we can provide the old fashioned file naming
"sensors-lm85-i2c-0-2e/fanspeed-fan4.rrd" and an extra file
"sensors-lm85-i2c-0-2e/info with descriptive informations.
This file could be used by the local creator of web pages, pdfs and so
on, to provide really good-looking information. The full directory
"sensors-lm85-i2c-0-2e/" could be archived and graphed after years with
the same information richness.

And, of course, it would be user selectable for security reasons.

And because I frequently translate applications into my language, such
information could be also translated to provide really good-looking
informations in the reader's native language.

So what do you think about gathering the descriptive informations from
plugins?


Best regard,
Lubos