Scripted downtime question

[Hari Sekhon]

Ian Collier wrote:
> Hi,
>
> We've been happily using nagios for a year and a half or so to monitor 
> a number of high performance linux clusters (total 200 nodes or so), 
> plus infrastructure hosts. All works nicely and it is highlighting 
> issues well before they become critical.
>
> One thing I have not found good solutions for is down time for cluster 
> nodes.
>
> Sometimes they are down briefly for maintenance, os reinstalls etc, 
> and turning off checks in the GUI sort of works, most of the time. But 
> we also turn machines off automatically, from other management 
> software when they are not needed for a while.
>
> Does anyone have a way to script turning off checks and notifications 
> for individual hosts or hostgroups? The only way I have identified is 
> the GUI. If it is there built in I have failed to identify it in the 
> docs.
This comes up quite a lot on this mailing list. I think so far the best 
solutions are:

1.use timeperiods to repeatedly exclude the maintenance window on those 
service or host checks

or

2. send a passive external command to the command pipe of nagios (the 
thing NSCA and the gui use to send those instructions to Nagios - see 
External Commands in the nagios docs and you will need 
check_external_commands=1 in your nagios.cfg). This option gives more 
flexibility in fact that the timeperiods can even allow for if your 
scheduling is more irregular and not for example the same time every day 
or every week.

If you search the mailing lists you should find whole discussions on 
this too.

-h

-- 
Hari Sekhon


-------------------------------------------------------------------------
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/
_______________________________________________
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