[collectd] A few problems and suggestions

Florian Forster octo at verplant.org
Mon Mar 17 10:43:23 CET 2008

Hi Marco,

On Sun, Mar 16, 2008 at 12:31:02PM +0100, Marco Chiappero wrote:
> - sensors reading (through lm-sensors) isn't fully working: first of 
>   all, it seems to me there's no support for libsensors4 yet, so
>   libsensors3 package is needed; then everything is collected but the
>   temperatures, making the sensors plugin quite unuseful.

libsensors4 is supported since collectd 4.1.5 and 4.2.3. Are you using a
precompiled package? If so, where from? And why is libsensors3 missing
your temperatures? Does the command-line `sensors' tool work?

> - the ping plugin don't work. It's totaly silent, nor data neither
>   logging. (yes, liboping0 is already installed)

Sorry, but I didn't find a control path in the ping plugin so it can
fail without logging at least a warning.

> - the hddtemp plugin prevent hdparm to put drives in standby mode
>   after a certain period of time: so, hdparm -S <time> /dev/hd? don't
>   work anymore (hdparm -y /dev/hd? does, but it's unuseful to me).

What can _we_ do different here? IIrc the hddtemp plugin simply connects
to and reads from the hddtempd using a socket.

> - I'd rather have some values stored in a single rdd file rather than 
>   having to plot many files in a single graph. I can see that the
>   interface plugin beaves like that, storing rx and tx data together,
>   right? How can I use the types.db for this purpose (for example for
>   the CPU activity or for the sensors readings, recording different
>   temps or different fans in a single rrd)? Is it possibile?
>   Documentation about types.db it's really essential.

No you can't. Different operatring systems have different CPU states.
The only way to get all that in a nice, clean and (most important of
all) forward-compatible structure is to split up the RRD files.

If we can help you solve any of the first three issues please let us
know. A simple ``doesn't work'' is a bit too sparse to debug the

I know that the last point is a bit annoying, but it's the only way to
design a system that will work with systems five years from now. Since
this question has come up at least twice before, I've added it (and the
answer) to the FAQs:

Florian octo Forster
Hacker in training
GnuPG: 0x91523C3D
-------------- 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/20080317/332c633e/attachment.pgp 

More information about the collectd mailing list