Types of Rules

There are a series of settings that can be configured for each rule. Different configuration options are available for different types of rules.

• For all rules you can configure the actions taken when a rule violation occurs. This includes specifying whether or not notifications will be sent out and whether or not the state of the object will change.
• Threshold Rules - For rules that relate to thresholds, there are two types of thresholds:
  • Value thresholds - These thresholds determine the specific value that will escalate from to a "Warning" and "Error" state. The rule defines the condition for escalating to a "Warning" and "Error" state and also the condition to de-escalate from "Error" state to "Warning" state and to "OK" state. For example, a CPU Usage rule can determine that if the CPU utilization reaches of above the 50% threshold, it will escalate to a "Warning" state and if the value is above the 80% threshold, it will escalate to an "Error" state. To protect against "flapping", the rule also includes de-escalation and escalation delays that require the object to spend the configured time (in minutes) in the higher/lower state to actually escalate/de-escalate the state. For example, the CPU has to be in under 80% for a period of 15 minutes in order to de-escalate from "Error" to "Warning" state.   
     
  • State-Over-Time Thresholds - For alerts that are based on a "Boolean" state, whether it is Boolean (e.g., Source Offline) or because the exact value is not important (e.g., CC errors or not recovered packets), the threshold is defined by a time window and a percentage of time in which that window spent in the relevant state.  For example, 50% out of 6 minutes is an error threshold, so if a source reports a blank picture for 3
    minutes out of the 6 min window, ZM will put it into an error state. However, if the warning threshold is 5% out of 60 minutes, if a source reports a blank picture for 3 minutes out of the 60 min window, ZM will put it into a warning state. To protect against "flapping", the rule also includes de-escalation and escalation delays that require the object to spend the configured time (in minutes) in the higher/lower state to actually escalate/de-escalate the state.