[collectd] non-C-based plugins

[Luboš Staněk]

Hi,
I will not support the concept of the scripted plugins until some
threading solution.
I observed overstepping on a decently equipped dual cpu machine with
common plugins settings.
Of course we are speaking about simple statistical daemon that will not
suffer from skipped steps. We can of course increase the step time.
Another side effect is the amount of consumed memory by such plugins. It
will discriminate low resources systems like routers.

All I can see in this draft is a bunch of snmp clients which will slow
down the daemon's plugins read loop.
What plugins do you think about, Seth?

Better way would be to design threads, reusable common snmp plugin and
then we could see what would remain.

In case you mean it seriously, please do not forget to enable switching
this feature on/off in autoconf.

On the other side the scripted plugins concept is very attractive in the
case of solved step time and threading problems. It would probably
increase the number of plugins multiple times.

Best regards,
Lubos


Florian Forster napsal(a):
> 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 script can return the array of DS's and values as well written to
stdout.
Because the DS's would be probable static texts, it would not slow down
the plugin's output.


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