CN100456687C - Method and system for real-time correlation analysis of network faults - Google Patents

Abstract

The invention provides a real-time correlation analysis method and system for network faults, belonging to the field of computer network communication. Fault event information from various network devices and business objects is written into the original event list, and the analysis control engine selectively reads events from the original event list according to the original event level and type for correlation analysis, and synthesizes them in the dynamic analysis algorithm Using various domain information such as historical fault analysis scenarios, network dynamic performance parameters, dynamic topology information and event time characteristics, it overcomes the neglect of dynamic network status information, excessive reliance on preset rules and lack of automatic fault correlation analysis methods in the existing fault correlation analysis methods. Insufficient learning ability, etc., can conduct effective correlation analysis on the original event set caused by the fault, and better solve the problem of real-time fault cause analysis and fault location when the network fault storm occurs.

Description

Method and system for real-time correlation analysis of network faults

Technical field

The invention belongs to the field of computer network communication, and in particular relates to a method and system for performing real-time correlation analysis on network failure events based on domain comprehensive information in network management.

Background technique

In computer and communication networks, when a certain device or service fails, a series of network events will be caused due to the close connection between the device, service and business, and the network management system responsible for monitoring the network will send event notifications through the device Or the polling monitoring of the network management system will find a large number of abnormal events, which will be reflected on the management interface of the network administrator through SNMP Trap, Syslog or Indication, thus appearing as a "network failure storm". Because this kind of fault storm often leads to a large number of events in a short period of time, submerging the most fundamental fault events, it is difficult for the administrator to find the real cause of the fault. To solve the fault, it is necessary to analyze the most fundamental fault. The reason is to analyze the correlation between these events and seek the root events. In order to analyze event correlation, the industry has developed several typical methods: such as rule-based analysis (Rule Based Reasoning), model-based analysis (Model-Based Reasoning), analysis based on State Transition Graph (State Transition Graph), code-based CodeBook analysis and case-based analysis (Case-Based Reasoning), these methods can solve the problem of fault correlation analysis to a certain extent, and each has its own advantages. However, none of these methods can completely solve the following problems:

(1) It is impossible to dynamically consider the network topology link information;

(2) All input events are processed without selection, which is difficult to improve efficiency and consumes a lot of resources;

(3) The reasoning process relies too much on preset rules, feature tables or models, lacks automatic learning ability, and lacks the ability to adapt and deal with new situations outside the knowledge base;

(4) Observe the event sequence within a fixed time range, and cannot dynamically change the time range of correlation analysis;

(5) Lack of consideration of conditional probability and time factors in the analysis process;

(6) The network operating parameters obtained in real time cannot be combined in the analysis process based on static information.

Contents of the invention

The present invention provides a method and system for real-time correlation analysis of network fault events based on domain comprehensive information, which overcomes the neglect of dynamic network status information, excessive reliance on preset rules and lack of automatic learning in the existing fault correlation analysis method Insufficient capabilities, etc., can effectively identify key events at the source of faults and locate them in the network.

Technical content of the present invention: a real-time correlation analysis method for network faults, comprising:

(1) The event extraction interface collects various fault events generated in the network and writes them into the original event list;

(2) Read an event from the original event list, perform event matching through historical fault scenario information, and perform real-time detection of network equipment and service operating parameters;

(3) If there is no matching event, select network objects related to the currently processed event based on the information model and topology dependencies for real-time detection, and apply the real-time detection results back to the reasoning process as conditions;

(4) Return to the original event list and continue to search for events related to the current processing event or events that match the real-time detection results, and add the event to the work list;

(5) In the original event list, there are no other events that can be added to the work list, then a new fault scenario is constructed from the events in the work list and added to the historical fault scenario information, and the work list is cleared;

(6) Read the next event that meets the selection strategy from the original event list, return to the second step, if there is no event in the list, then hang up and wait for event input.

The information model described includes:

(1) Object-oriented abstraction of various managed objects in the managed network;

(2) Form a hierarchical information model according to the inheritance relationship between the abstracted managed classes;

(3) In the information model, use the association class to define the relationship between the managed classes. :

The topological dependencies include:

(1) Keep the topology dependency consistent with the actual topology of the network during network operation;

(2) Set the network node where the fault correlation analysis program runs as a reference point;

(3) Calculate the reachability dependencies to other nodes through the reference point.

(4) Utilize the notification of the topology change from the device to trigger the topology synchronization program to recalculate the topology dependency from the latest topology;

The reasoning process includes:

(1) Assign a confidence probability to each step of reasoning, and calculate the probability of the final analysis result by calculating the probability of each step;

(2) Define a time constraint function in fault scenario creation to describe the time characteristics of events and the time relationship between associated events;

(3) Represent and match the alarm content with a formal method.

The historical failure situation information is constructed as a failure situation table for quick query.

The collection of original fault events further includes:

(1) When processing different event types, dynamically change the length of the original event queue according to predetermined rules;

(2) Determine which events are used as the starting point of correlation analysis according to the event level and user-defined rules;

(3) Preprocess the original events, provide an extensible event acquisition interface for fault events of different protocols, convert them into a unified internal format and filter them.

Described construction new failure situation comprises:

(1) Extracting fault characteristic parameters;

(2) Extracting the fault propagation path;

(3) Construct new fault resolution scenarios by using fault characteristic parameters and propagation paths.

A real-time correlation analysis system for network faults, comprising:

Analysis control engine: used to call other modules and interfaces according to the analysis control engine algorithm to complete fault correlation analysis;

Event extraction interface: used to receive various network events sent by network devices, convert the events into a unified format, write the original event list, and call it for the analysis control engine;

Real-time network parameter detection interface: used to detect real-time information such as attributes, performance, and accessibility of various devices and services in the network. It is called by the analysis control engine and accepts the parameters of the fault analysis engine to determine which network device to perform real-time detection , and return the result to the analysis control engine;

Information model: describe a series of management classes corresponding to network protocol objects and device objects, and the interdependence between them;

Information model query interface: a function used to query management classes, management class attributes, and relationship between management classes from the information model, and provide information from the information model for the analysis control engine at runtime;

Topology synchronization module: used to be triggered by network topology change events to run the topology dependency generation algorithm, generate topology dependencies that correctly reflect the current network topology connection relationship and store them in the topology dependency library, which provides relevant information for the analysis control engine ;

Fault scenario table generation module: used to establish a fault scenario on a group of events that have found correlation, and store this scenario in the fault scenario table, and match subsequent events through the fault scenario table.

The information model is stored in the form of a hash table file, and the analysis control engine extracts the information of the information model through the model query interface during the analysis process.

It further includes a preprocessing module: preprocessing the received original event according to a predetermined preprocessing rule.

The technical effect of the present invention: making full use of various dynamic and static information, real-time information and historical information in the network, when the network fails, the key to effectively identify the source of the failure from the complex failure phenomenon and the event storm caused by it events and locate them in the network; in addition, because the topology dependencies synchronized with the actual network topology conditions are applied in the analysis, as well as the network operating parameters obtained in real time, the accuracy of fault location is improved; by analyzing the original input events Preprocessing (including protocol format conversion, filtering and selection) avoids correlation analysis from all input events and improves processing efficiency; using the construction of fault processing history scenario table makes this method self-learning from historical experience ability, and use the scenario table to quickly match events, so that some events can be directly matched in the scenario table, thereby avoiding the correlation analysis of the whole process for all events, and improving the processing efficiency; and because in The application of probabilistic logic, time constraint function, and regular expression fuzzy matching in the analysis algorithm can more flexibly handle the complex relationship between events and improve the applicability of correlation analysis.

Description of drawings

Fig. 1 is the structural representation of network failure real-time correlation analysis system of the present invention;

Fig. 2 is the flow chart of network failure real-time correlation analysis method of the present invention;

Fig. 3 is the topology dependence generating algorithm flow chart of network failure real-time correlation analysis method of the present invention;

Fig. 4 is the network schematic diagram of a specific embodiment of network failure real-time correlation analysis method of the present invention;

Fig. 5 is a schematic diagram of an information model in a specific embodiment of the method for analyzing real-time correlation of network faults according to the present invention.

Detailed ways

Referring to Fig. 1, the present invention takes the analysis control engine as the control module, and implements the network fault by interacting with the information model query interface, event extraction interface and preprocessing module, real-time network parameter detection interface, fault scenario table generation module, and topology synchronization module Real-time correlation analysis. The specific steps are:

1. The event extraction interface uses different protocols (SNMP/SYSLOG, etc.) to extract fault event information from various network devices and business objects, and converts their format into a unified internal format, and then through the event preprocessing module, these The event information is compressed and filtered (according to the preset filter), and written into the original event list; the processing effect can be effectively improved by preprocessing the original event;

2. The analysis control engine selectively reads an event from the original event list according to the original event level and type for correlation analysis; in the analysis process, it comprehensively applies the fault scenario table, information model information, real-time detection information and topology information, and analyzes During the process, events will continue to be read from the original event list as needed to construct an event propagation path until no next matching event can be found;

(1) Construct the historical failure situation information into a failure situation table for quick query. Events can be quickly matched in the scenario table;

(2) Construct an object-oriented hierarchical network information model: perform object-oriented abstraction on managed objects such as hardware, links, software, and network services in the network, and organize them according to the inheritance relationship between these abstracted management classes into A hierarchical information model. In this model, association classes are used to define the relationship among managed classes, such as containment, dependence, and connection. The model is stored in the form of a hash table (Hash) file, which can be accessed through the model object management interface, and is derived by using the hierarchy and interdependence of the management classes defined by the model; a series of corresponding network protocol objects and devices are described in the information model The management classes of objects, and the various relationships between them. The management classes defined in the information model can be divided into three categories: topology sub-model, open service sub-model and network communication sub-model.

The following uses the open service system sub-model as an example to introduce the definition of the management class: the open service system sub-model is mainly used to describe each node device and its internal modules in the data communication network, and it will provide data transmission services or data processing services The network nodes of the network are abstracted into an open service system, and different systems are formed by combining software and hardware in an expandable and tailored manner. The management class is:

a. Open Service System: (Open Service System) represents all systems that provide data services at various levels on the data communication network; including routers, switches or servers;

b. Software (software): the functional modules implemented by software in the open service system;

c. Hardware (hardware): functional modules realized by hardware and firmware in the open service system;

d. Application: various applications, such as mail client;

e. Operating system (os): various real-time and time-sharing operating systems; such as VxWorks, Windows, Unix, Linux, etc.;

f. Resource (resource): basic shared objects in the system: such as memory, disk, CPU, interrupt, etc.;

g. Device: each module that makes up the hardware;

h. Service:

i. Protocol stack (protocol stack):

j. Kernel:

k. Driver:

l. Memory:

m. Hard disk (hard disk):

n. Central processing unit (cpu):

o. Bus (bus):

p. Adapter:

q. Network adapter (network adapter):

u. Controller:

In this information model, there are various dependencies between management classes, such as protocol dependencies, development service dependencies, and so on.

(3) Real-time detection: combine the reasoning process with real-time detection of network equipment and service operating parameters.

(4) Real-time calculation of topology dependencies based on the specified reference point: set the network node where the fault correlation analysis program runs as the reference point, and calculate the reachability dependencies to other nodes on this basis, and perform the calculation during network operation Maintain synchronization with the network topology; topology dependencies describe the physical connections between nodes and are the basis for protocol interoperability and service availability. The reference point refers to the node as the starting point when we consider the accessibility of a node in the topology diagram. In the actual managed network, it is often the node where the network management platform is located, or the network detector. The node location where (software or hardware) resides. Referring to Figure 3, the establishment of dependencies is a recursive algorithm. Every time the topology changes, the automatic operation algorithm will be triggered to update the dependencies and dependencies to ensure the accuracy of current fault location and correlation, so as to achieve the possible correlations that need to be detected in the next step. A collection of network instance objects.

(5) Complete the core logic of the correlation analysis method within the control analysis engine, refer to Figure 2,

a. Read an event Ei (i=1～n) from the list, and use the event to match in the scenario table to see if there is a fault history scenario related to the event (the characteristic event of the fault scenario matches the event ), for each applicable scenario, follow step (b);

b. Call the real-time detection module to perform real-time state detection on the relevant instances of the relevant object classes in the situation (while considering the topologically dependent nodes related to the event generation node) to see whether the returned result meets the characteristic scope of the situation description; and then Then go to the original event list to search for subsequent events generated by relevant instances to see if they conform to the characteristics of the scenario definition; if the above checks pass, then mark these related events and call the output module to format and output the analysis results;

c. If the detection in (b) does not match, call the model query interface to query the management class corresponding to the object that generated the event in the network information model; at the same time, consider the topologically dependent nodes related to the node that generated the event, and get the following A collection of potentially related network instance objects that need to be detected in one step;

d. Call the real-time detection module to detect whether the current state of these objects conforms to the characteristic range described by the relationship defined in the galaxy model, and then check whether there are related events sent by these objects in the original event list, and if so, add these events to Go to the work event list, go to step (e); if the above detection fails, then check whether the work event list is empty, if it is empty, go to step (e) if it is not empty, then call the fault scenario construction module to construct a new one for these events The failure scenario is added to the failure scenario table, and the work event list is cleared; then these events are marked and removed and the output analysis results are formatted, and then step (e);

e. Read the next event that meets the selection strategy from the original event list, then go to step (a), if there is no event in the list, then hang up and wait for event input;

Among them, the reasoning process of matching and real-time state detection mentioned in the above steps includes: rule-based reasoning based on probability: assign a confidence probability to each step of reasoning, and obtain the probability of the final analysis result by calculating the probability of each step; Handling of constraint factors: Define time constraint functions in fault scenario creation to describe the time characteristics of events and the time relationship between associated events; use regular expressions to perform fuzzy matching of alarm content.

3. After completing one pass of correlation analysis (complete scanning of all events in the current event list), construct fault scenarios for the events associated together in this pass analysis and add them to the fault scenario table, and then remove these events from the original event list And construct the output analysis results;

4. While performing the above work with the analysis control engine, the event collection module (including the event collection interface and event preprocessing module) is also synchronously writing new events to the original event list, and the topology synchronization module is also monitoring When the network topology changes, refresh the network topology dependency library at any time; if there are no events in the original event list, the analysis control engine will hang, waiting for new events to be written; the event preprocessing module writes new events into the original event list , if the analysis control engine is found to be hung, the process will be woken up.

Specifically using a local area network as an example, refer to Figure 4, where A, C, and D are hosts running the Linux operating system in the local area network, S is a three-layer switch, and R is a router connecting the local area network and the Web server. Gateway for this LAN. A and C are directly connected to S, and D is directly connected to R. RP is a PC running Windows, and it is also a reference point for us to perform correlation analysis. The correlation analysis system runs on this host.

First, with reference to Fig. 5, this embodiment adopts a simplified information model, in this network: host A, C, D, RP, router R, switch S can all be regarded as the open service system, each open service system Contains a protocol stack, which is responsible for completing the communication between the application and other peer entities in other open service systems on the network. Data flows downward through applications, operating systems, protocols, and interfaces, then enters the physical network, passes through layer-2 forwarding and layer-3 routing to another open service system, and passes through interfaces, protocols, and operating systems upwards to the application at the other end.

1) Information model instantiation

The above model will generate some instances corresponding to the above model entities in the actual network environment: such as the application on the router R, we will name it Application_R, and the operating system on R, named:

OS_R,

By analogy, we get other instances: Protocols_R, Interface_R;

same:

For host A, we get Application_A, Service_A, OS_A, Protocols_A, Interface_A;

For host C, we get Application_C, Service_B, OS_C, Protocols_C, Interface_C;

For host D, we get Application_D, Service_D, OS_D, Protocols_D, Interface_D;

And there are the following dependencies:

Application->Service;

Service->OS;

OS->Protocols;

Protocols->Interface; (note: this is a simplified model);

Assume that web_browse_in_url->DNS service is defined in the model;

X.interface.fail is equivalent to X.down;

2) Topological dependency generation

For the network shown in Figure 4, the network management platform will obtain its topology data through automatic discovery, and then run the topology dependency generation algorithm (with RP as the reference point) to obtain the following topology dependency set:

RD={A->S, C->S, S->R, D->R, Internet->R, R->RP}

Among them: the meaning of 'X->Y' can be interpreted as "to access X, you must first pass through Y";

R->RP indicates that R is a network node directly connected to the reference point RP;

When the network topology or reference point changes, the algorithm automatically updates the dependencies so that the dependencies can reflect the actual network operation status.

3) The event extraction interface starts to receive various events generated in the network.

Suppose a DNS service is running on host A (it can be regarded as a service), and there is a program on host D that is constantly accessing the home page www.harbournetworks.com on the web server, which can be regarded as an Application, we Name it web_browse_in_url.

Assume that at a certain moment, the event extraction interface receives the following events from the SNMP agents of each host, and the events are formatted as follows:

{

E0＝RP.ping.S.fail:t0, indicating that the switch S cannot be pinged from the RP at time t0,

E1=RP.ping.C.fail:t1, which means that the host C cannot be pinged from the RP at time t1,

E2=RP.ping.C.fail:t2, which means that the host C cannot be pinged from the RP at time t2,

E3=D.web_browse_in_url.Web_Server.fail: t3 indicates that the host D cannot access the Web server at time t3.

E4=RP.ping.A.fail:t4, which means that the host A cannot be pinged from the RP at time t4,

E5＝RP.ping.A.fail:t5, means that the host A cannot be pinged from the RP at time t5,

E6＝R.down:t6, means that R is invalid at time t6,

E7=RP.web_browse_in_url.web_server.fail: t7 indicates that the host RP cannot access the Web server at time t7.

E8=R.up:t8, means that R resumes work at t8 moment,

}

4) E0...E4 is then sent to the preprocessing module for processing, and the compressed original event set is obtained. Note that repeated events (E2, E5) and paired events (E6, E8) whose fault status has been resolved are filtered here;

{

E0＝RP.ping.S.fail:t0, indicating that the switch S cannot be pinged from the RP at time t0,

E1=RP.ping.C.fail:t1, which means that the host C cannot be pinged from the RP at time t1,

E3=D.web_browse_in_url.Web_server.fail: t3 indicates that the host D cannot access the Web server at time t3.

E4=RP.ping.A.fail:t4, which means that the host A cannot be pinged from the RP at time t4,

E7=RP.web_browse_in_url.Web_Server.fail: t7 indicates that the host RP cannot access the Web server at time t7.

}

5) Real-time correlation analysis of fault events in the communication network by using comprehensive domain information:

(a) The analysis control engine reads an event from the original event list: E0=RP.ping_S.fail:t0;

parsed out of

Node objects: source node RP, destination node S,

Application object: RP.ping, ping belongs to Applications;

Application object status: fail;

Mark E0 and add it to the work event list;

(b) Open and inquire about whether there are relevant scenarios with RP, S, and ping in the scenario table, and find that the scenario table is empty (the system is initialized for the first time, and no new scenarios have been added), and close the scenario table;

(c) Call the information model query interface, query ping (Application), and get the relationship: Applications->Services, Services->Protocols, Protocols->Interface; then query the topology dependency library, get R->RP, S->R ;

(d) Call the network status real-time detection interface, check the S.Interface, and find that the S.Interface status is fail, then the following results can be deduced according to the dependencies:

S.Interface.fail == S.down;

S.down=>A.down and C.down;

A.down＝＝A.Interface.fail＝>A.application.fail and A.services.fail

C.down==C.Interface.fail=>C.application.fail and C.services.fail;

A.services.fail=>A.DNS.fail=>*.browse_web_in_url.fail

(e) Check the raw event list starting from E1. read E1

E1 = RP.ping.C.fail:t1, parsed from

Node objects: source node RP, destination node C,

Application object: RP.ping, ping belongs to Applications;

Application object status: fail;

Ping belongs to the application, which requires RP and C, as well as topology-dependent S, applications, services, protocols, and interfaces on R to remain normal, then S.down and C.down can launch E1, so E1 is associated, and the analysis engine Mark and add E1 to the list of work events;

Read on to read E3:

E3＝D.web_browse_in_url.Web_server.fail: t3 parses and gets:

Node object: D, Web_server;

Application object: web_browse_in_url;

Application object status: fail;

According to the above: A.services.fail=>A.DNS.fail=>*.browse_web_in_url.fail, it can be concluded that E3 is also a related event of E1, so E3 is marked and added to the work event list.

Similarly, it can be analyzed that both E4 and E7 are related events of E1, so the event is marked and added to the work list.

(f) find that there is no unmarked event in the original event list, then call the output module to format the original event list:

Output warning:

Alarm1＝

{

Cause:RP.ping.S.fail:t0

Affects:

[

RP.ping.C.fail:t1

D.web_browse_in_url.Web_server.fail:t3

RP.ping.A.fail:t4

RP.web_browse_in_url.Web_Server.fail:t7

]

}

(g) Construct a new fault resolution scenario Scene1 for these events by using fault characteristic parameters and fault propagation paths: S.down=>{A.down and C.down and*.web_browse_in_url.fail} and add it to the fault scenario table.

(h) Empty the job event list; remove these events from the original event list.

(j) If a new event is added to the original event engine at this time, then turn to (3), otherwise hang up and wait for new event input;

(k) Suppose a new event arrives:

E9=D.web_browse_in_url.Web_Server.fail:t9

E10=A.down:t10;

(1) The event analysis engine reads E9, queries in the event scenario table, and finds that there is an event feature pattern of *.web_browse_in_url.fail in Scene1 that matches it, and adds E9 to the work event list, and continues to view the original event list Is there any feature event in: A.down and C.down, read E10, meet A.down, add E10 to the work event list; at this time there are no other events in the list, and there is still a feature C.down that needs to be After confirming, the real-time detection interface is called, and the detection finds: C.down=true; then the scenario is matched, and the result S.down is obtained directly. The following steps are the same as described in (1).

In the previous step, if the real-time detection result of C is C.down=false; then the above scenario cannot be completely trusted, and a confidence probability can be given. Indicates that there may be other reasons.

Through the use of domain comprehensive information, including management object level information and mutual relations based on network information model, automatically learned fault handling history information, real-time collected network operating parameters, network dynamic topology information, event time characteristics, etc., and in the reasoning process By using the dynamic analysis method, the problem of fault correlation analysis in the complex network environment is better solved.

With reference to Fig. 1, the network failure real-time correlation analysis system of the present invention comprises:

Analysis control engine: the main control logic executor of the analysis process, used to call other modules and interfaces according to the analysis control engine algorithm to complete the fault correlation analysis;

Information model: describes a series of management classes corresponding to network protocol objects and device objects, and various relationships between them. The management classes defined in the information model can be divided into topology sub-model, open service sub-model and network Three categories of communication sub-models;

Information model query interface: a function used to query management classes, management class attributes, and relationship between management classes from the information model, and provide information from the information model for the analysis control engine at runtime;

Event extraction interface: used to receive various network events sent by network devices, including event notifications of various protocols such as SNMPTRAP, SYSLOG, CMIP Event Report, etc., convert the events into a unified format, and send them to the preprocessing module;

Preprocessing module: used for simple filtering of received original events (removing events that managers do not need to care about according to set rules), compression (removing duplicate events), redefinition (resetting one or more events Defined as a new event) and other pre-processing, which is conducive to correlation analysis;

Real-time network parameter detection interface: used to detect real-time information such as attributes, performance, and accessibility of various devices and services in the network. It is called by the fault analysis engine and accepts the parameters of the fault analysis engine to determine which network device to perform real-time detection on. , and return the result to the fault analysis engine;

Fault scenario table generation module: used to create a fault scenario based on a group of events that have found correlation, and store this scenario in the fault scenario table. These established fault scenarios are used for subsequent analysis and quick search. The established fault scenarios It can be quickly found and used for subsequent analysis;

Topology synchronization module: used to be triggered by network topology change events to run the topology dependency generation algorithm, generate topology dependencies that correctly reflect the current network topology connection relationship, and store them in the topology dependency library for fault correlation analysis.

Claims (10)

1. A real-time correlation analysis method for network faults, comprising: (1) The event extraction interface collects various fault events generated in the network and writes them into the original event list; (2) Read an event from the original event list, perform event matching through historical fault scenario information, and perform real-time detection of network equipment and service operating parameters; (3) If there is no matching event, select network objects related to the currently processed event based on the information model and topology dependencies for real-time detection, and apply the real-time detection results back to the reasoning process as conditions; (4) Return to the original event list and continue to search for events related to the current processing event or events that match the real-time detection results, and add the event to the work list; (5) In the original event list, there are no other events that can be added to the work list, then a new fault scenario is constructed from the events in the work list and added to the historical fault scenario information, and the work list is cleared; (6) Read the next event that meets the selection strategy from the original event list, return to step (2), if there is no event in the list, then hang up and wait for event input. 2. the network failure real-time correlation analysis method as claimed in claim 1, is characterized in that described information model comprises: (1) Object-oriented abstraction of various managed objects in the managed network; (2) Form a hierarchical information model according to the inheritance relationship between the abstracted managed classes; (3) In the information model, use the association class to define the relationship between the managed classes. 3. The network failure real-time correlation analysis method as claimed in claim 1 or 2, wherein said topology dependency comprises: (1) Keep the topology dependency consistent with the actual topology of the network during network operation; (2) Set the network node where the fault correlation analysis program runs as a reference point; (3) Calculate the reachability dependencies to other nodes through the reference point; (4) Using the topology change notification from the device to trigger the topology synchronization program to recalculate the topology dependency from the latest topology. 4. the network failure real-time correlation analysis method as claimed in claim 1, is characterized in that described reasoning process comprises: (1) Assign a confidence probability to each step of reasoning, and calculate the probability of the final analysis result by calculating the probability of each step; (2) Define a time constraint function in fault scenario creation to describe the time characteristics of events and the time relationship between associated events; (3) Represent and match the alarm content with a formal method. 5. The real-time correlation analysis method for network faults according to claim 1, characterized in that the historical fault scenario information is constructed as a fault scenario table for quick query. 6. the network failure real-time correlation analysis method as claimed in claim 1, is characterized in that described step (1) further comprises: (1-1) When processing different event types, dynamically change the length of the original event queue according to predetermined rules; (1-2) Determine which events are used as the starting point of correlation analysis according to the event level and user-defined rules; (1-3) Preprocess the original events, provide an extensible event acquisition interface for fault events of different protocols, convert them into a unified internal format and filter them. 7. The network fault real-time correlation analysis method as claimed in claim 1, is characterized in that the new fault scenario of said construction comprises: (1) Extracting fault characteristic parameters; (2) Extracting the fault propagation path; (3) Construct new fault resolution scenarios by using fault characteristic parameters and propagation paths. 8. A real-time correlation analysis system for network faults, comprising: Analysis control engine: used to call other modules and interfaces according to the analysis control engine algorithm to complete fault correlation analysis; Event extraction interface: used to receive various network events sent by network devices, convert the events into a unified format, and write them into the original event list for calling by the analysis control engine; Real-time network parameter detection interface: used to detect real-time information such as attributes, performance, and accessibility of various devices and services in the network. It is called by the analysis control engine and accepts the parameters of the fault analysis engine to determine which network device to perform real-time detection , and return the result to the analysis control engine; Information model: describe a series of management classes corresponding to network protocol objects and device objects, and the interdependence between them; Information model query interface: a function used to query management classes, management class attributes and relationships between management classes from the information model, and provide information from the information model for the analysis control engine at runtime; Topology synchronization module: used to be triggered by network topology change events to run the topology dependency generation algorithm, generate topology dependencies that correctly reflect the current network topology connection relationship and store them in the topology dependency library, which provides relevant information for the analysis control engine ; Fault scenario table generation module: used to create a fault scenario based on a group of events that have found correlation, and store this scenario in the fault scenario table, and match subsequent events through the fault scenario table. 9. The network fault real-time correlation analysis system according to claim 8, wherein the information model is stored in a hash table file, and the analysis control engine extracts the information of the information model through the model query interface during the analysis process. 10. The network fault real-time correlation analysis system according to claim 8 or 9, further comprising a pre-processing module: pre-processing the received original events according to predetermined pre-processing rules.

Images