AppManager performance and availability information cannot remain available indefinitely. In addition, displaying too much information in the Operator Console can impede system performance. AppManager repository preferences therefore can help you determine how long to keep event information and set options for archiving events. In addition to repository preferences, you can also set event-handling properties for jobs. For more information about configuring job event settings, see Using Advanced Event-handling Properties.
To help consolidate events and simplify the information displayed in the Operator Console, by default, AppManager collapses duplicate events (events with the same object name, event message, severity, job ID) into a single event. For example, after an event is raised instead of creating new child event entries, duplicate events, associated with the same computer, job, and event condition, are collapsed into the original child event and the child event count is increased.
AppManager collapses duplicate events within a specified time interval (20 minutes by default). You can configure this time interval to begin:
When the first event is raised. All duplicate events within the time interval (static period of time) are collapsed into one event.
Each time an event is generated (it is not a static period of time). For example, using the default time of 20 minutes, if a job generates duplicate events every 5 minutes, the 20 minute interval is restarted every 5 minutes, meaning it never effectively expires — unless you set an option for AppManager to ignore events.
After the original child event is closed, or after the event collapsing time interval expires, a new child event is created if the event condition is detected.
In addition, when event collapsing is enabled and a duplicate event is raised for an event you previously acknowledged, by default AppManager changes the status of the acknowledged event to open and increments the event counter. In most cases, this default behavior is appropriate, giving you visibility that even though an event has been acknowledged by an operator it hasn’t been closed and the case should be re-opened to resolve the problem. In some cases, however, you may want to leave an acknowledged event in the acknowledged state to indicate someone has responded to the problem but still be notified that the event condition has extended beyond the event collapsing interval. You can choose one of the following AppManager preferences to control this behavior:
If you want to see a new open child event when the event condition persists beyond the event collapsing window for an acknowledged event, use the Create a new child event for acknowledged event during event collapsing preference.
If you want to increment the child event count only when the event condition persists beyond the event collapsing window for an acknowledged event, leaving the status of the acknowledge event unchanged, use the Increment the event count only without changing status event during event collapsing preference.
You can change the way AppManager displays event information for duplicate events that are raised (and collapsed) after you acknowledge an event.
NOTE:These options are not available in the Control Center console, though how you set these options in the Operator Console also affect how the Control Center console displays event data.
To change the handling of duplicate events when event collapsing is enabled:
Click File > Preferences in the Operator Console.
Click the Repository tab, then click Event in the Event options group.
Click the event handling preference you want to use.
Click Create a new child event for acknowledged event during event collapsing if you want AppManager to create a new child event and sets the status of the event to open.
Click Increment the event count only without changing status event during event collapsing if you want to leave the status of an event as acknowledged but also to increment the event count to indicate there has been a new occurrence of the event.
By default, AppManager keeps event information available for display in the TreeView pane, Events tab, and Message tab indefinitely. Over time, events can accumulate in the Operator Console, which can affect the performance of the Operator Console, or they can become out-of-sync with your jobs. For example, if you delete jobs but not their associated events, your Events list will include events for which no job information is available. While this may not be a problem if you manage a small number of jobs and events, it can become a problem when the number of jobs and events increases. Managing the list of events and identifying useful and relevant events can become increasingly difficult.
To prevent this situation, in most cases you should plan to remove events when you delete the associated jobs. AppManager provides a repository preference to help you manage event information for deleted jobs.
NOTE:This option is not available in the Control Center console, though how you set this option in the Operator Console also determines whether or not events are deleted when deleting jobs in the Control Center console.
To delete all event information when a job is deleted in the Operator Console:
Click File > Preferences in the Operator Console.
Click the Repository tab, then click Event in the Event options group.
Click Remove associated events when jobs are deleted.
When you delete a job in the Operator Console, AppManager removes the associated event information from the AppManager repository. However, if you archive events, this information is still available in the event archive tables in the repository.
NOTE:If you do not remove events when jobs are deleted, you should periodically remove events from the repository manually. If you do not remove them, these “orphan” events without jobs associated with them will consume database resources and may impact performance. For information about removing events from the repository, see Removing Events.
Click OK in the Preference - Event Options dialog box, then click OK in the Preferences dialog box.
To respond to an open event and turn off the event alert, you need to either acknowledge or close the event. How you respond to an event and use the Acknowledge or Closed status depends on your system management policies. For example, you might immediately acknowledge the event, check the server, and try to solve the problem, or you might acknowledge the event and run other Knowledge Scripts to collect data or to further diagnose the problem.
Acknowledging the event turns off the event alert and changes the status of the event in the Events tab to “Ack.” When you have resolved the problem that caused an event, you can then close the event. You do not need to acknowledge an event before closing it. However, to prevent accidental deletion of open or unresolved events, you must close an event before you can delete it.
To acknowledge or close events, you can:
Individually acknowledge or close child events in the Events tab (or acknowledge or close all child events at once by acknowledging or closing a parent event).
Acknowledge or close all events associated with an application server, a group of servers, or all servers in a view in the TreeView pane.
Individually acknowledge or close an event after viewing detailed information in the Message tab in the Event Properties dialog box.
AppManager also provides a repository preference to automatically close events based on their severity level. This preference can be useful when:
You want to save historic information about an informational or diagnostic event but do not want to manage event status.
You want to know that an event occurred, but you don’t need to address the issue right away. You would therefore would like to automatically close, but not delete, the event.
For example, if you are raising an event when a condition no longer exists and you receive an informational event indicating that the condition ended, you may want to automatically dismiss (close but not delete) this type of event.
NOTE:This option is not available in the Control Center console, though how you set this option in the Operator Console also determines whether or not events with a specified severity are closed in the Control Center console.
To automatically close events:
Click File > Preferences in the Operator Console.
Click the Repository tab, then click Event in the Event options group.
Click Automatically close event when severity is greater than N.
NOTE:Use caution when setting this preference. Depending on the value you set for this preference, you can accidentally acknowledge and close other events. NetIQ Corporation recommends setting a unique severity level for this preference (for example, a special value you do not typically use, such as 40) and if you have other Knowledge Scripts using this severity level, set their event severity level to another value, such as 39.
Click OK in the Preference - Event Options dialog box, then click OK in the Preferences dialog box.