Using alerts

LANDesk Management Suite alerting and monitoring features make your work more efficient by giving you immediate notice of hardware, software, and application events on the devices you manage. When events occur that indicate a need for action or a potential problem, alerts can initiate the process of solving the problem in different ways, such as logging the event, sending an e-mail or pager message, running an application, or powering off the device.

An alert is a unique ID that represents an event. You can specify an alert action that is performed automatically when the event occurs, such as automated e-mail, applications, or power options. An alert combined with an action is referred to in this product as an alert rule. Some alerts can be combined with specific performance monitoring rules that specify the condition that triggers an event. For example, you can define a monitoring rule for available free space on disk drives, so that when a drive is 90% full a warning alert is generated.

By defining alert rulesets you decide which events require immediate action or need to be logged for your attention. A ruleset contains a collection of alert rules, each of which has a corresponding alert action. When you define an alert ruleset you can deploy it to one or more devices to monitor the items that are important for that kind of device.

This chapter includes information about:

Related topics include:

Understanding alerts, actions, and performance monitoring

To generate alerts for a managed device, the alerting agent must be deployed to that device. A default alerting agent and alert ruleset are deployed to every managed device when you install the standard agent on the device. That agent follows the rules defined in the alert rulesets for that device.

By default every managed device has a standard alert ruleset. When you have defined a custom ruleset you can deploy it to devices to monitor items specific to that type of device. You can deploy multiple rulesets to devices, although you should be aware that conflicts could occur between similar rules in different rulesets.

NOTE: When you install an additional Win32 console on a device, no agent is installed on that device. Even though you can manage other devices from that console, the console device itself can't generate alerts, either as a core or as a managed device, unless you also install management agents on it.

Some alerting events are based on specific performance monitoring rules. "Performance monitoring" refers to an event based on performance counters that are defined for specific devices. Counters can be defined for hardware components and sensors, operating system performance, application components and usage levels.

To add performance monitoring to the ruleset for a device, you select the "Performance monitoring" alert rule in the ruleset, but the details of what to monitor are defined for each individual device. This is done in the Real-time inventory and monitoring console on each device. You can select different hardware and software components and define counters for the items to be polled, then view the monitoring data in real time or historically. For more information, see Performance monitoring.

Events that can generate alerts

This product has an extensive list of events that can generate alerts. Some events are problems that need immediate attention, such as component failure or system shutdown. Other events are configuration changes that provide useful information to a system administrator, such as changes that affect a device's performance and stability or cause problems with a standard installation.

Examples of the types of events you can monitor include the following:

To view a record of alerts for configuration changes, review the alert log on the device's Real-time inventory and monitoring console (see Viewing the alert log).

Alerts can only be generated when devices are equipped with the appropriate hardware. For example, alerts generated from sensor readings only apply to devices equipped with the correct sensors.

Hardware monitoring is also dependent on the correct configuration of the hardware. For example, if a hard drive with S.M.A.R.T. monitoring capabilities is installed on a device but S.M.A.R.T. detection is not enabled in the device's BIOS settings, or if the device's BIOS does not support S.M.A.R.T. drives, alerts will not be generated from S.M.A.R.T. drive monitoring.

Severity levels for events

Device problems or events can be associated with some or all of the severity levels shown below. In some parts of the product interface, these states are noted with a numeric value as well as an associated icon. Numeric values are in parentheses.

Depending on the nature of the event, some severity levels don't apply and aren't available. For example, with the Intrusion detection event, the device's chassis is either open or closed. If it is open, an alert action can be triggered, but only with a severity of Warning. Other events, such as Disk space and Virtual memory, include three severity levels (OK, Warning, and Critical) because different states can indicate different levels of concern to the administrator.

You can choose the severity level or threshold that will trigger some alerts. For example, you can select one action for a Warning status and a different action for a Critical status for an alert. The Unknown status can't be selected as an alert trigger but simply indicates that the status can't be determined.

Using alert actions to receive notifications

This product can notify you when monitored events occur by doing any of the following:

For detailed information about configuring alert actions, see Configuring alert rulesets.

Process for deploying alert rulesets

This product includes predefined alert rulesets that can be deployed to managed devices. Note that each managed device must have a management agent installed before you can deploy an alert ruleset to the device and before it can send alerts to the core server.

When the monitoring agent is installed to a managed device, a default ruleset of alerts is included by default to provide health status feedback to the health dashboard and console. This default ruleset includes alerts such as:

You can modify these standard alert rulesets to include the alerts you want to monitor. For detailed information, see Configuring alert rulesets.

The general process for deploying alert rulesets to managed devices is as follows:

  1. Create or edit the ruleset
  2. Target the devices you want to deploy the ruleset to
  3. Schedule a deployment task to the targeted devices
  4. If a ruleset includes performance monitor alerts, open the Real-time inventory and monitoring console for each device with that ruleset and define the performance monitor counters for the device

For complete instructions on deploying rulesets to devices, see Deploying alert rulesets. For information about defining performance monitor counters on individual devices, see Performance monitoring.

NOTE: You can deploy multiple rulesets to a device, and you can select devices in other ways than by targeting them.

NOTE: You can remove all rulesets from one or more devices in the same way that you deploy rulesets: target the devices and, in the list of alert rulesets, right-click and select Remove all rulesets.

Process for configuring custom alert rulesets

In addition to the default rulesets, you can configure and deploy custom alert rulesets. You can include custom alert actions to respond any combination of events. For example, you may want to define one set of actions for events on managed desktop devices (such as sending an e-mail to the hardware support team) and a different set of actions for managed servers (such as sending a pager message to the admin).

The overall process for creating and deploying an alert ruleset is as follows:

  1. Create your custom alert ruleset. This includes selecting alerts to include and associating alert actions with them. (For more information, see Configuring alert rulesets).

  2. Create an agent deployment task, and drag devices onto the task. (For details, see Configuring device agents).

  3. Schedule the task. (See Scheduling tasks for more information).

The following is a simple example of the first step in this process, in which a single alert rule is added to a ruleset.

Example: Configuring an alert ruleset for disk space problems

  1. In the core server console, click Configuration > Alerting.
  2. On the toolbar, click New. Type a name for the ruleset and a description (such as "Disk space 90% full"), and click OK.
  3. In the Alert rulesets list, click the name of the new ruleset and click Edit on the toolbar.
  4. In the Ruleset configuration window, click Alerts in the left column.
    A tree view of alerts is displayed, with a grid containing alerts and their descriptions. You can click All alerts to view all available alerts, or click a category in the tree to view a specific group of alerts.
  5. In the tree view, under the Monitor group, click the Drive space alert.
  6. In the grid, select Default disk usage, then click Edit in the right column.
  7. In the Drive space monitoring dialog box, you can set the Polling interval frequency to change how often the drive space usage will be monitored. To change the thresholds at which alerts are triggered, click Drive space and set percentages for warning and critical alerts. (These are percentages of total available drive space that are full.) Click OK to save the settings.
  8. On the Alerts page, in the right column, click Rules > Add.
    Three "wells" are displayed at the bottom of the page. Use these wells to combine alert, action, and time items to create an alert rule.
  9. Drag the Default disk usage alert to the Alerts well.
  10. In the left column, click Actions. Click the Standard folder. Drag Log alert to local NT event log to the Actions well.
    For every alert rule you create, a default Log handler configuration action is already included in the Actions well. If you want to add other actions, such as sending an e-mail, you need to define an action and then drag it to the Actions well.
  11. In the left column, click Time. In the Time list, drag Always to the Time well.
  12. Click OK next to the wells to save the rule, and click OK again at the success message.
    You have now created an alert rule that is part of the ruleset. To save your changes, you need to publish the ruleset.
  13. In the right column, click the Publish button.
    You can go back to the Rules summary page to view the rule and, if you want, edit it.
  14. In the left column, click Rules summary.
    Note that there are two rules listed. One is for the rule you created (with a Log alert to local NT event log action), and the other is a default rule that sends the alert notifications to the core server (with a Log handler configuration action). This is automatically created for every rule you define so that all alerts are logged at the core server. You can't delete this rule unless you delete all rules for an alert.
  15. Select the Default disk usage rule with Log alert to local NT event log as the action, then in the right column click Rules > Edit. Use this dialog box to change settings for the rule.
  16. To change the action associated with the rule, select a different item from the Action drop-down list.
  17. To change the time during the which the alert rule is active, select a different item in the Time drop-down list.
  18. To change the severity levels for alert notifications, click the State icons. A dimmed icon will not be used, so to receive alerts only for critical status alerts, click the Warning (State 2) icon, a yellow triangle, to turn it off.
  19. Select the Health check box to include disk space usage as an alert that contributes to the device's health status.
  20. Click OK. You can now see the changes you made reflected in the Rules summary list.
    To save the changes to this ruleset, you need to publish it again. It will then be saved and will be available for deployment in your list of rulesets.
  21. In the right column, click Publish.

When you return to the management console, the new ruleset you created is listed under Alert rulesets.

Alert storm control

Some alert rules assigned to groups of devices can simultaneously generate a large number of responses. For example, you can include an alert rule for computer configuration changes and associate it with an e-mail action. If a software distribution patch is applied to many devices with this alert rule, it would generate a number of e-mails from the core server equal to the number of devices to which the patch was applied, potentially flooding your e-mail server with a "storm" of alert notifications.

This product's alert storm control feature automatically limits the number of times an alert action occurs for an alert. If an alert triggers an action 5 times in 5 minutes, the alert action is discontinued but alerts are still written to the core log file. The administrator is notified of the alert storm with an automated e-mail. When the alert stops occurring and does not occur again for one hour, the alert storm control is reset for that alert. Alert actions will again be triggered if that alert occurs again later.

Migrating alerts from previous versions of LANDesk Management Suite

Previous versions of LANDesk Management Suite included alerting functionality with the Alert Management System (AMS) feature. Beginning with version 8.8, alerting is based on a new set of alert handlers, even though some alerts are based on AMS alerts. Your alert rulesets for managed devices will need to be created using the new alerting feature.

To help you migrate alerts from previous versions, this product includes a utility that extracts information about your AMS alerts and writes the data to a text file, which you can refer to as you create new rulesets.

To use the alert migration utility
  1. In the \utilities directory of the LDMAIN share, run alertexp.exe.
    To show help information about using the utility, type alertexp.exe /? at the command line. You can optionally specify the path to the iaobind.dat file and a path and filename for the output file.
  2. Open the iaobind.txt file to view a summary of existing AMS alerts.

You can use the information about your existing alerts to create new alert rulesets. The text file lists the name of each alert with the associated action and severity, along with the application that triggers the alert and parameters associated with it.