[collectd] Thought about exec and types.db

[Florian Forster]

Good morning :)

Sorry for the late reply, I was ``disconnected'' for a couple of days.

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

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

Thanks for the patch Sebastian, I'll apply it asap.

Regards,
-octo
-- 
Florian octo Forster
Hacker in training
GnuPG: 0x91523C3D
http://verplant.org/
-------------- 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/53d1327f/attachment.pgp