Different notification methods in different timeperiods
Ben Beuchler
insyte at gmail.com
Tue Dec 20 23:08:47 CET 2005
I am trying to work out a clean way to use different techniques during
different notification_periods (one notification technique during
"workhours" and another during "nonworkhours") for the same service.
I already created duplicates of each contact with the new contact method:
define contact{
use tapPager
contact_name ben
alias Ben Beuchler
email ben_beuchler at mcad.edu
pager ben
}
define contact{
use emailOnly
contact_name benEmail
alias Ben Beuchler
email ben_beuchler at mcad.edu
}
For each contact_group, I also created a second contact group that
just contains the "emailOnly" versions of the contacts.
The confusing part is how to assign these contact_groups to services.
I tried sub-classing the service, changing only the
notification_period and contact_groups:
define service{
use generic-service
name ntpSvc
service_description NTP
check_command check_ntp
notification_period workhours
host_name swizzle,swozzle
}
define service{
use ntpSvc
notification_period nonworkhours
contact_groups networkAdminEmail
}
But that, of course, results in this error:
Error: Service 'NTP' on host 'swizzle' has already been defined
Clearly, I could include a second service_description, but that would
really clutter up Nagios. Not to mention testing each service twice
as often.
Is there a better way to do this?
Thanks!
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
_______________________________________________
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