Closed teftin closed 11 years ago
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.
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/).
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
thanks! if you have more questions on how to make it better, feel free.
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.