[collectd] 3.10.1 - proposed patch to extend sensors plugin

[Florian Forster]

Hi,

On Sun, Oct 22, 2006 at 07:50:52PM +0200, Lubo?? Stan??k wrote:
> > 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 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..?

> > 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 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 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?

> I am sorry, I got the collectd's code at Friday and I have not got
> deeply inside so far.

No problem, so far you have proven to have an eye for weak spots, which
is always welcome :)

Regards,
-octo
-- 
Florian octo Forster
Hacker in training
GnuPG: 0x91523C3D
http://verplant.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mailman.verplant.org/pipermail/collectd/attachments/20061023/a3b09782/attachment.pgp