Hyperic HQ 4.x Documentation : ui-Alert.Edit
This page last changed on Jul 15, 2009 by mmcgarry.
Topics marked with * relate to HQ Enterprise-only features. On the Alert Definition page, you can edit an alert definition's properties and condition set, and define and edit the alert actions HQ should perform when the alert fires. The Alert Definition page, which appears when you save a new alert definition or edit an existing alert definition, is similar to the New Alert page, with the addition of Edit controls in the "Alert Properties" and "Condition Set" sections, and a set of tabs at the bottom of the page for defining alert actions. Feedback is welcome. Click Add Comment at the bottom of the page. Edit Alert PropertiesClick
Edit Alert Condition SetClick Condition SetAn 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 HQ version. If a condition type is not supported by your version of HQ 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.
To Enable Collection of a Metric If you want to base a metric condition on a metric that is not currently collected, you have to enable collection of that metric. To do so, update the metric collection settings for the resource type (choose Monitoring Defaults from the Administration tab), or for the specific resource (click Metrics on the Monitor tab for the resource).
Define Additional Conditions*In HQ Enterprise, 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"). Define Recovery Alert Behavior*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. For more information, see Recovery Alerts. Enable ActionsYou can make the condition absolute - (one strike you're out) or fire after the condition occurs repeatedly. Choose either:
Option removed in 4.1 In versions of HQ Enterprise previous to 4.1, you could configure an alert definition to fire when its conditions have meet met continuously for a specified portion of an period of time. The option - "When conditions are exceeded for x within a time period of y minutes" - was removed in HQ 4.1. Enable Action FiltersAn action filter can be used to control alert firing and alert actions. Disable an Alert Definition upon FiringClick 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. In HQ Enterprise this configuration option - used in conjunction with recovery alerts - automates the process of disabling and re-enabling an alert definition. Result: (1) no redundant alerts for the same problem, and (2) you don't have manually "fix" an alert triggered by a transient problem. For more information, see Recovery Alerts. Disregard Control Actions for Related Alerts.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:
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. Option removed in 4.2 Versions of HQ previous to 4.2 also had a Filter notification actions that are defined for related alerts option to prevent multiple notification when alerts fire for resources on the same platform. In HQ 4.2, the option was removed. HQ 4.2 provides enhanced functionality for global control of notification volume. For more information, see Set a Notification Throttle. Create or Edit Alert ActionsYou assign actions to an alert definition on the Alert Definition page, which appears when you save a new alert definition or edit an existing alert definition. The Alert Definition page is similar to the New Alert page, with the addition of Edit controls in the "Alert Properties" and "Condition Set" sections, and tabs at the bottom of the page for defining alert actions. You can specify multiple actions to be performed automatically when an alert fires. The types of actions available in the Alert Definition page vary based on: (1) the type of resource the alert applies to, (2) your version of HQ, and (3) whether you've configured HQ for the types of actions that must be enabled before you can use them, such as escalations, OpenNMS trap actions, and in HQ Enterprise, SNMP notifications. To define an alert action, select one of the tabs and supply the required information: EscalationSelect an escalation from the "Escalation Scheme" pulldown; the tab refreshes and shows the escalation steps. You must define an escalation before you can assign it to an alert definition. Using an escalation that is configured to repeat until the alert is fixed is a good way to prevent redundant alerts firing for the same problem. To create an escalation, click Escalation Schemes Configuration on the Administration tab. For more information about escalations, see Understanding Escalations. Control Action*In HQ Enterprise, you can define a resource control action for HQ to perform when the alert fires. The control action can target the current resource (the one to which the alert definition is assigned) or a different resource on the same platform, as long as the resource type has HQ-supported control actions. To configure a control action for the alert, select the Control Action tab, click Edit, and follow the instructions on the associated help page. You can only assign a single control action to an alert definition. Note: You cannot assign a control action to a resource type alert. Notify Roles*In HQ Enterprise you can specify one or more HQ roles as notification recipients. HQ users with a role you specify will be notified when an alert is fired. Click Add to List on the Notify Roles tab. On the roles selection page, choose the role(s) to be notified when the alert fires. The help page has instructions. For information about creating roles specifically for use in notification actions, see in Role-Based Alert Notifications. Notify HQ UsersClick Add to List on this tab to specify one or more HQ uses as notification recipients. On the user selection page, choose the users to be notified when the alert fires. The help page has instructions. Notify Other RecipientsClick Add to List on this tab to specify non-HQ user email recipients for alert notifications. The help page has instructions. Script*In HQ Enterprise, to assign a script action to the alert definition, click the Script tab, enter the full path to the script, and click Set. HQ will run the script when the alert fires. Scripts can reference alert-related HQ environment variables to perform custom notification logic. For information, see Define a Script Action for an Alert. OpenNMSIf HQ Server must be configured for OpenNMS integration, you can use this tab to configure HQ to send an SNMP trap to OpenNMS when the alert fires. The notification will be generated by opennms_notify.gsp alert notification template. To configure an OpenNMS trap action, enter:
For more information, see Enabling OpenNMS Integration. SNMP Notification*If the HQ Server is configured to send SNMP notifications to your NMS, you can use this tab to configure a trap notification action. See SNMP Server Configuration Properties for more information. The notification sent when the alert fires will contain three variable bindings:
To configure an SNMP notification action on HQ Enterprise 4.3, enter:
To configure an SNMP notification action on HQ Enterprise 4.2 and earlier, enter:
![]() ![]() ![]() ![]() ![]() |
![]() |
Document generated by Confluence on Apr 20, 2010 15:01 |