Time based WARN/CRIT values

[Furnish, Trever G]

> -----Original Message-----
> From: Subhendu Ghosh [mailto:sghosh at sghosh.org]
> Sent: Thursday, September 05, 2002 10:19 PM
> To: nagios-users at lists.sourceforge.net
> Subject: Re: [Nagios-users] Time based WARN/CRIT values
> 
> 
> On Thu, 5 Sep 2002, Jeremy Tinley wrote:
> 
> > Is there a way to change parameters based on time of day without
> > hardcoding it into the script.
> > 
> > I have a process that's allowed to get a little more 
> out-of-control at
> > night.  I don't want the pager going off with the same 
> thresholds that
> > it does during the day, while I'm at work.
> > 
> > Currently, I have 2 service checks, process and process-night.
> > Process-night has higher critical and warning values.  It's also
> > configured to check and notify during nonworkhours.  Same 
> is true for
> > the process service check.
> > 
> > Did I pretty much hit the workaround, or is there something 
> more obvious
> > I'm missing?
> 
> You are pretty much on target.  The plugins have no concept 
> of time.  so 
> two different definitions would be needed...
> 
> -sg

That's right, of course, but IMHO it's less than optimal conceptually
because you end up with "two" services instead of one, which throws off both
the user interface and the reporting ability.  What might be the best way to
change nagios to deal with that?  Are there any related changes in CVS?
Here's an idea - I wish I had the time and skill to code it. :-(

Perhaps the template-based config file format could be extended such that
services can have properties grouped by timeperiods

So an example would be:

define service{
	use	mytemplate
	hostname	host1,host2,host3
	service_description	PING
	check_command	check_ping
	define optgroup_period{
		valid-periods	workhours
		notification_interval	10
		notification_options	wucr
		contact_groups	unixadmins
		}
	define optgroup_period{
		valid-periods	nonworkhours
		notification_interval	60
		notification_options	cr
		contact_groups	operators
		}
	}

That would probably be a Big Change though.  I haven't even thought about
how it might impact escalations and dependencies yet.

Criticism welcomed...

-t.


-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390