This will add support for multiple metric output formats within the same class.
Description
This changes moves the different output formats into a base metrics cli class and let implementers to choose the output format on runtime.
Motivation and Context
We have been struggling to use various sensu metrics plugin scripts since most of the existing plugins are generating metrics in graphite format and this format is not easy to map to other metric storage architectures with tags that can't be known ahead of time. So we've been either forced to (re)implement copies of the graphite metrics collector scripts in our choice of metrics storage or maintain mappings for grafana metric path to other metrics storage option. E.g. We've been using influxdb templates to map grafana metric path to influxdb measurement, tags, fields and trying to maintain the mapping templates is not optimal for long term operational goals.
Expectation is to let the graphite specific plugins to start using the generic metrics class and start supporting other metric formats without having to copy the metric collection logic. The output function calls in metric collection scripts needs to decorated with a better metadata for this change.
This issue has been previously discussed in #37, and this is just an initial implementation for the idea there. And one of the main blocking issues (chef/mixlib-cli#13) seems to be solved after that ticket is open.
How Has This Been Tested?
Here are the test results, I also added some tests to cpover the new feature:
This will add support for multiple metric output formats within the same class.
Description
This changes moves the different output formats into a base metrics cli class and let implementers to choose the output format on runtime.
Motivation and Context
We have been struggling to use various sensu metrics plugin scripts since most of the existing plugins are generating metrics in graphite format and this format is not easy to map to other metric storage architectures with tags that can't be known ahead of time. So we've been either forced to (re)implement copies of the graphite metrics collector scripts in our choice of metrics storage or maintain mappings for grafana metric path to other metrics storage option. E.g. We've been using influxdb templates to map grafana metric path to influxdb measurement, tags, fields and trying to maintain the mapping templates is not optimal for long term operational goals.
Expectation is to let the graphite specific plugins to start using the generic metrics class and start supporting other metric formats without having to copy the metric collection logic. The
output
function calls in metric collection scripts needs to decorated with a better metadata for this change.This issue has been previously discussed in #37, and this is just an initial implementation for the idea there. And one of the main blocking issues (chef/mixlib-cli#13) seems to be solved after that ticket is open.
How Has This Been Tested?
Here are the test results, I also added some tests to cpover the new feature:
Types of changes
Checklist:
Known Caveats