[collectd] Collectd plugin for Madwifi and some questions
Florian Forster
octo at verplant.org
Thu Jul 16 07:47:23 CEST 2009
Hi Ondrej,
On Thu, Jul 16, 2009 at 01:29:34AM +0200, Ondrej Zajicek wrote:
> I am developing a Collectd plugin for Madwifi (a driver for Atheros
> wifi cards).
sounds very interesting :) Is this related in any way to `wprobe' [0]?
As far as I know it's an interface to wireless cards. Some OpenWrt guys
pointed me to it recently.
If you have a Git repository somewhere, let me know :)
> 1) Are there any guidelines for using plugin_instance and
> type_instance?
Yes there are, see [1].
> For example CPU plugin uses plugin_instance to specify CPU, but
> Interface plugin uses type_instance to specify interface. That seems
> to be inconsistent (from my point of view).
That's basically a known bug but can't easily be changed because it's a
backwards incompatible change. We plan to fix this as soon as we're
working on a new major version, see [2].
> In the madwifi plugin, there are two levels of a hierarchy - first,
> several network interfaces, second, several stations connected to that
> interface. And for each station we have several statistics (RX, TX,
> RSSI, ...). So a natural idea is to specify an interface name in
> plugin_instance and station MAC address in type_instance. Is that a
> good idea?
That's sounds good to me.
> 2) There are many different types of rx/tx errors exported as separate
> counters from Madwifi. The plugin collects them separately. That would
> lead to many data streams (~ 200 per interface), most of them full of
> zeroes. Therefore i submit these counters only if they are non-zero.
> Is that a good idea?
That's what we do in the MySQL plugin, but I have to admit I'm not a big
fan anymore. If you restart the system (/the database), a rare error (or
statement in case of MySQL) is reset to zero. collectd will then ignore
that value, which leads to ``zombie graphs''. I've been asked several
times by people why `MySQL support is broken', so obviously this concept
is confusing for users.
I think there are two better possibilities:
1) Let the user specify which errors to connect. For example:
RXError "crc"
RXError "length"
TXError "something"
...
IgnoreSelected false
This will ``select'' some specific errors and collect only those. If
`IgnoreSelected' is set to `true', the effect is inversed, so that
all specified values are ignored.
This behavior is found in many plugins, for example the `interface'
plugin. You can use the functions from "src/utils_ignorelist.h" to
implement it.
2) Implement some `level of detail'. Something like:
RXErrors "ignore"|"basic"|"verbose"
TXErrors "ignore"|"basic"|"verbose"
If set to `basic', only some common errors are collected. If set to
`verbose', all errors will be available. Users can then use the
filter infrastructure to ignore unwanted values, see [3], [4].
> 3) Besides of these counters, there are RSSI (received signal strength
> indicator) for each station, but this value is updated only when a
> packet is received from that station. I think that RSSI value should
> not be submitted if there is no received packed from last RSSI
> submission. It is correct to do such irregular data submission?
Yes, that'd be okay by me, but it may cause problems with RRDtool's
consolidation. The default RRD files created by the rrdtool and
rrdcached plugins will set the `x files factor' (XFF) to 0.1,
i. e. 90 % of all values need to be present in each consolidation
interval for the value to be defined (non-NaN).
I'd say, give it a try. If the values make sense for you and the above
problem doesn't really occur or is okay to occur, fine. If we find out
later that there is some horrible problem with this approach, it's
backwards compatible to change it.
> 4) A general question, not specific to Madwifi - if i have a slowly
> changing counter and i submit its value during each iteration, is it
> sent each time to the network, even if the value is the same, or is it
> optimized? If it is sent each time, is it a good idea to submit a
> value of the counter (in a plugin) only if there is a change?
The value is sent each time, because otherwise you can't tell if a
counter didn't change or the machine went down. Also it's much easier to
implement this way ;) Counters, even if they didn't change, should be
submitted every `interval' seconds, where `interval' is a number in the
`value_list_t' data structure.
Best regards,
-octo
[0] <http://collectd.org/wiki/index.php/Roadmap#Query_wprobe>
[1] <http://collectd.org/wiki/index.php/Naming_schema>
[2] <http://collectd.org/wiki/index.php/Plans_for_5.0#Interface_plugin>
[3] <http://collectd.org/wiki/index.php/Chains>
[4] <http://collectd.org/wiki/index.php/Match:RegEx>
--
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/20090716/e60a28b3/attachment.pgp
More information about the collectd
mailing list