Page 2 of 2

Re: Passing Failed Service Name To Event Handler

Posted: Thu Mar 11, 2021 10:41 am
by benjaminsmith
Hi @jimmlegs,

Yes, you can pass any of the standard Macros available in Nagios Core to your event handler. Those are listed on the following page with descriptions.

Standard Macros in Nagios

Take a look at $SERVICEOUTPUT$ and $LONGSERVICEOUTPUT$ on the page. That should contain the stopped service data.

--Benjamin

Re: Passing Failed Service Name To Event Handler

Posted: Thu Mar 11, 2021 5:00 pm
by jimmlegs
I've got the MACROS in the event handler but do not know how to pass the failed service name dynamically to the remote host. So if I am monitoring 80 services in one check I would like the event handler to attempt to restart any one of them that crashes. The free variables do not appear to parse MACRO data or I cannot find the information on how this is achieved. Even providing a static list somehow could potentially do the trick.
Perhaps XI this is the wrong solution for this.

Re: Passing Failed Service Name To Event Handler

Posted: Fri Mar 12, 2021 3:06 pm
by benjaminsmith
Hi @jimmlegs,

The example in the guide is very simple with just one service to re-start, it may be easier to break this up into single checks for simplicity. The other approach I can think of would be to write a wrapper script for the service check that does the heavy lifting, parsing the output from the plugin, and returning the proper exit code. However, this is getting into more complex custom programming which is outside the scope of technical support.

Here are the guidelines for plugin development.
Nagios Plugins Development Guidelines

--Benjamin

Re: Passing Failed Service Name To Event Handler

Posted: Fri Mar 19, 2021 1:50 pm
by jimmlegs
Thanks. You can close, I will consider alternative solutions for this issue and will keep future handlers simple.

Re: Passing Failed Service Name To Event Handler

Posted: Mon Mar 22, 2021 7:26 am
by scottwilkerson
jimmlegs wrote:Thanks. You can close, I will consider alternative solutions for this issue and will keep future handlers simple.
Locking thread