Nagios::Plugin::OverHTTP Planned Additions

I usually get e-mails about my Nagios::Plugin::OverHTTP asking about little things being added here and there. The last e-mail I got was from Peter van Eijk asking for support for performance data. I looked over the code and realized that it really needs some refactoring before I can easily add support for performance data, and so I am currently hung up on that before the feature will get added.

My current thoughts on support for getting performance data from the remote page would be to just scrape it from the standard plugin output, which is supported as the body:

PLUGIN OK - Good to go! | time=0.012s;1;10;10;0

I was also thinking about how to add support for receiving as headers, since the other supported aspects of the plugin may be transmitted as headers. My current thoughts are for a header named X-Nagios-Performance which would hold the name=value pair, separated by spaces like the normal plugin and would also allow more than one header with the data to be present:

X-Nagios-Performance: time=0.012s;1;10;10;0
X-Nagios-Performance: count=2;;;50;0 other=4;;;4;0

For Nagios::Plugin::OverHTTP itself, since the remote plugin can provide critical and warning thresholds, I was thinking of allowing for actually changing the status based on that to be made optional by default (because if the remote plugin said the status was OK but yet a performance metric it sent said that it should really be in a WARNING state, by default Nagios would have kept that as OK so I believe that my plugin should honor that as well by default). New options for the plugin would be:

--warning name=threshold
--critical name=threshold

The last option --override-transmitted-thresholds would cause the performance data written as the plugin’s output to be changed to match the thresholds given as the plugin’s options. This means a plugin with the given options --override-transmitted-thresholds --critical time=4 would cause the performance data to say time=0.012s;1;4;10;0 instead of time=0.012s;1;10;10;0 (note that this setting does not affect the decision of the final status code).

Leave a Reply