Rules and monitors generate Operations Manager alerts. You view alerts in the Monitoring workspace shown in Figure 1. Rules and monitors can be configured to trigger an alert when certain sets of conditions are encountered. For example, an alert might be generated if a specific event is written to an event log of a monitored device or server, or when a monitored port on a network device surpasses a specific error threshold. Not all rules and monitors generate alerts. Alerts are raised by all types of monitored objects and aren’t specific to network devices. However, rather than provide the same coverage across the different sections of this chapter, managing alerts is covered in this first section in a way that is universal to the way alerts are dealt with across all of the different objects you can monitor with Operations Manager.
FIGURE 1 Active Alerts
You can configure a monitor to create an alert when the monitored item’s health state changes from healthy (green) to warning (yellow), or from healthy to critical (red). An alert is only sent if the state changes from warning to critical, if the original alert sent when the monitor changed from healthy to warning has been closed. Alerts are not sent if the health state changes from warning or critical to healthy, but will again be sent if, once returned to healthy, the state changes again to warning or critical.
The majority of alerts generated by monitors automatically resolve when the monitor returns to a healthy state. If an alert does not automatically resolve when a monitor returns to a healthy state, you can ensure that it will in the future by configuring an override on the Auto-Resolve Alert parameter for the monitor. Figure 2 shows the configuration of an override for the Auto-Resolve Alert parameter on a monitor named Security.
FIGURE 2 Override auto-resolve
Just as it is possible to configure a monitor that sends alerts with an override to stop it from sending alerts, it is also possible to configure a monitor that does not send alerts by default with an override so that it does send alerts.
Rules and monitors handle alerts differently. Rules cannot automatically resolve alerts. Unlike a monitor, that will send one alert while the condition that caused the alert is present, rules will continue to send alerts while the condition that caused the alert is present. To deal with the potential flood of alerts, you can configure alert suppression for the rule during rule creation. When you configure alert suppression, only the initial alert will be sent. Further alerts will be suppressed. Operations Manager will only suppress duplicate alerts that have suppression criteria, specified in the rule, that are identical. To be tagged as a duplicate, an alert must be created by the same rule and be in an unresolved state.
To view the number of suppressed alerts for a particular alert, you can add the Repeat Count column to the Active Alerts view. The repeat count will be incremented each time a new alert is suppressed. Figure 3 shows the Repeat Count column, with a figure of 307 for the first alert from MSSQLSERVER.
FIGURE 4 Repeat count
Alert details
Viewing the details of an alert is straightforward. Locate the alert in the Active Alerts node of the Monitoring workspace, and then click Alert Properties. This will bring up the Alert Properties dialog box, an example of which is shown in Figure 4. The General tab will provide information about the alert source, severity, priority, and repeat count in the event that the error has occurred more than once.
FIGURE 4 Alert properties
The Alert Properties dialog box also has the following information:
- The Product Knowledge tab will provide you with a summary of the alert, information about the causes of the alert, and possible resolution steps that you could implement.
- The Company Knowledge tab allows you to edit the rule that triggered the alert, and add extra information about the alert.
- The History tab allows you to enter history information in the form of comments about the alert.
- The Context tab provides further detail, including Log Name, Source, Event Number, Level, and Logging Computer, and is shown in Figure 5
FIGURE 3-5 Alert context
- The Custom Fields tab allows you to enter custom field information.
Closing alerts
Closing an alert removes it from the list of Active Alerts. In most cases, you’ll only close an alert if you can verify that the issue has been resolved. Resolving alerts works differently depending on whether an alert was generated by a monitor, or by a rule. The differences are as follows:
- If you close an alert that was generated by a rule and the issue that generated the alert occurs again, another alert will be sent. You can close an alert generated by a rule as part of the diagnostic process, as new alerts will be sent if you haven’t resolved the underlying issue.
- If you close an alert that was generated by a monitor when the issue is not fixed, no additional alerts will be sent because alerts from monitors are generated by changes in state.
Since the alert won’t be raised again unless there is a negative change of health state, you have to take care when closing alerts generated by monitors as you may simply hide an issue rather than fix it. For the most part, monitors automatically resolve the alerts that they generate. Having said that, not every monitor will automatically resolve the alerts it generates. Before closing an alert generated by a monitor, check Health Explorer, and verify that the state of the monitored segment has returned to healthy.
You can set multiple resolution states for alerts, and even create your own alert resolution states. Resolution states can have a value between 1 and 254, with the ID of 1 assigned for the New resolution state, and the ID of 255 assigned for the Closed resolution state. Figure 6 shows configuring the resolution state for an alert.
FIGURE 6 Resolution states
You configure additional alert resolution states by performing the following steps:
1. In the Administration workspace of the Operations Manager console, click Settings, click Alerts, and then click Properties in the Tasks pane.
2. On the Alert Resolution States dialog box, shown in Figure 7, click New.
FIGURE 7 Alert resolution states
3. On the Add Alert Resolution State dialog box, provide a resolution state name, and an ID that has not been used.Figure 8 shows the resolution state set to Under Investigation, and a Unique ID set to 100.
FIGURE 8 Add Alert Resolution state
4. The new resolution state will be listed, as shown in Figure 9.
FIGURE 9 Review alert resolution states
Automatic alert resolution
Operations Manager automatically resolves alerts after a certain number of days. The default settings are to automatically resolve all active alerts that are in a new resolution state after 30 days. This automatic resolution only applies to alerts that haven’t had their resolution changed to another resolution state. If, for example, the resolution state had been set to Acknowledged or Scheduled, then the alert will not be automatically resolved.
Automatic alert resolution will also occur in the event that the alert source remains in a healthy state after a specified number of days, with the default being 7 days. To configure Automatic Alert Resolution settings, perform the following steps:
1. In the Administration workspace of the Operations Manager console, click Settings, click Alerts, and on the Tasks pane, click Properties.
2. On the Global Management Group Settings - Alerts dialog box, click the Automatic Alert Resolution tab.
3. Configure the appropriate automatic alert resolution settings on the Global Management Group Settings - Alerts dialog box, as shown in Figure 10.
FIGURE 10 Automatic alert resolution
