I'm lazy: How about an event handler trigger selection?

[eloyd]

I'm well-versed in writing event handlers. They fire at SOFT result or state change. I'm good with that. But sometimes, I just want to fire an event handler through NRPE that is nothing more than "check_nrpe -H HOSTANME -c command_name" and be done with it.

Consider this a feature request for XI (and by proxy, Core):

I'd like a set of selection criteria (two, most likely) that state when to fire an event handler in the service config screen. Right now, it's "choose event handler" pull-down and then on/off/skip/null (which, frankly, I don't get). I'd like to see this changed to the pull-down plus on/of (because I don't understand skip and null) and then also ok/warning/critical radio boxes and a entry for every time or just on the Xth occurrence (typically, first, second, or third).

This gives me the ability to use existing commands (such as the aforementioned check_nrpe) to throw a "service donut_maker restart" command into the remote host nrpe.cfg file and then just fire it off on the second CRITICAL state without having to code a piece of shell that gets fired every time and has to check itself to see if it's time to restart the donuts.

Does that make sense? I think it would greatly simplify what 80% of people use event handlers for 80% of the time. Obviously, the corresponding Core config directives would have to be created first....

[tmcdonald]

[...] and then on/off/skip/null (which, frankly, I don't get)

Just to get this one out of the way: http://www.nagiosql.org/forum/general-q ... .html#1154

This would definitely be possible, however it would require a pretty hefty patch to Core. Couldn't as easily be done in XI since we would essentially need to disable event handlers in Core and then handle them in XI before passing them to Core for execution. In regards to:

[...] and then also ok/warning/critical radio boxes and a entry for every time or just on the Xth occurrence (typically, first, second, or third).

I'd make them checkboxes instead of radio, since you might want to do it for WARN/CRIT but not OK/UNKNOWN. And as for every Xth time, inevitably someone will say "I want this event handler only to fire every X time where X = fn(2Y*4 - Q)" but simply allowing for similar logic to how notification counts are done wouldn't be terribly hard.

As a pro, we would now have a few lines of C determining when an event handler gets run instead of spawning a shell and interpreting bash just to see if that bash shell needed to be spawned in the first place. As a con, this wouldn't be a simple 10-line patch to Core. We would need to consider many factors such as rewriting the structs to now keep track of how many times the event handler was run, writing this into objects.cache and status.dat, probably putting it into ndo (which means a DB schema change), adding fields to the CCM in XI, updating the web interface... It would be a bit of work :)

All that doom and gloom aside, GitHub it. I do agree that this sounds like a nice improvement in the spirit of reducing work in writing scripts. I could see some arguments made that "this can already be done by using a library for your scripts" but if the request never gets filed, it will never be considered.

[eloyd]

Eep! I did mean checkbox, not radio box. I'll go edit my original.

Thanks for skip/null. I think these represent a very outlier use scenario compared to "on/off" and how most people use templates in XI (meaning, they don't, that's more of a Core consideration).

I think a simple first, second, third, fourth, fifth...tenth pull down for which iteration to execute on would satisfy 80% of the use scenarios. Which is what I'm going for, here - 80% of the time, 80% of people do 80% of the same thing that the rest of the 80% do, which is fire an event handler on the first, second, or third HARD/SOFT WARNING/CRITICAL to restart something before it gets worse and starts notifying.

And I am oh so well aware of how hard it would be to integrate it. Which is why I haven't picked up my int main() just quite yet. I especially like not forking copies of processes to run shell scripts to see if said script should be run in the first place. That logic really should be moved up a layer.

I got stuff to do but will submit it later today.

[tmcdonald]

Please do so on the GitHub page: https://github.com/NagiosEnterprises/nagioscore

And link back to this topic if you will. Helps with coordination.



As an aside, Mantis has been closed for our open-source products in favor of GitHub. We still use it for XI and friends, however.