[collectd] New aggregator plugin "basic_aggregator" (#136)
Sebastian Harl
sh at tokkee.org
Thu Oct 11 09:11:24 CEST 2012
Hi,
On Wed, Oct 10, 2012 at 11:28:05PM -0700, ymettier wrote:
> After some use of the aggregator, I noticed that when you change
> something in the configuration of the aggregator (add,remove a
> hostname, type...), you have to restart all collectd to take the
> change into account.
>
> This new commit introduce a new feature : there is a distinct
> configuration file for the aggregator and when it changes, the
> aggregator notices it and updates its configuration. No more need to
> restart anything.
Hrm, from a first glance, I don't really like this idea. The following
are a couple of random ideas / notes; maybe we can get to a "better"
(more generic) solution from there. Also, I've Cc'ed the mailing list.
Imho, the discussion should happen there.
Background: currently, collectd does not support reloading any
configuration at run-time. This is due mostly to the rather generic
configuration approach. Support for config reloading would probably
require modifying each single plugin.
Now, my idea is to introduce a "reconfigure" callback that allows to
reconfigure a single plugin. This could then be exposed, for example,
through the 'unixsock' plugin.
Example:
/* plugin.h */
int plugin_register_reconfig (const char *name,
int (*callback) (oconfig_item_t *));
/* UNIXSOCK */
RECONFIGURE <PluginName>
Obviously, "reconfigure" will fail if the specified plugin did not
register a "reconfig" callback. In case, the plugin did not specify a
"config" callback either, "reconfigure" could be a no-op (no error).
Internally, the callback would trigger re-parsing the whole
collectd.conf file. Then, the appropriate config-block would be
dispatched to the registered "reconfig" callback just in the same way
that the original configuration was dispatched to the "config" callback.
As a second step we could then think about also implementing a "reload"
action. This would mean unloading and reloading the shared object of a
plugin and then doing a "reconfigure".
This approach will allow us to introduce a global "reload" operation
step by step. Also, if we decide never to implement a global operation,
some plugins (like the aggregator) will still be able to benefit from
the infrastructure.
What do others think?
Cheers,
Sebastian
--
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/
Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin
More information about the collectd
mailing list