[collectd] ip6tables and uptime plugin

Marco Chiappero marco at absence.it
Tue Mar 10 17:07:22 CET 2009


Hi everybody,
I forked the iptables plugin and created the ip6table one. It's
basically a 5 minute hack since IPv6 libiptc interface is consistent
with the one dealing with IPv4, so it's just a mere renaming task.
Although we already talked about this, after having a look at the code,
let me agree with the fact that separated plugins is the best way imho:
a single dual stack plugin means lots of if/else every time we need to
choose the right function (using a protocol value in the ip_chain_t
struct) or even different chains lists / submit_match functions. I can't
see any advantage in one more complex or code redundant plugin, two
different plugins are indeed redundant (although many people will run
just one of the two) but seems to me a cleaner and effective choice. Let
me know what do you think about.
A note: I didn't change the "ipt_packets" & "ipt_bytes" data types
because I can't see a reason for having two different types, in
types.db, doing the same thing, but this obviously affect the rrds name
schema. So, please change it if you think it's a wrong idea.

About the uptime plugin...
First of all I have to say that using own plugins it's a pain because
you need to recompile every time a newer collectd version is out or you
want to upgrade. Thus the question is: if I write an uptime plugin, are
you going to include it in the upstream tree? Otherwise I'm going to use
the exec plugin for collecting uptime stats. Which is fine. But I
wouldn't dislike an uptime plugin, as already said I can be useful,
sometimes.
Here an example found on internet:
http://haroon.sis.utoronto.ca/perl/rrd.cgi/localhost_stats/uptime.html
This is a stub from mine:
http://i41.tinypic.com/zuf62v.png
Still a little bit interesting, isn't it? ;-)

Regards,
Marco

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ip6tables.c
Type: text/x-csrc
Size: 7944 bytes
Desc: not available
Url : http://mailman.verplant.org/pipermail/collectd/attachments/20090310/fd1ab3b2/attachment.c 


More information about the collectd mailing list