Clear actions

You can define actions to execute when a clear condition is active and becomes true. These actions are called "clear actions" because they often do things like set an alert level back to a normal value or reset status.

For example, if you define an action to send a message to the log if the CPU utilization gets above 90%, you can also define an action to send a different message to the log when a CPU utilization that was above 90% drops to a lower utilization.

The clear action is executed only once—when the condition becomes invalid and the clear condition becomes valid:

  • If the rule does not have a clear condition defined, the default behavior is that the clear condition becomes valid when the condition transitions from true to false.

    For example, if the CPU utilization is greater than 90% (the condition is valid or true), the clear action is executed when the CPU utilization is equal to or less than 90% (the condition becomes invalid), but not if it continues to drop or if it remains less than 90% the next time the condition is evaluated. However, if the CPU utilization becomes greater than 90% again, the clear action will be executed the next time the CPU utilization drops to less than the threshold of 90%.

  • If the rule has a clear condition defined, the clear condition becomes active the first time the condition becomes true. However, the clear condition does not become valid until it is both active and it becomes true.

    For example, consider a clear condition that becomes true when the CPU utilization drops below 70%. After the CPU utilization is becomes greater than 90% the clear condition becomes active, but it does not become true until the CPU utilization drops below 70%. Therefore the clear action is not executed until a CPU utilization that has been above 90% drops below 70%.

Both predefined and callback actions can be used in clear actions.

The following is an example of a rule that includes an action and two clear actions. In the example:

  • One of the clear actions calls the CLI action to execute the show running-config CLI command:

    self.rule.clear_action("CLI","show running-config")
  • The other clear action calls the set_normal function, which removes the alert level:

    self.rule.clear_action(self.set_normal)

The following example shows a monitor that has a rule that defines a clear actions and a clear condition:

self.monitor = Monitor(AverageOverTime("/rest/v1/system/subsystems/management_module/1%2F5?attributes=resource_utilization.cpu", "5 minutes")
self.rule = Rule("")
self.rule.condition("{} > 90", [self.monitor])
seld.rule.action("ALERT_LEVEL", AlertLevel.CRITICAL)
self.rule.clear_condition("{} < 70", [self.monitor])
self.rule.clear_action(self.set_normal)

def set_normal(self, event):
  self.remove_alert_level()

The following example shows a monitor with a rule that defines clear actions but does not define a clear condition:

self.monitor = Monitor(AverageOverTime("/rest/v1/system/subsystems/management_module/1%2F5?attributes=resource_utilization.cpu", "5 minutes")
self.rule = Rule("High CPU Utilization")
self.rule.condition("{} > 90" [self.monitor])
self.rule.action(self.action_high_cpu)
self.rule.clear_action("CLI","show running-config")
self.rule.clear_action(self.set_normal)

def action_high_cpu(self, event):
  # CPU value when the Condition met
  cpu = event["/v1/system/subsystems/system/base?attributes=resource_utilization.cpu"]
  ActionSyslog("CPU Utilization at %d" % cpu)
  ActionCLI("top cpu")

def set_normal(self, event):
  self.remove_alert_level()