This topic provides information about the structure of a condition set.

An alert condition specifies a resource metric value or event that will initiate the alert firing process.

The condition types you can choose when you define a alert vary by resource type and Hyperic version. If a condition type is not supported by your version of Hyperic or is not valid for the target resource, it will not appear as an option.

To define a condition, choose one of the following condition types, and supply required parameter values.

Metric condition - To base the alert on the value of a metric that vCenter Hyperic collects for the resource:

Metric - Select a metric from the selector list. Only currently enabled metrics are listed.

Define the rule for evaluating the metric value. You can:

Compare metric value to an absolute value. Select an operator: >(greater than), <(less than), =(equal to), or != (not equal to), and enter a metric value. If the metric value is a percentage, specify it as a float value. For example, enter .99 for 99%, 1.0 for 100%. Use a period (.) as a decimal separator, rather than a comma (,).

Compare metric value to its minimum, baseline, or maximum value, in vCenter Hyperic only. Select an operator: >(greater than), <(less than), =(equal to), or != (not equal to), and choose Min Value, Baseline Value or Max Value. Baselining must be enabled.

Fire upon change in metric value. Click value changes.

Inventory Property Condition - To define a condition that is triggered when the value of an inventory property for resource changes, select an inventory property. The pulldown contains only those inventory properties that are valid for the type of the resource to which the alert applies.

Control Action Condition - When you define an alert for a resource that supports control actions, you can define a condition that is triggered when a particular control action is performed. If desired, you can base the condition on a control action with a particular result status: in progress, completed, or failed. Pulldowns allow you to select a control action that the resource supports, and a result status if desired.

Events/Log Level Condition - To define a condition that is triggered by a log event, select a message severity level (error, warn, info, debug, all) and optionally a match string. The condition is satisfied each time a message of the selected severity that contains the match string (if one was specified) is written to a log file that vCenter Hyperic is tracking. Log tracking must be enabled for the resource. To determine the log files that vCenter Hyperic monitors for the resource, see the Configuration Properties section of the resource's Inventory tab. The log files that vCenter Hyperic monitors for a resource are defined using the server.log_track.files property.

Config Changed... Condition - This type of condition is triggered by a change to a configuration file that vCenter Hyperic is configured to monitor for the resource. To limit the condition to a single file, enter its filename in the match filename field. If you don't specify a filename, a change to any file monitored will trigger the alert. To determine the log files that vCenter Hyperic monitors for the resource, see the Configuration Properties section of the resource's Inventory tab. The files that vCenter Hyperic monitors for a resource are defined using the server.config_track.files property. The maximum length for filename entered is 25 characters.

In vCenter Hyperic, you can define up to three conditions for an alert. To add another condition, click Add Another Condition and specify whether both the new condition and the preceding one must be satisfied for the alert to be triggered ("AND") or only one must be satisfied ("OR").

To designate the alert you're defining as a recovery alert, select the primary alert definition from the pulldown.

A recovery alert condition should detect when the condition that fired the primary alert is no longer true. When a recovery alert fires, it marks the primary alert Fixed, and the primary alert definition is re-enabled. The primary alert definition should be configured to generate one alert and then disable alert definition until fixed, as described below.

You can make the condition absolute, or fire after the condition occurs repeatedly. Choose one of the following options:

Each time conditions are met.

The alert fires upon a single occurrence of the condition.

Once every _ times conditions are met within a time period of _ minutes.

This option configures an alert to fire when the condition(s) occur multiple times over a period of time. Enter the number of occurrences and period of time.

This condition depends on the time interval that you choose when setting the metric conditions.

The number of recurrences, multiplied by the time interval, must be equal or less that the "time period of minutes" that you specify. For example, if the available metric interval equals two minutes, and the condition is 3 recurrences in 6 minutes (2 x 3 is less than or equal to 6), the condition is valid. If the available metric interval equals two minutes, and the condition is 3 recurrences in 5 minutes, the condition is invalid and is not applied.

An action filter can be used to control alert firing and alert actions.

Click Generate one alert and then disable alert definition until fixed to disable the alert definition after firing and reenable it when the alert that triggered it is marked Fixed.

This option eliminates redundant firing for the same problem. If you do not choose this option, the alert will fire repeatedly as long as the triggering condition is still true.

This configuration option, used in conjunction with recovery alerts, automates the process of disabling and re-enabling an alert definition. The outcomes are that there are no redundant alerts for the same problem, and you do not have manually "fix" an alert triggered by a transient problem.

The Disregard control actions that are defined for related alerts option appears on New Alert Definition pages for resources that support control actions. This option only applies when:

The current alert definition will include an alert action.

The resource associated with the alert is a member of an application.

There are other members of the same application with alerts that fire control actions (ideally the same control action)

Under these circumstances, this configuration option ensures that if multiple alerts are fired within a short period for resources that are members of the same application, only one control action will be executed. For example, this would prevent a server from being restarted several times in a short period of time for the same alert conditions. For instance, you might have an alert with an action to restart a Tomcat server if the JVM Free Memory got too low and another alert with an action to restart the same server if the JVM Active Thread count got too high. If both alerts fired at the same time and they were filtering control actions, only 1 restart control action would be executed and not two.