The following options are available:
Sometimes, observations are high-strung, causing a single match in the evaluation to lead to more actions than desired. With this option it is possible to enforce a certain number of positive evaluations before a rule finally fires.
Setting this option to x causes the rule’s actions (simple and multiple-severity rules) and alarms (multiple-severity rules only) to execute when the number of evaluations defined by x are true.
Example: A rule that checks the current CPU utilization is evaluated every 5 minutes. To avoid having short spikes leading to a firing rule, you can configure a damper mechanism to prevent actions and alarms from occurring until a certain number of matches is reached, such as, for example, three consecutive evaluations. That means that three times in 15 minutes (because the rule is evaluated every five minutes) the evaluation has to resolve to true before the rule fires.
Similar to the above setting, this option allows to enforce a pattern of the evaluation behavior. When the frequency of positive evaluations matters less than their reoccurrence, this option allows for a less strict damper mechanism.
Setting this option to x out of y causes the rule’s actions (simple and multiple-severity rules) and alarms (multiple-severity rules only) to execute after x out of y evaluations are true.
Example: A fixed number of positive evaluations in a row is not missing positives matches, however their pattern of 2-0-2-1-0-2 consecutive positive evaluations is not identified. Setting this option to 4 out of 8 allows for identification of a problem across multiple evaluations while not relying on them being consecutive.
Sometimes when evaluations are performed immediately after a topology object creation, or the Foglight Management Server re-start, a number of false positives can occur. There might be a startup-time factor or the monitored entity simply needs to calm down for a minute or two, before reliable analysis can be performed. This option specifies that the first evaluation and all evaluations in the given time frame afterwards are ignored before evaluation results are considered.
Setting this option causes the rule’s actions (simple and multiple-severity rules) and alarms (multiple-severity rules only) to execute after the specified period. This applies only to the first evaluation of the rule after the Foglight Management Server has been restarted; subsequent evaluations will not adhere to the specified delay setting.
Example: When a new host becomes available online, a high network utilization is expected, while updates are downloaded or application synchronization commences. To avoid having newly-discovered hosts generate alarms on their bandwidth usage, you can specify a time window, for example, 15 minutes, during which the rule evaluating the network conditions is on hold.
To define alarm and action behavior:
