...
Normally all newly createded events are subject to policy actions immediately after having been created, but this can be fine-tuned and adjusted:
- No policy actions are performed for events with the property
action_checked
set to 1 or propertyaction_required
set to 0. - If the configuration option
opevents_no_action_on_flap
is set to true inconf/opCommon.nmis
, then no action is performed on a flap event. - Policy action handling is delayed by
state_flap_window
seconds for all stateful events, so that state flaps can be detected before any actions are performed. - Policy action handling is delayed for synthetic events, if the event creation rule sets the property
delayedaction
.
...
Writing escalate.somepolicy()
in a THEN
clause marks the matched event for future escalation according to the escalation rules of somepolicy
. An event can be subject to multiple escalation policies at the same time. All escalation policies that an event is marked for will be applied independently, and when a policy is unapplicable because of time and day restrictions, it is ignored - but only temporarily until the time and day match up again.
Only when an event is acknowledged will does escalation for it cease. Events are normally acknowledged manually, but for stateful entities the "down" event is acknowledged automatically if the configuration option opevents_auto_acknowledge
is enabled in conf/opCommon.nmis
.
Escalation Policies
To formulate an escalation policy, you need to decide on your preferred escalation steps, their respective time thresholds and actions, and express that in section escalate
of the config file conf/EventActions.nmis
. Here is an example configuration fragment:
...