mirror of https://github.com/Icinga/icinga2.git
Docs: Add examples for dynamic notification apply rule
Reviewed and adopted a bit. refs #9443 Signed-off-by: Michael Friedrich <michael.friedrich@netways.de>
This commit is contained in:
parent
5f6c50eff7
commit
9776ae86bd
|
@ -529,6 +529,81 @@ In this example the `mail-noc` notification will be created as object for all se
|
||||||
`notification.mail` custom attribute defined. The notification command is set to `mail-service-notification`
|
`notification.mail` custom attribute defined. The notification command is set to `mail-service-notification`
|
||||||
and all members of the user group `noc` will get notified.
|
and all members of the user group `noc` will get notified.
|
||||||
|
|
||||||
|
It is also possible to generally apply a notification template and dynamically overwrite values from
|
||||||
|
the template by checking for custom attributes. This can be achieved by using [conditional statements](19-language-reference.md#conditional-statements):
|
||||||
|
|
||||||
|
apply Notification "host-mail-noc" to Host {
|
||||||
|
import "mail-host-notification"
|
||||||
|
|
||||||
|
// replace interval inherited from `mail-host-notification` template with new notfication interval set by a host custom attribute
|
||||||
|
if (host.vars.notification_interval) {
|
||||||
|
interval = host.vars.notification_interval
|
||||||
|
}
|
||||||
|
|
||||||
|
// same with notification period
|
||||||
|
if (host.vars.notification_period) {
|
||||||
|
interval = host.vars.notification_period
|
||||||
|
}
|
||||||
|
|
||||||
|
// Send SMS instead of email if the host's custom attribute `notification_type` is set to `sms`
|
||||||
|
if (host.vars.notification_type == "sms") {
|
||||||
|
command = "sms-host-notification"
|
||||||
|
} else {
|
||||||
|
command = "mail-host-notification"
|
||||||
|
}
|
||||||
|
|
||||||
|
user_groups = [ "noc" ]
|
||||||
|
|
||||||
|
assign where host.address
|
||||||
|
}
|
||||||
|
|
||||||
|
In the example above, the notification template `mail-host-notification`, which contains all relevant
|
||||||
|
notification settings, is applied on all host objects where the `host.address` is defined.
|
||||||
|
Each host object is then checked for custom attributes (`host.vars.notification_interval`,
|
||||||
|
`host.vars.notification_period` and `host.vars.notification_type`). Depending if the custom
|
||||||
|
attibute is set or which value it has, the value from the notification template is dynamically
|
||||||
|
overwritten.
|
||||||
|
|
||||||
|
The corresponding Host object could look like this:
|
||||||
|
|
||||||
|
object Host "host1" {
|
||||||
|
import "host-linux-prod"
|
||||||
|
display_name = "host1"
|
||||||
|
address = "192.168.1.50"
|
||||||
|
vars.notification_interval = 1h
|
||||||
|
vars.notification_period = "24x7"
|
||||||
|
vars.notification_type = "sms"
|
||||||
|
}
|
||||||
|
|
||||||
|
### <a id="using-apply-dependencies"></a> Apply Dependencies to Hosts and Services
|
||||||
|
|
||||||
|
Detailed examples can be found in the [dependencies](3-monitoring-basics.md#dependencies) chapter.
|
||||||
|
|
||||||
|
### <a id="using-apply-scheduledowntimes"></a> Apply Recurring Downtimes to Hosts and Services
|
||||||
|
|
||||||
|
The sample configuration includes an example in [downtimes.conf](4-configuring-icinga-2.md#downtimes-conf).
|
||||||
|
|
||||||
|
Detailed examples can be found in the [recurring downtimes](5-advanced-topics.md#recurring-downtimes) chapter.
|
||||||
|
|
||||||
|
|
||||||
|
### <a id="using-apply-for"></a> Using Apply For Rules
|
||||||
|
|
||||||
|
Next to the standard way of using [apply rules](3-monitoring-basics.md#using-apply)
|
||||||
|
there is the requirement of generating apply rules objects based on set (array or
|
||||||
|
dictionary).
|
||||||
|
|
||||||
|
The sample configuration already includes a detailed example in [hosts.conf](4-configuring-icinga-2.md#hosts-conf)
|
||||||
|
and [services.conf](4-configuring-icinga-2.md#services-conf) for this use case.
|
||||||
|
|
||||||
|
Take the following example: A host provides the snmp oids for different service check
|
||||||
|
types. This could look like the following example:
|
||||||
|
|
||||||
|
|
||||||
|
user_groups = [ "noc" ]
|
||||||
|
|
||||||
|
assign where host.vars.notification.mail
|
||||||
|
|
||||||
|
|
||||||
### <a id="using-apply-dependencies"></a> Apply Dependencies to Hosts and Services
|
### <a id="using-apply-dependencies"></a> Apply Dependencies to Hosts and Services
|
||||||
|
|
||||||
Detailed examples can be found in the [dependencies](3-monitoring-basics.md#dependencies) chapter.
|
Detailed examples can be found in the [dependencies](3-monitoring-basics.md#dependencies) chapter.
|
||||||
|
|
|
@ -836,12 +836,15 @@ Configuration Attributes:
|
||||||
types | **Optional.** A list of type filters when this notification should be triggered. By default everything is matched.
|
types | **Optional.** A list of type filters when this notification should be triggered. By default everything is matched.
|
||||||
states | **Optional.** A list of state filters when this notification should be triggered. By default everything is matched.
|
states | **Optional.** A list of state filters when this notification should be triggered. By default everything is matched.
|
||||||
|
|
||||||
Available notification state filters:
|
Available notification state filters for Service:
|
||||||
|
|
||||||
OK
|
OK
|
||||||
Warning
|
Warning
|
||||||
Critical
|
Critical
|
||||||
Unknown
|
Unknown
|
||||||
|
|
||||||
|
Available notification state filters for Host:
|
||||||
|
|
||||||
Up
|
Up
|
||||||
Down
|
Down
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue