[collectd] Thought about exec and types.db

[Sebastian Harl]

Hi,

On Sun, Jan 20, 2008 at 01:19:44PM +0100, Florian Forster wrote:
> On Fri, Jan 18, 2008 at 12:25:26PM +0100, Sebastian Harl wrote:
> >  i) Provide some kind of interface to plugin_register_data_set() from all
> >     plugins that may dispatch values to collectd (i.e. network, snmp, exec and
> >     unixsock).
> 
> I don't think this would be a good thing to do: While on a first glance
> it would be nice if the custom-made script could prefix its values with
> the appropriate type specification, this creates a whole bunch of new,
> interesting problems:

Yes, I was thinking about those as well (and, unfortunately, didn't come up
with any good solutions so far - but see below for some quick ideas). However,
we've got the exact same problem if some plugin (C or Perl) uses
plugin_register_data_set(). So, we should either declare this function to be
"private" (i.e. it should not be used from inside any plugin) or come up with
some solution to handle this situation. Personally, I'd prefer the latter if
it's doable in a reasonable way.

> - A script registers a new type. If the values are sent via the network
>   plugin it must include this new specification. I. e. there needs to be
>   a new kind of callback so that plugins get notified when a type is
>   added.
> - If a server ``tunes in'' after the specification has been sent it
>   doesn't know how to handle the data. I. e. the type specification
>   would need to be sent at least once in a while.

Well, the networking protocol could be expanded to let the "server" request
unknown data-set definitions from the client sending them. This would require
some sort of bidirectional communication, so will probably not be trivial to
implement. In the long run, this should be a fairly nice solution though.

I don't think there's a need for a new callback - this is an issue solely
related to the network plugin. As soon as the network plugin registered the
new definition, all other plugins will automatically be aware of it, if they
use plugin_get_ds().

> - What if a server receives two different specifications? If either one
>   has a preference you can always construct use cases where this is
>   annoying. So the ``right thing'' to do would be to have one types-list
>   per host, which is a lot of work for a small gain.

I'd blame the user in this case. Simply printing out a big fat warning (we
might even want to dispatch a notification) and using the definition received
first should be fine. Imho it's the admin's task to choose a fairly reasonable
setup, so I don't think collectd has to be more fool-save than that.

> >  ii) Update the "TypesDB" configuration option to accept multiple files which
> >     are then parsed in the specified order. You could then use something like
> >     "TypesDB /usr/lib/collectd/types.db /etc/collectd/types.db" and define
> >     custom data-sets in "/etc/collectd/types.db" (as you suggested in your
> >     e-mail).
> 
> I think the best way to handle this is to copy the file to
> /opt/collectd/var or /var/lib/collectd and change the config file to
> point to this file. I see however that this is not an appropriate
> solution if the file is included in a package and may change in the next
> version.

Right, the file would have to be marked as a configuration file which means
that (in case of custom changes) the user would have to manually merge it on
every upgrade.

> Changing the config parsing to allow multiple `TypesDB' statements
> should be relatively easy and would allow to make additions to the
> shipped file using a second file somewhere else. So I'd strongly prefer
> this solution. I'll put this on my todo-list.

If I find some time, I might provide a patch later.

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

-------------- 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/20080120/d5367482/attachment.pgp