Ok I understand now. I'm looking at this in the wrong place. I'm thinking I need to modify the actual services, (which I will have to to some extent) though the solution is in the contacts and timeperiods cfg. I just stumbled across p.234 of the manual on adding the host/service notification_period. It makes sense now.
-----Original Message----- From: Wojciech Kocjan [mailto:[EMAIL PROTECTED] Sent: Thursday, April 03, 2008 3:24 PM To: Seth Simmons; nagios-users@lists.sourceforge.net Subject: Re: [Nagios-users] Monitoring in different time periods On Thu, 03 Apr 2008 21:12:21 +0200, Seth Simmons <[EMAIL PROTECTED]> wrote: > I understand the first part about adding all to the same contact groups. > The second part I can't see how they would have their own hours, > unless I have a separate service defined? For example if I have this > (below) what line(s) would I need to add/modify? I'm thinking I would > have to have a different service defined for each check/notification period? No, I assume what you actually want is to: 1/ Monitor the service 24x7 2/ For India working hours, notify India 3/ For remaining hours, notify someone else So, define single service, two contact groups and for India group members configure them for Indiaworkinghours time period and for "someone else" configure them for a timeperiod defining remaining hours. Then if a problem comes in during Indiaworkinghours, India staff will get the message. On remaining hours "someone else" will get the message. -- Wojciech Kocjan ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ Nagios-users mailing list Nagios-users@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
