New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[dev.icinga.com #12256] Add check command definition for check_graphite #4416
Comments
Updated by gbeutner on 2016-07-29 09:34:46 +00:00
ITL commands in the plugins-contrib.d directory should use the PluginContribDir variable. :) |
Updated by mwaldmueller on 2016-07-29 09:40:45 +00:00
Thanks for your hint ;-) |
Updated by mwaldmueller on 2016-07-29 09:42:14 +00:00
Applied in changeset 6d082e6. |
Updated by mwaldmueller on 2016-07-29 10:12:44 +00:00
Sorry, once again... |
Updated by gbeutner on 2016-08-22 11:58:02 +00:00
|
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). Kind regards, |
Updated by cmh on 2016-08-29 16:05:12 +00:00 Yep, I renamed mine to avoid the conflict. |
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
Assignee: mwaldmueller
Status: Resolved (closed on 2016-07-29 09:42:14 +00:00)
Target Version: 2.5.0
Last Update: 2016-08-29 16:05:12 +00:00 (in Redmine)
Add Plugin Check Command for check_graphite
Attachments
Changesets
2016-07-29 09:38:57 +00:00 by mwaldmueller 6d082e6
The text was updated successfully, but these errors were encountered: