Another way to do this is to have the service notify to a dummy
contact by default that has a 'do nothing' notification command (e.g.
/bin/true) and then use escalations to trigger real alerts; each
escalation can then have a custom time period, contact, etc.
We use this as our primary means of triggering notifications as we
have a large group of shared services (service -> hostgroup -> hosts)
and the hosts are in different projects with different contacts so the
service can't have a real notification contact that makes sense .. by
triggering all of our notifications through escalations we can then
easily control which group gets notified for which (service,hostgroup,
host) tuple and control time period and contact on a project by
project basis.
define service {
...
check_period 24x7
max_check_attempts 3
normal_check_interval 5
retry_check_interval 5
contact_groups no-one
notifications_enabled 1
notification_options a
notification_interval 5
notification_period 24x7
...
}
define serviceescalation {
name project-base-svc
hostgroup_name project-hostgroup
contact_groups project-notify-group
first_notification 1 ; notify right away (1st notification)
last_notification 0 ; notify until service changes state
notification_interval 240 ; default to 4 hour re-notify
escalation_period 24x7
register 0
}
define serviceescalation {
use project-base-svc
service_description My custom service
escalation_options c
}
define serviceescalation {
use project-base-svc
service_description My custom service
escalation_options w
escalation_period workhours-only
}
------------------------------------------------------------------------------
_______________________________________________
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
