5.3  Automatic Analysis

Automatic analysis is the immediate analysis of an event that has been captured and decomposed by SEA as soon as the event is generated by the system (or shortly thereafter), regardless of any interfaces that may be running. No user intervention is required. Automatic analysis is always enabled while the Director is running. The Director is always running unless it is manually stopped or, during installation, you chose not to start the Director when the system is rebooted (Tru64 UNIX, HP-UX, Linux, or OpenVMS systems).

Problem reports resulting from automatic analysis are sent to all interfaces and to all recipients that are set up to be notified.

See Chapter 8 for information about setting up notification services.

5.3.1  Scavenge

Automatic analysis processes events as they occur. However, when the Director is stopped, SEA indicates the last event from the binary log file that was processed in the analysis database. When the system is restarted, SEA checks the database to see which events have been processed and processes all the events that occurred after that point. This operation is referred to as scavenging. The scavenge operation finds events that are still pending processing and ensures that no events are missed, even when the system is restarted. The first time scavenge occurs, it processes the entire event log. Once this is complete, new events are processed as they occur. The scavenge operation occurs four minutes after the Director is started. If the Director is started and stopped within four minutes, no scavenge occurs.

Initially, the entire system event log is read to find any events that can be analyzed. A filter is then applied to the analyzable events. All analyzable events that occurred within a week of the current time are processed.

If there are no analyzable events, the scavenge feature becomes dormant and a marker representing an unsupported system is stored in the automatic analysis database. As long as the unsupported system marker is present on the system, no scavenging occurs. If there is at least one recognized event, scavenging occurs every time the Director is stopped and started

Scavenging and the Web Interface

If you connect to the Web Interface before scavenging begins, events that arrive while the Web Interface is running will appear in the Real-Time Monitoring view. All the events that arrive before scavenging starts are processed once scavenging begins and any problem reports that result from scavenging also appear in the Real-Time Monitoring view. However, any events that were added to the event log before the Web Interface was started will not appear in the Real-Time Monitoring view.

5.3.2  Reset

Note


Resetting the automatic analysis results may significantly impact the results of future analysis.


You can use the command line interface to reset the automatic analysis database. Resetting the database erases the current callouts and any analysis data stored. Only the following information is retained:

To reset the database, stop the Director (see Section 1.8 for more information) and then use the reset command (only available in the new common syntax):

wsea reset

Once you have reset the database, restart the Director (see Section 1.7 for more information).

Impact of Resetting the Analysis Database

Be aware that resetting the analysis database clears both the active problem reports and all the storage units maintained by SEA. Storage units are records of past events that are used by some rules for thresholding and multiple event analysis. Hence, after a reset, analysis results may be significantly different than they otherwise would have been in the absence of a reset.

For example, if SEA had an accumulation of storage units that would count toward satisfaction of a threshold filter, resetting the database would erase these units. As a result, one or more problem reports that depend on thresholding filters could be delayed or completely suppressed. This type of issue most typically arises with correctable events. Whereas uncorrectable faults generally are reported immediately, correctable events such as intermittent disk read errors may be subject to threshold filtering. After a certain number of correctable events within a specified time-frame occur, a problem report can be generated to signal that a device is suspect, regardless the fact that it continues to function normally.

The best way to minimize the impact is to only use the reset command after carefully reviewing the recent events (reviewing the events from the last 24 hours is recommended as a minimum). During the review, look for recurring events, typically correctable errors, that involve any device that has not been called out in the problem reports. These events should help determine if any other devices on the system are suspect.

5.3.3  Disable

If necessary, automatic analysis can be disabled from the CLI as described in Chapter 3. You may want to disable automatic analysis if SEA is running on a platform such as HP-UX or Linux, where the native error log is not currently analyzed.