plugin for collectd-generated metrics in graphite

[teftin]

It contains (still incomplete) list of various types of metrics provided by collectd. Includes a fix allowing plugin tag to be overridden by regex matcher.

[Dieterbe]

Includes a fix allowing plugin tag to be overridden by regex matcher.

what's the purpose of that? i actually like that a plugin can't do this, i believe plugin should be consistently derived from the plugin file/class name.

if i understand correctly, this one plugin is basically memory, disk, network, ... metrics all in one? but it's ok for all those metrics to just have 'plugin=collectd' or something, it's up to the other tags to distinguish/clarify what the metric represents.

[teftin]

• overriding plugin name is still possible without this 'fix', it can be done on sanitisation step, and I wanted to skip this step.
• collectd is slightly more than simple collector. it has it's own plugin system (actually, everything is plugin), so in this case it's both source and transport of the data. I actually set 'source' to indicate where the data come in. (i'm currently using collectd for over 90% of metrics, with all system and some of the app level metrics)
• 'plugin' has it's own meaning in collectd world and i tried to get graph-explorer matching it (to have more obvious search terms)
• example preferences.py already uses 'plugin' for distinguishing what metrics represents, and it looks consistent with collectd.

if you want 'plugin' to be reserved only for information which matcher matched the metric name, I can change the code and start using different name (but then, probably plugin should not be used anywhere outside structured metrics/).

[Dieterbe]

if you want 'plugin' to be reserved only for information which matcher matched the metric name, I can change the code and start using different name

maybe you should set a 'collectd_plugin' tag, this way 'plugin' (as used in structured_metrics) can keep it's meaning of "structured_metrics plugin"

but then, probably plugin should not be used anywhere outside structured metrics/

this seems ok, it's a plugin written for structured_metrics after all

example preferences.py already uses 'plugin' for distinguishing what metrics represents, and it looks consistent with collectd.

that's actually not clean, and i'm in the process of fixing it. i still have to think a bit more about it (the problem is those rules should only look at the "intrinsic properties" of the metric, but currently we're adding tags to metrics that aren't really intrinsic to them, i.e. the name of the plugin is irrelevant). i think we can for now just extend preferences.py to also consider the collectd plugin specifically

[Dieterbe]

thanks! if you have more questions on how to make it better, feel free.