Determining the success or failure of external commands

Scott Sanders lists at jssjr.com
Wed Jan 23 16:29:15 CET 2008


Kyle,

Yes, I have been following the thread you linked and saw some of the
suggestions made. However, all of them seem "hackish" to me. Using NFS is
not a good solution for me, because it reduces the portability of my
scripts. For example, if a server that runs processes which disrupt
monitored services cannot use NFS, I am out of luck. Also, simply exporting
the nagios.cmd file over NFS requires me to use NFS to secure things instead
of using the same authentication system nagios uses. I already have my API
working, and am able to submit commands to nagios in a safe manner, but I
cannot verify that those command were processed or what the result is.
Consider the following block of code:

$nag = new Nagios('username', 'password', 'nagios.domain.com');
$host = $nag->findHostByIP('192.168.1.1');
$result = $nag->scheduleHostDowntime($host->name, date(U), date(U)+3600,
true, 0, 3600, $nag->getUsername(), 'Auto-scheduled downtime for X');
if($result->code == 0) {
  do_task_that_causes_downtime();
} else {
  log_errors($result->message);
}

This is what I envision being able to do. One of the main problems is that
nagios may take a while to process the command, so if the command is sent
and recieved by nagios, but hasn't yet been processed when the disruptive
task begins, alerts will be still be generated.

While typing this I received Marc's reply and it seems I will need to modify
commands.c to log when a command was processed then add a facility in my
client interface to poll nagios about the status of a command in the pipe.
This way my client can sit and wait until the command is processed before
beginning the disruptive task.

I believe I have a better understanding of what I need to do now. Thanks for
all the advice and I look forward to any additional feedback.

-Scott

SCHEDULE_HOST_DOWNTIME;<host_name>;<start_time>;<end_time>;<fixed>;<trigger_id>;<duration>;<author>;<comment>
On 1/23/08, kyle.odonnell at gmail.com <kyle.odonnell at gmail.com> wrote:
>
> Hi Scott,
>
> I'm in the process of doing something similar.  I've come up with
> something that may help you.
>
> Read my thread entitle "nagios.cmd over nfs"
>
>
> http://www.nagiosexchange.org/nagios-users.34.0.html?&tx_maillisttofaq_pi1[mode]=1&tx_maillisttofaq_pi1[showUid]=8571
>
>
> If nfs isn't an option, Thomas mentioned the use of netcat and or a
> Perl daemon which would offer more control.
>
> Good luck!
> On 1/23/08, Scott Sanders <lists at jssjr.com> wrote:
> > In my case, a backup job might take down a MySQL database for anywhere
> from
> > 1 minute to 1 hour, depending on the size of the database. Because the
> time
> > needed to perform the backup is flexible and the time when the backup
> might
> > occur is not always known, I cannot simply set the affected services to
> only
> > notify in a timeperiod that excludes certain hours of the days. This is
> just
> > an example of why I need to allow scripts and applications not on the
> nagios
> > host(s) to be able to use the external command pipe.
> >
> > Currently I have a very simple API over https that uses the same auth
> > mechanism as the Nagios frontend, and PHP classes that I can use in my
> > client side scripts to manipulate this API. I am able to query Nagios
> about
> > object data and status data, as well as submit commands to the
> > nagios.cmdpipe. In order for the external command functionality to
> > work the way I
> > intend, I need to obtain a response from nagios so my server can respond
> > back to the client with the results of processing the external command.
> I am
> > really hoping there is an easy way to do this, as replacing the
> > nagios.cmdfile with something besides a FIFO pipe requires
> > modification to the nagios
> > source and is something I was trying to avoid.
> >
> > Thanks for the response. I hope this makes sense.
> >
> > -Scott
> >
> > On 1/23/08, Andreas Ericsson <ae at op5.se> wrote:
> > >
> > > Scott Sanders wrote:
> > > > Hi,
> > > >
> > > > I am working on implementing some functionality that will allow me
> to
> > > safely
> > > > expose nagios.cmd to external hosts. In my environment there are
> > > maintenance
> > > > tasks that run periodically which disrupt certain services, causing
> > > nagios
> > > > to start generating alerts. Needless to say, I am tired of having my
> > > cell
> > > > phone go crazy when this happens.
> > >
> > > In that case, why not ask "How do I keep my cellphone from waking me
> up?"?
> > > Instead, you've thought up a solution to your problem, which generates
> > > other problems, and now you want help solving those other problems.
> > >
> > > Assuming you know when these disruptive tasks are run, you should
> simply
> > > create a notification_period that doesn't include the sensitive hours
> > > and use that notification_period for the services being disrupted.
> > >
> > > There are other solutions too, but this one is normally the
> recommended,
> > > so I suggest you try that out first.
> > >
> > > --
> > > Andreas Ericsson                   andreas.ericsson at op5.se
> > > OP5 AB                             www.op5.se
> > > Tel: +46 8-230225                  Fax: +46 8-230231
> > >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.monitoring-lists.org/archive/users/attachments/20080123/a4ad8b12/attachment.html>
-------------- next part --------------
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
-------------- next part --------------
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. 
::: Messages without supporting info will risk being sent to /dev/null


More information about the Users mailing list