[collectd] non-C-based plugins

[Florian Forster]

Hi Seth,

On Sun, Nov 05, 2006 at 12:46:42PM -0500, seth vidal wrote:
> As far as monitoring goes it seems like most of the widely-used ones
> support pretty much arbitrary plugin types.
> 
> Would you consider a plugin in C that took a command as its argument
> and expected returns back in a specific order?

the problem is, that only the plugins now how to generate the RRD-files.
This information needs to be provided by the script (or the config).
So three parts would be neccessary: An instance name, a DS-type and the
actual value.

The simplest way is probably to configure a script to return one DS-type
or another and have each script to return only one value. This, however,
is not the most practical solution. Configuring a script as returning a
fixed DS-type and let it return multiple values might be an acceptable
compromise. And, the last choice that I see as being reasonable, would
be to let the script describe the value in some more detail. I'll assume
this last possibility in the fictional examples below.

A script `daemon' could, for example, return values like this, by simply
writing them to stdout.
-- 8< --
 gauge,connections,123
 counter,attempts,98754
-- >8 --

The values could be written to RRD-files named like this:
 exec-daemon/gauge-connections.rrd
 exec-daemon/counter-attempts.rrd

The config could look like this:
 <Plugin exec>
   Exec daemon /path/to/the/script arg0 arg1
   ...
 </Plugin>

Does all that make any sense and sound reasonable?

> I know you'd be forking off a process in that case but then:
>  1. it's left to the user to decide what is or is not too much forking
>  2. it provides nearly infinite flexibility for what data is gathered
>     and using what languages.

All in all you're right: I'd prefer to have a perl-, python-, and/or
rupy-plugin that can execute {perl,python,ruby}-scripts. But noone needs
to use an exec-plugin. The bottom line being more flexibility without
any harm to people with performance concerns.. So, sure I'd accept it :)

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/20061105/9ca96143/attachment-0001.pgp