In addition to the repository preferences for event handling and archiving, AppManager provides preferences to specify how jobs generate events. You can set these preferences for individual jobs by clicking the Advanced tab in the Knowledge Script Properties dialog box. Or you can set the default behavior for these preferences by modifying Advanced Properties repository preferences. These advanced properties for jobs and events specify preferences for:
NOTE:Any default values you set for how the Operator Console generates events will not apply to the Control Center console. As a result, if you open the same Knowledge Script in both the Operator Console and Control Center console, the default values on the Advanced tab of the Knowledge Script Properties dialog box may not be the same. If you are going to create jobs from the same Knowledge Script in both the Operator Console and the Control Center console, be sure any settings on the Advanced tab of the Knowledge Script Properties dialog box are the same in both consoles.
When you run a Knowledge Script and raise events, AppManager creates both a parent and child event for the first occurrence of the event condition. For subsequent occurrences, AppManager creates additional child events under the parent event and updates an event counter indicating the number of child events.
To change the default behavior for collapsing duplicate events:
Select File > Preferences in the Operator Console.
Click the Repository tab, and click Advanced Properties in the Knowledge Script options group.
Click Collapse duplicate events into a single event.
Set the time interval for collapsing duplicate events in the Time interval for event collapsing field.
Click Initial occurrence to indicate that you want to use a static period of time to regulate event collapsing.
Click OK in the Preference - Knowledge Script Advanced Options dialog box. Then click OK in the Preferences dialog box.
NetIQ Corporation recommends using event collapsing and selectively setting the number of consecutive occurrences. When setting an event collapsing interval, keep the following in mind:
The schedule interval must be set to at least 10 minutes.
If the schedule interval is shorter than the collapsing interval and the job detects an event every interval, new identical events are collapsed into the same child event.
If the job schedule is longer than the collapsing interval, you will see multiple child events even though the events are identical.
If you set the number of consecutive occurrences to a value greater than 1, be sure to consider the time schedule interval. For example, if a job runs once every 12 hours and you set the number of consecutive occurrences to 3, you won’t be notified of the event until the third occurrence — 36 hours later.
Child events accumulate in the database. Try to strike a reasonable balance between timely notification and eliminating trivial or redundant events.
If you only want to receive an event if a condition crosses a threshold a certain number of times, you can specify the number of times a consecutive duplicate event (events with the same object name, event message, severity, job ID) must occur before AppManager generates an event message. Using this approach you can hide trivial spikes that can occur when a Knowledge Script runs at frequent intervals. Events triggered by these temporary spikes are not always useful and your operations or administrative staff can spend vital time responding to events for conditions that do not cause any disruption to your environment.
For example, say you are monitoring CPU and it hits 99%. You might not consider this a problem because you know the system has a heavy processing load, or because this represents an uncharacteristic spike in the activity while the system is performing a specific processing task. In this case, you might not want to receive an event message. However, if CPU is at 99% for 10 minutes, you might have a problem.
By default, AppManager alerts you every time CPU crosses the threshold you specify. You have two options for changing this:
Set the number of times you want the condition to occur and the number of iterations for the job in the Raise event if condition occurs N times within N job iterations field on the Advanced tab in the Knowledge Script Properties dialog box for individual jobs.
Change the default behavior by setting the Advanced Properties repository preference. See the instructions below.
For this example, you might specify that you want to receive an event only if CPU is over 99% 10 times in 2 job iterations.
NOTE:Typically, the more frequently the job is scheduled to run, the higher you can set the number of consecutive intervals before raising an event. NetIQ Corporation recommends setting this preference in the range of 3 to 5 occurrences for volatile performance statistics.
To change the default behavior for consecutive intervals:
Select File > Preferences in the Operator Console.
Click the Repository tab, and then click Advanced Properties in the Knowledge Script options group.
Specify the number of times you want the condition to occur and the number of iterations for the job in the Raise event if condition occurs N times within N job iterations field.
Click OK in the Preference - Knowledge Script Advanced Options dialog box. Then click OK in the Preferences dialog box.
For some event conditions, it is useful to raise an event when the condition is first detected and then raise a second event when the condition no longer exists. For example, you can use this option if you want to be automatically notified when a problem that raised an event has gone away.
To illustrate, suppose you want to receive a severity 5 event when CPU utilization reaches 99% and then an informational event message with a severity level of 35 when CPU utilization returns to 10%. In this case, you have two options:
You can select Generate a new event when original event condition no longer exists and specify a severity level (for example, 35) in Severity of new event on the Advanced tab in the Knowledge Script Properties dialog box for an individual job.
You can change the default behavior by setting the Advanced Properties repository preference. See below for instructions.
You can also select Automatically close original event to close the original severity 5 event when CPU utilization falls below the threshold you set.
For example, if a job detects that physical memory usage has exceeded the threshold you set, AppManager raises an event. This event condition continues until memory usage falls below the threshold. Because at this point the original event condition no longer exists, AppManager automatically closes the original event and raises a new informational event with a severity you have specified.
NOTE:In general, you should set the severity level for the informational event to a unique or rarely-used severity and use a severity level that is clearly distinguishable from the original event.
To change the default behavior for raising events when an original event condition no longer exists:
Select File > Preferences in the Operator Console.
Click the Repository tab, and then click Advanced Properties in the Knowledge Script options group.
Click Generate a new event when original event condition no longer exists and specify a severity level in Severity of new event.
Click Automatically close original event.
Click OK in the Preference - Knowledge Script Advanced Options dialog box, then click OK in the Preferences dialog box.