[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