[collectd] Proposal: Make collectdmon start several instances of collectd based on configuration file

[XANi]

Hi
Dnia 2010-02-23, wto o godzinie 18:03 +0100, Sebastian Harl pisze: about
that yet. Any comments would be appreciated.

> 
> > In an ideal world, you would set a DefaultInterval for all plugins
> > (20secs?) and then potentially overwrite that value in the
> > configuration of every plugin. That would be perfect. 
> 
> Yes, that is the idea, basically.
> 
> > But maybe there are restrictions, like a plugin could only have an
> > interval that is a multiple of the base interval?
> 
> There are no such restrictions (from a collectd-core architectural point
> of view). The question is, whether we want to introduce a config block
> for each and every plugin where most plugins will support a single
> config option ("Interval") only. This would, e.g., look like this:
> 
>   Interval 10 # default
> 
>   LoadPlugin cpu
>   LoadPlugin load
>   LoadPlugin postgresql
>   LoadPlugin rrdtool
> 
>   <Plugin cpu>
>       Interval 5
>   </Plugin>
> 
>   <Plugin postgresql>
>       Interval 60
>       # more postgresql configuration
>   </Plugin>
> 
>   # more configuration
> 
> Then, cpu would read its values using a 5 seconds interval, load would
> use the default of 10 seconds and postgresql would use 60 seconds. As I
> said before, the "downside" of this approach is that this feature has to
> be implemented in every single plugin.
> 

That would be imo most "user-friendly", because it keeps non-default
plugin config "close" to other configuration options (no need for
<LoadPlugin> and <Plugin> Sections)

> Another approach might be to do something like this:
> 
>   Interval 10
> 
>   <LoadPlugin cpu>
>     Interval 5
>   </LoadPlugin>
>   LoadPlugin load
> 
>   # more configuration
> 
> This could be implemented in the daemon itself, so it would not require
> a modification of every plugin. Plugins could still support a more
> specific "Interval" option (e.g., the "postgresql" plugin might want to
> support different intervals for querying different databases). However,
> that would introduce three different kinds of intervals: a global
> interval, a plugin specific interval overwriting the global
> configuration and a plugin instance (or whatever) specific interval
> overwriting the plugin specific interval. That might be confusing to
> users but it would probably require the least code changes and the most
> consistent behavior (as in: it's not possible to accidentally have some
> plugin not implementing the plugin specific interval option). Also, I'm
> not yet a 100% sure how to implement that [*].
> 
> Any comments about that?
> 
> Cheers,
> Sebastian
> 
> [*] One approach might be to keep a look-up table in the daemon, storing
>     (plugin name, interval) pairs. When a plugin registers a read
>     callback without specifying an interval, the daemon would try to
>     look up the interval in that table and fall back to the global
>     interval. This would require all plugins to strictly follow a naming
>     convention when registering read callbacks, though (e.g.
>     "<plugin_name>-<instance>").

Following name convention is good thing anyway, idea looks good and it
would have nice "backward compatibilty" so no need to rewrite all
plugins

Regards
-- 
Mariusz Gronczewski (XANi) <xani666 at gmail.com>
GnuPG: 0xEA8ACE64
http://devrandom.pl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.verplant.org/pipermail/collectd/attachments/20100223/9b8b050a/attachment.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: To jest =?UTF-8?Q?cz=C4=99=C5=9B=C4=87?=
 =?UTF-8?Q?_wiadomo=C5=9Bci?= podpisana cyfrowo
Url : http://mailman.verplant.org/pipermail/collectd/attachments/20100223/9b8b050a/attachment.pgp