[collectd] Plans for collectd 4 [discussion]

[Florian Forster]

Hello all,

the current design of collectd is very inflexible, I'm afraid. Thus,
such logical things as a Local-Server-hybrid-mode (collect data locally
_and_ accept network traffic) or an SNMP plugin don't exist. I've though
about an alternative design for a while and want to share my ideas with
you for some discussion. I haven't started coding one line of it, so
this is all far far away.

First, I want to make the plugin-structure more abstract:
- Data is read by `input plugins' such as `system' (basically what we
  have now: Use some system-dependend code to actually collect the
  values from somewhere), `network' (basically what the `server mode'
  does now) and `snmp' (read values from SNMP enabled devices).
    Input plugins should be worked and have their own event loop. This
  will make passive monitoring (e.g. snmp-traps or similar) possible.
- Data is written by `output plugins', such as `rrd' (write to RRD
  file(s)), `network' (basically the `client mode'), `logfile',
  `nagios', you name it.
- Between the `input' and `output' side some logic decides which data is
  sent where, with the option to send it to multiple output plugins.
- Right after the `input' interface and right before the `output'
  interface should be `mangle' hooks to manipulate the data. I don't
  know what to use that for yet, but people will come up with a use, I'm
  confident.

I want to implement another network-protocol. The minimal features I
want to have is:
- The protocol should carry the `host'. Right now it's assumed that the
  data originates from the sending host. This will no longer hold true:
  The `snmp input plugin' will next to never query `localhost' and you
  can use collectd in `proxy mode' by using `network' as input and
  output plugin.
- It should be extendable. Therefore, the protocol itself should be as
  small as anyhow possible with all functionality in `options'. Adding a
  new feature to the protocol should work by defining a new option.
- It should be possible to sign/verify the data.
Optional feature:
- Possibility to encrypt/decrypt the data.
- It might be neccessary to include the `step' in the network packets so
  receiving instances `know' how often to expect data readings.

It should be possible to base the `routing decision' upon:
- The host the data originates from,
- the `type' of the data, and
- the values being sent (i.e. the `DS' (data source) and the value,
  possible with some threshold).

Any thoughts? Ideas? Wishes?
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/20060411/cec49c4f/attachment-0001.pgp