[collectd] Question about remote plugins

[Florian Forster]

Hi Niraj,

On Fri, Oct 10, 2008 at 06:45:13PM -0700, Niraj Tolia wrote:
> Supposed I have a plugin on machine A that uses
> plugin_register_data_set() and also uses the network plugin to
> dispatch values to server B. Would I be correct in understanding that
> server B won't know how to interpret the data as the data source types
> don't exist in types.db? Is there any way to work around that?

that's right, the receiving instance will not know how to handle the
value(s), because that data set definition never reached it.

Currently the preferred method is to put all your custom data set
definitions in an own `types.db'. You distribute that file to all hosts
running collectd and add a second `TypesDB' statement to collectd's
config. This way you don't have to change the file distributed with a
binary package which makes upgrading simple.

While the above method works, I can see that having it ``just work''
would be nice to have. This is not trivial, though because there is no
way for the `client' to know which types the server knows and which it
should transmit. I see two possible solutions for this:

 * The server could contact the client. Thus, we would have to give up
   the unidirectional communication schema. You will get into trouble
   with this method, if a type of the same name is already defined on
   the server, because there is no automated way to tell if both parties
   talk about the same definition.
 
 * The client ``occasionally'' sends the definition along. For example
   every `n' values, once per hour, with a 1% chance, every time, ...
   Now you have the problem what to do when the just received definition
   conflicts with the existing definition. You could, of course, build a
   per-host list, but since UDP is connectionless you would have to
   occasionally check if the host is still alive and possibly remove
   that information..

If you have any other ideas, please let me know. I'm not a huge fan of
the existing solution, but so far I couldn't come up with a better
solution..

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/20081011/312e4c51/attachment.pgp