Electrical computers and digital processing systems: multicomput – Computer conferencing – Demand based messaging
Reexamination Certificate
1997-12-02
2001-01-30
Rinehart, Mark H. (Department: 2756)
Electrical computers and digital processing systems: multicomput
Computer conferencing
Demand based messaging
C709S218000, C709S202000, C707S793000
Reexamination Certificate
active
06182119
ABSTRACT:
FIELD OF THE INVENTION
The present invention relates to network management systems, and more particularly, to a method and apparatus for identifying important information among the total information collected by network management systems.
BACKGROUND OF THE INVENTION
Network management systems often have access to enormous amounts of data about the networks that they manage. Such data includes, for example, “syslog” messages generated by routers, and Management Information Base variables (“MIB variables”) received in response to polling the various devices on the networks.
Typically, this data is stored in the form of log files. Because of the volume of data available to network management systems, it is relatively easy for important pieces of information (“key information”) to go undetected, effectively lost deep inside a log file. For example, among the “syslog” messages generated by a router, there may be a single “configuration change” message hidden among thousands of relatively unimportant “link-up” and “link-down” messages. Detection of such a configuration change message may be the key to determining why a particular section of the network ceased to function properly.
The volume of collected data is such that it is not practical for network administrators to manually sift through the log files on a real-time basis to uncover key information. Consequently, attempts have been made to automate the discovery of key information. One such attempt involves the ad-hoc creation of shell or PERL scripts. Such scripts may be coded to read the log files searching for data that has certain characteristics. If data that satisfies the programmed criteria of a script is detected by the script, the script performs some predefined action.
Alternatively, complex analytical tools may be used to sift through the log files. For even basic filtering, such tools often require the use of relatively complex inference engines, event forwarding discriminators, and/or complex correlation codebooks.
One disadvantage of both the script approach and the analytical tool approach is that they do not provide real-time feedback. Thus, important information remains undetected until a detection tool is executed. For example, if a script file begins executing at time T
10
, it may take until time T
20
before the script indicates that key information was received at time T
1
. Similarly, an analytical tool executed at time T
10
may discover at time T
20
the key information received at time T
1
. Such delays in detection are unacceptable in situations where it is critical to immediately act upon key information.
Another approach to detecting key information is to analyze the information in real-time as it arrives from one or more sources. Such sources could include, for example, a socket, a log file or a log file reader. Programs that perform such real-time analysis are referred to as filtering systems.
One problem with typical filtering systems is that they are inflexible with respect to the type of key information they detect, and the data sources with which they work. For example, a typical filtering system is delivered pre-compiled with filters, actions and source modules, as well as the connections between the various modules, already in place. Because the filters, actions and source modules and connections are effectively hard-coded, a user cannot adjust the operation of the filtering systems in response to changes. Changes that may require behavioral or connection changes in filtering systems may include, for example, changes in (1) which information is considered key information and (2) the number and type of sources supplying the information and (3) the number and type of actions to be triggered upon receipt of information that is considered key.
Based on the foregoing, it is clearly desirable to provide a mechanism for detecting and acting upon key information supplied by one or more sources. It is further desirable to provide a mechanism that is flexible enough to be adapted to the changing needs and configurations of the system in which it is employed.
SUMMARY OF THE INVENTION
A method and system for filtering and acting upon data are provided. The specific identity, behavior and relationship between the various components that make up the system are not fixed at compile time. Rather, flexibility is maintained by establishing the identity, behavior and relationships based on configuration data at run time.
According to one aspect of the invention, the configuration data specifies a set of source modules, a set of filter modules, a set of action modules, and publisher-subscriber relationships between the source modules, filter modules, and action modules. At run time, the various modules specified in the configuration data are loaded into dynamic memory and initialized. The publisher-subscriber relationships are then established between the loaded modules based on the configuration data. The source modules then begin execution.
According to another aspect of the invention, the behavior of the various components is determined by arguments passed to the components when they are initialized. A user interface is provided which allows a user to specify changes to the publisher-subscriber relationships between the components, or to the initialization arguments of the components. In response to user input that specifies changes publisher-subscriber relationships, subscriber lists maintained by the components are changed. In response to user input that specifies changes to initialization arguments, the components are re-initialized with the new arguments.
According to one embodiment, the various components are implemented as objects that are instances of JAVA classes. After being loaded and initialized, the source objects are launched to begin execution in their own threads. The filter and action objects execute when invoked by objects, such as source objects and other filter objects, that are executing.
REFERENCES:
patent: 5857190 (1999-01-01), Brown
patent: 5867799 (1999-02-01), Lang et al.
Hood et al., “Proactive Network Fault Detection”, IEEE Communications Conference, Apr. 12, 1997.
Thottan et al., “Adaptive Thresholding for Proactive Network Problem Detection”, IEEE Conference, 1998.
Cisco Technology Inc.
Hickman Palermo & Truong & Becker LLP
Rinehart Mark H.
Thompson Marc D.
LandOfFree
Dynamically configurable filtered dispatch notification system does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Dynamically configurable filtered dispatch notification system, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Dynamically configurable filtered dispatch notification system will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2517383