I'd be leaning towards #2 as well. In our situation all alerts are sent via email (and we make use of an email to sms gateway for some alerts). The option we'll probably go for here, is to make the alert scripts check for the presense of a file containing a timestamp and an email address, if alerts make it to the alert script before that timestamp (with sanity checking to make sure the timestamp is less than four hours away) instead of being sent to the email address given to the alert script, they are sent to the email address in the file
ie something like... /local/mon/etc/outage: 1166045104 [EMAIL PROTECTED] If 1166045104 > now + 14400 - alert someone, having mon away from default behaviour this long is bad and continue with normal behaviour If now +14400 > 1166045104 > now - redirect any alert to [EMAIL PROTECTED] If now > 1166045104 - old outage window, ignore and continue with normal behaviour Cheers, Ben Aled Treharne wrote: > I'm definately leaning for #2 - we have alerts that are ack'd (e.g. > Hardware replacement on order, but takes a week to arrive) but not > disabled, and watches that are disabled (e.g. service offline for an > indeterminate time, but will eventually come back). > > I'd also like to see it implemented so that you don't need to reload > mon to add a new maintenance slot. > > Cheers, > Aled. > > _______________________________________________ > mon mailing list > mon@linux.kernel.org > http://linux.kernel.org/mailman/listinfo/mon > -- Ben Ragg - Internode - Network Operations 150 Grenfell Street, Adelaide, SA, 5000 Phone: 13NODE Web: http://www.on.net _______________________________________________ mon mailing list mon@linux.kernel.org http://linux.kernel.org/mailman/listinfo/mon
