Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
[dev.icinga.com #12256] Add check command definition for check_graphite #4416
This issue has been migrated from Redmine: https://dev.icinga.com/issues/12256
Created by mwaldmueller on 2016-07-29 09:31:58 +00:00
Add Plugin Check Command for check_graphite
2016-07-29 09:38:57 +00:00 by mwaldmueller 6d082e6
Updated by cmh on 2016-08-26 12:09:46 +00:00
Saw this showed up in latest update of Icinga2 and it uses the obfuscurity check_graphite script. That script hasn't been updated in over a year and depends on Ruby which leads to all types of dependency hell in CentOS 6 due to the ancient version of Ruby available from the default repos. I didn't feel like installing a newer version of Ruby just so I could run one plugin command.
Because of that, I had defined the "graphite" checkcommand to use Etsy's version, (https://github.com/etsy/nagios\_tools) which is far more neglected (last updated 2 years ago) and not perfect (https://github.com/etsy/nagios\_tools/pull/10) but it runs fine with the python that ships with CentOS 6.
I've evaluated about 8 different check_graphite scripts from github, and none are perfect, but several offer features which might make them a better choice over the obfuscurity plugin, depending on the user's needs.
With this in the latest update, my icinga setup broke because of the conflict between my "graphite" CheckCommand and this one. While I can rename mine to avoid the conflict, making the decision that everyone would want to use the obfuscurity plugin might not be the best course of action.
Updated by mfriedrich on 2016-08-29 13:26:19 +00:00
It has been sitting in "plugins-contrib" for a while now - similar to "mem" which might break existing installations too. The only notable change (which is emphasised on in the Changelog file as well as the release blog post notes) is the inclusion of that part of the template library for new installations by default. If you decide that you don't want to use the contributed plugin check command definitions, disable the default inclusion.
In either way, you have to make a decision which plugin is the default for a CheckCommand definition. One will hate you for that, one will love your for that. I trust the expertise of Markus choosing the right one. If you've got a better idea about CheckCommand object naming / versioning for specific plugins with the same name, please let us know (best by opening a new issue for future discussion).