Page History

opEvents provides the Event Action Policy as a flexible mechanism for reacting to events. This document briefly describes how to configure the service, the policy language and the currently supported actions. 

Action Policy Language

The action policy is configured in conf/EventActions.nmis, primarily in the section named policy. The policy consists of any number of nested if-this-then-that clauses, which specify the  conditions an event must conform to and what actions to take in case of a match. Further configuration sections specific to particular actions can be present in the same file.

...

The IF expression is basically any arbitrary Perl expression, but tokens of the form event.name or node.name are substituted with the respective event or node property value. The special wildcards event.any and node.any are replaced by a logical true value. Furthermore, tokens that match extdb.queryname.column will be substituted with the result of an external enrichment query.  The IF expression can include "AND" as well as "and" but does not support "OR".

If your IF expression does require text that could be misinterpreted as a substitution token (e.g. the "Nr.1" in  IF => 'event.details eq "NTP Server Nr.1"'), then you should escape the dotted expression with a backslash (e.g. "NTP Server Nr\.1"). Please note that in versions before 2.2.2, any misidentified unparseable tokens were flagged as errors and were not included in the final expression to be tested.

...

• No policy actions are performed for events with the property action_checked set to 1 or for events that are (already) acknowledged.
  The former can be controlled by custom parser rules, the latter is mostly affected by the configuration options opevents_auto_acknowledge and opevents_auto_acknowledge_up:
  With auto-acknowledge enabled, a stateful down event is automatically acknowledged when the corresponding up event arrives. In that case, the up event itself is also automatically acknowledged if and only if opevents_auto_acknowledge_up is set.
• If the configuration option opevents_no_action_on_flap is set to true in conf/opCommon.nmis, then no actions are performed on the down event that is involved in a flap event, and the down event is acknowledged. This is the default behaviour.
• 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.

Supported Policy Actions

...

Action Name	Description
log.logtype()	Log the event to a file, as plain text or in JSON format
script.scriptname()	Execute a user-defined script, possibly capturing the output
escalate.policyname()	Mark this event for escalation using a particular escalation policy
email(contactname)	Email the event details to a particular contact
syslog.targetserver(prio)	Send the event as Syslog message to a Syslog server, optionally overriding the event priority
nmissyslog.targetserver(prio)	Send the event as Syslog message to an NMIS Syslog server, in the format expected by NMIS
priority(adjustment)	Change the priority of the event Adjustment can be a number between 0 and 10 for fixed assignment, or +number or -number for relative adjustment.
tag.tagname(value)	Set a custom event property's value for static enrichment. Tagname is the name of the property to modify and must be a single string without spaces. Values are not restricted. (In the database the custom tag will be stored as "tag_tagname", hence you cannot overwrite opEvents-internal properties with this action. As a consequence, if your policy has IFs that need a tag's value, then these need to reference the tag with the 'long form' "tag_tagname".) In opEvents 2.0.2 and newer the tagname "kb_topic" is special and controls linking to external data sources.
acknowledge()	Acknowledges the event in question (which stops all escalation activity for the event). Supported in opEvents 2.0.3 and newer.
watchdog.set(waittime) watchdog.disable()	Creates or updates a watchdog timer for the node associated with the current event. The timer is set to expire in waittime seconds from now. If the timer is not disabled or updated before the expiration time, then a synthetic event named "Watchdog Timer expired" is generated. Note that all four watchdog actions are disabled if the current event itself is a watchdog expiration event.
element_watchdog.set(waittime) element_watchdog.disable()	Similar to the  previous, but for watchdog timers that are specific to both the node and the element (e.g. an interface) of the current event. Element watchdog timers are independent of node watchdogs and of each other: Updating or disabling an element watchdog for say, eth1 doesn't affect a timer for lo0 for the same node.

Notes for watchdog and element_watchdog

...