JP2001007892A - Network management method and network management system - Google Patents

Abstract

PROBLEM TO BE SOLVED: To inform a system manager efficiently about the repetitive occurrence of a slight or a warning symptom. SOLUTION: A symptom generating state section 21 classifies an occurrence state of symptoms into (A) a symptom abnormality state (symptoms take place at a specified frequency or over), (B) symptom consecutive occurrence state (symptoms take place at a specified frequency or less), and (C) symptom non-occurrence state (no symptom takes place). A symptom occurrence state notice section 22 informs the system management about the transition of the states above depending on occurrence and restoration of bubbling symptoms and occurrence and restoration of continuing symptoms. Thus, the state of symptoms taking place repetitively can efficiently be informed.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a network management system for managing faults on a network, and more particularly to a network management system having a function of detecting a state where a fault event has repeatedly occurred.

[0002]

2. Description of the Related Art Communication networks using computers have been increasing in scale. As communication networks have become larger, the effects of failures occurring on the networks have become larger and more serious. for that reason,
It is very important how to manage the network efficiently.

In order to perform such management, for example, a network management system is composed of a manager function (a side to be notified of a failure) and an agent function (a side to notify a failure). Japanese Patent Application Laid-Open No. H6-175887 uses an alarm notification function as a means for reporting a failure that has occurred on the agent side to a manager function.

[0004] The failures that occur on the agent side are classified into serious ones that should be reported immediately, minor ones that can recover from failures as a result of recovery processing or retry, or warnings.

[0005] Serious failures must be reported immediately. On the other hand, minor or warning failures show signs of becoming serious failures. Therefore, in the above invention, a counter is provided for each type of alarm, and the counter is updated each time the failure occurs. Then, when the number of failure occurrences exceeds a prescribed number (threshold) determined by the maintenance operation, a report is made to the system administrator. This is used for preventive maintenance of the system.

Here, terms related to network management will be described in more detail. An “event” refers to an exceptional condition that occurs in a network.
Includes hardware and software failures, outages, performance bottlenecks, inconsistent network configurations, unintended consequences due to poor design, and malicious damage such as computer viruses.

[0007] A "symptom event" refers to an observable event. For example, “communication takes time for a certain destination A and retransmission is required”, “characters are garbled for a certain destination B”, and It doesn't return. " In the same sense, the word "Symptom" is used.

[0008]

According to the above invention, critical symptoms are immediately reported to the system administrator. However, as a result of recovery processing or retry, mild or warning symptom that recovers from failure,
If the threshold is not exceeded, it is not reported to the system administrator. As a result, there is a problem that the administrator cannot grasp the fact that there is a possibility that the sign may eventually become a serious obstacle.

On the other hand, if the symptom that is generated is notified as it is, it is notified every time a symptom is generated, even if the symptom itself is not so important, so that the number of the notification becomes enormous. As a result, another problem arises that it is difficult for the system administrator to grasp the situation.

The object of the present invention is to solve these conflicting problems. That is, the purpose is to efficiently notify the system administrator that the symptom has repeatedly occurred.

[0011]

In order to solve the above-mentioned problems, the present invention relates to the following: (A) a symptom abnormality occurrence state in which a symptom occurs more than a prescribed frequency; and (B) a symptom occurrence state less than a prescribed frequency. Symptom continually generated state (C) Symptoms are classified into three types, that is, symptom not generated at all, and (A) and (B) are notified. To notify these state transitions, a symptom called a bubbling symptom or a continuing symptom is used.

According to a first aspect of the present invention, there is provided a network management method for detecting and notifying the occurrence of a symptom. If the status of the symptom does not occur more than the specified frequency, it is notified that the symptom is no longer in the abnormal state, and if the symptom is generated less than the specified frequency, it is notified that the symptom has continued to be generated. If the symptom is no longer in a state in which the symptom is less than the prescribed frequency, the symptom is notified that the symptom is no longer in a continuation occurrence state.

With this configuration, the state of symptom occurrence is classified and notified according to the symptom occurrence frequency.

According to a second aspect of the present invention, in a network management system for detecting and notifying the occurrence of a symptom, a state where a symptom occurs at a frequency equal to or more than a specified frequency is defined as a symptom abnormality occurrence state, and a state where the symptom occurs less than a specified frequency. Is a symptom continuation occurrence state, and a state where a symptom is not generated is a symptom non-occurrence state. A network management system comprising: a symptom occurrence state detection unit that detects a state transition between the states; and a symptom occurrence state notification unit that notifies a part or all of the states.

With this configuration, the frequency of occurrence of the symptom is associated with the occurrence state of the symptom, and the state transition is detected and notified.

In a third aspect based on the second aspect, the symptom occurrence state notifying section notifies the occurrence of the symptom abnormality as the occurrence of the bubbling symptom, and bubbling that the symptom has no longer occurred. A network management system for notifying that the symptom has been restored, notifying that the symptom continuation has occurred and notifying that the symptom continuation has not occurred, and notifying that the symptom has no longer continued as the continuation symptom has been restored; It is.

With such a configuration, the occurrence and restoration of the bubbling symptom and the occurrence and restoration of the continuing symptom are notified according to the frequency of occurrence of the symptom.

A fourth aspect of the present invention is the network according to the second or third aspect, wherein the symptom occurrence state detecting section is set by a model in which a bubbling symptom and a continuing symptom are described in a modeling language. It is a management system.

With this configuration, the symptom occurrence state detection unit is set by a model in which a bubbling symptom and a continuing symptom are described in a modeling language.

[0020]

FIG. 1 shows a block diagram of a network management system embodying the present invention. The network interface unit 11 is an SNMP (Simple Netwo
The MIB (Mana) of the management target network 12 using a network management protocol such as rk Management Protocol (RK).
gement Information Base) and polling. In addition, a Trap event that autonomously reports (without polling) an abnormality or a state transition is received from the management target network. Data relating to network configuration information (configuration information data) is stored in the configuration management unit 13, and data relating to network failure information (failure information data) is stored in the event database unit 14.
Is converted to an appropriate format and sent. The schema definition file 20 is read by the configuration management unit 13 and is used for setting each part of the network management system.

Here, terms related to network management will be described in more detail. "Problem events"
Refers to the root cause of the failure. Not always observable. For example, the transmitter of the communication device is damaged, the communication cable is disconnected, and the capacity of the communication line is insufficient. In the same sense, we use the word "Problem".

An "object" refers to something that has a clear boundary and meaning for a concept, abstraction, or problem of interest. "Object instance"
Refers to one specific object. "Object class" refers to a group of objects having similar properties (attributes), common behavior (operations), common relationships with other objects, and common meanings.
“Class” is the same as “Object class”.
"Subclass" is a subclass of a class,
Refers to the class included in the class. "attribute"
Means data held by each object belonging to the class.

The "repository" refers to a storage unit in which necessary information is collected and stored in a list format. It should be called an aggregation list memory. The “event repository” refers to a storage unit that stores an actually generated symptom pattern. "Object repository" refers to a repository of network configuration models. As a result, the "symptom pattern that occurs when a certain cause is assumed" can be specified in advance.

In order to efficiently manage the network, it is preferable to handle the network to be managed and the event propagation by modeling. Therefore, in order to abstract the static aspects of the network to be managed and the event propagation, and to model efficiently, an object-oriented concept is adopted. That is, various managed objects are modeled as classes. Then, the relationship between the classes is defined. Then, certain events are modeled as propagating along the relationships between the classes. There are various textbooks about the object-oriented concept, so please refer to them.

The configuration management unit 13 holds a managed object model and an event propagation model related thereto. These models are input from the user interface unit 15. Further, instead of inputting from the user interface unit 15, reading from a file may be performed. Then, the configuration management unit 13 receives the configuration information data from the network interface unit 11, constructs the managed object configuration information based on the managed object model, and stores it in the managed object repository 16. The managed object repository 16 is a repository of a network configuration model.

The event database unit 14 receives configuration information data and fault information data as events from the network interface unit 11 and stores them in the event repository 17. The event repository 17 is a storage unit that stores a pattern of an actually occurring symptom.
Among the events, data relating to the failure information, in particular, a failure symptom event (symptom) is notified to the failure management unit 18.

The failure management unit 18 has a symptom occurrence state detection unit 21, a symptom occurrence state notification unit 22, and a root cause estimating unit 23 for a failure. Receive a set of symptom events.

The symptom occurrence state detecting section 21 judges the symptom occurrence state. Then, according to the occurrence state, the symptom occurrence state notification unit 22 performs the occurrence and restoration of the symptom abnormality occurrence state and the occurrence and restoration of the symptom continuation occurrence state by using either the user interface unit 15 or the event database unit 14 or Notify both.

The root cause estimating unit 23 estimates the root cause of the failure. The root cause of the failure can be estimated by, for example, patterning a symptom event that occurs for a certain problem event in advance, and comparing this pattern with a symptom pattern when the failure actually occurs. Alternatively, Japanese Patent Application No. 10-11239 filed by the present applicant.
7 can also be implemented. The root cause of the fault thus obtained is notified to the user interface unit 15.

The user interface unit 15 notifies the network administrator (user) of the root cause of the failure and the detected symptom occurrence state.

In FIG. 1, the network interface unit 11 is directly connected to the network 12 to be managed. Alternatively, as shown in FIG. 2, the network interface unit 11 may be configured to be indirectly connected to the management target network 12 via the existing network management system 19. Then, the present invention can be implemented by effectively using the existing network management system 19. In this case, the network interface unit 11 acquires the configuration information data and the failure information data held by the existing network management system 19 and converts them into an appropriate format.

In order for the network management system to efficiently handle a complicated network, it is preferable to first efficiently describe a management target in a modeling language. As the modeling language, for example, the present applicant has disclosed in Japanese Patent Application No.
This can be implemented by making the following extension to the event propagation modeling language disclosed in 7308.

First, a bubbling symptom is used for the notification about the symptom abnormality occurrence state, and a continuation symptom is used for the notification about the symptom continuation occurrence state.
om). These symptoms are globally defined according to the format shown in FIG. That is, instead of being defined inside a specific class, it is defined as being common to all classes.

In the format shown in FIG. 3, babbling_sympt
om is a keyword in parsing and is input as it is. The bubbling symptom name and the continuation symptom name give a distinctive name. "Description 1" and "description 2" are character strings used to make the display to the system administrator easy to understand. [] Means that it may be omitted (that is, "description 1" and "description 2" can be omitted).

Next, a condition (hereinafter, referred to as a bubbling condition) for causing a symptom abnormality state is set inside the class according to the format shown in FIG.
Define within. In this format, babbling is a keyword in parsing, and is input as it is. Bubbling symptom names are given the same names as those shown in FIG. The symptom name gives the name of the symptom whose occurrence is to be detected. If this symptom occurs more than a specified number of times during a specified observation period, a symptom abnormal state is set. Figure 4 shows the number of occurrences and the observation period.
In the format shown in. The unit of the observation period is seconds.

It is to be noted that, although not otherwise specified, in detecting the state of occurrence of a symptom, when a symptom occurs, both the case where the symptom is generated and restored, and the case where only the symptom is generated are performed. Shall be included.

If a symptom is generated less than the number of occurrences during this observation period, the state is set to the symptom continuous generation state. Therefore, the symptom continuation occurrence state does not need to be explicitly described in the modeling language.

According to the above-described format, the state in which the symptom named PortDown is generated 10 times or more in 20 seconds (symptom abnormal state) is described as BabblingPortDown.
FIG. 5 shows a description example of a model of a network in the case where notification is made by a bubbling symptom. The symptom continuation occurrence state is indicated by the ContinuingPortDo
Notify by the continuing symptom named wn. In the list shown in FIG. 5, the line starting with // is a comment line and does not affect the described model.
Is not part of the description of the network,
This is a reference numeral given to each line of the list for convenience described below. In the following, the numbers from to indicate the lines with the respective numbers

FIG. 5 defines a problem event (problem). problem is a keyword in parsing. And FatalConnectorPr respectively
Indicates that there are problems named oblem and MinorConnectorProblem. These names are used for notification from the fault management unit 18 to the user interface unit 15. "Fatal Connector Problem" on the right side of export
And "Minor Connector Problem" are strings used to make it easier for system administrators to understand. If you don't need to show this string to system administrators, use expo
rt and the character string on the right can be omitted.

Defines a symptom. sympto
m is a keyword in parsing. Is PortDown
Indicates that there is a symptom named.

Defines a bubbling symptom and a continuing symptom according to the format shown in FIG. Their names are BabblingPortDown and Cont
inuingPortDown. "Babbling condition of Port Down" and "Continuing"
condition of Port Down "is shown.

FIG. 5 shows an example in the interface, ie, i
The managed object class is defined in {} after nterface. interface is a parsing keyword. This managed object class is named Port. ManagedObject is the name of a managed class object class defined in another interface not shown. The management class object class inherits another specified management class object class unless it is newly defined therein. Here, the management class object class called Port
It inherits the attributes and relationships of a managed class object called ManagedObject. Note that the ManagedObject
It is needless to say that such inheritance will not be performed unless "."

Defines bubbling conditions according to the format shown in FIG. By this description, PortDo
If the symptom wn occurs more than 10 times in 20 seconds (symptom error occurrence state), BabblingPortDo
Notification is provided by a bubbling symptom called wn. In addition, the continuation symptom occurrence state is notified by a continuation symptom called ContinuingPortDown in combination with the description of FIG.

Defines event propagation.
This is described to infer the cause of the failure.
propagate is a parsing keyword. Is Fatal
Indicates that PortDown is caused by ConnectorProblem. B caused by MinorConnectorProblem
Indicates that abblingPortDown will occur. Is necessary to infer the cause of Portdown and BabblingPortDown, respectively. If you do not infer the cause,
Is unnecessary, and both are unnecessary.

Since such a model is written in a format that can be easily understood by the system administrator, the model is converted (compiled) into a format that can be easily handled by the network management system by the compiling device illustrated in FIG.

The compiling device includes a precompile unit 33 for integrating the source file 31 of the basic network model and the user-defined source file 32 and outputting it as a source combined file 34, and a source combined file 34 and a conversion table file 35. A lexical / syntax analysis unit 36 for analyzing and outputting syntax tree data and a conversion table, and a semantic analysis unit 37 for analyzing the meaning of the syntax tree data and outputting the schema definition file 20 are included.

The source file 31 of the basic network model stores a standard network model in an event propagation modeling language (for example, Japanese Patent Application No. 10-373 by the present applicant).
08 is a source file described in the event propagation modeling language disclosed in No. 08). The user-defined source file 32 is a source file expressing a network model extended to implement the present invention, and includes, for example, the description shown in FIG.

The connection of the source files to the precompile unit 33 is specified by an include statement. The include statement is a line starting with #include. In the user-defined source file 32, an include file name (specifically, the source file 31 of the basic network model) is described after #include. Then, the precompile unit 33 generates the user-defined source file 32
The source file 31 of the basic network model is referred to by referring to the include file name described in
And a user-defined source file 32 to output a source combined file 34.

The conversion table file 35 is a file created in advance, and is converted from an event propagation modeling language to an M / Core (Manage) used for a network management system.
mentCore, a registered trademark of Sumitomo Electric Industries, Ltd.) is defined. In the conversion table file 35, the above-described definition related to interface, attribute definition, relation definition, symptom definition, and the like are set.

The lexical / synthesis analysis unit 36 inputs the source combination file 34, and receives a JavaCC (Java Compiler Compiler,
Lexical characters using Sun Microsystems' registered trademark)
Parse is analyzed, and the result is output as syntax tree data. The lexical / syntax analysis unit 36 also receives the conversion table file 35 and creates a conversion table using JavaCC in the same manner.

The semantic analysis unit 37 includes a lexical / syntax analysis unit 36
The semantic analysis of the syntax tree data is performed by referring to the syntax tree data output from
Outputs the schema definition file 20 in the (mmaSeparated Value) format. The schema definition file 20 is read by the configuration management unit 13 shown in FIG.
It is used for setting each part of the network management system including the symptom occurrence state detection unit 21 and the symptom occurrence state notification unit 22.

Next, the determination of the bubbling condition performed by the symptom occurrence state detecting section 21 shown in FIG. 1 or 2 will be described. This means that the state of occurrence of a symptom is
Classify into (B) and (C).

(A) Symptom abnormal state: Symptom satisfies the bubbling condition. That is, the symptom is generated more than the specified number of times during the observation period specified by the bubbling condition.

(B) Symptom continuation occurrence state: A state in which the symptom does not satisfy the bubbling condition but has occurred one or more times in the specified observation period.

(C) Symptom not generated: A state in which the symptom has not been generated at least once in the observation period defined by the bubbling condition.

The occurrence state of the symptom transitions between these states. This is schematically shown in FIG. Reference numerals 41, 42 and 43 shown in FIG.
A symptom continuation occurrence state and a symptom non-occurrence state are shown.

The state of symptom occurrence can be managed by the network management system in the three states (A), (B) and (C). Specifically, the event database unit 14 shown in FIG. 1 or FIG. 2 creates one object corresponding to each of the bubbling symptom and the continuing symptom, and manages their occurrence and recovery. Then, as shown in FIG. 7, the symptom occurrence state notifying unit 22 changes the symptom occurrence state by the occurrence of the bubbling symptom, the restoration of the bubbling symptom, the occurrence of the continuation symptom, and the restoration of the continuation symptom. May be notified to the event database unit 14. Needless to say, when the symptom occurrence state does not change, the symptom occurrence state notifying section 22 does not need to perform the notification. By notifying in this way, the event data section can manage the occurrence and recovery of the symptom abnormality occurrence state and the occurrence and recovery of the symptom continuation occurrence state.

There are four types of notifications (a), (b), (c), and (d) performed by the symptom occurrence state notification unit in response to the state transition performed by the symptom occurrence state detection unit. .

(A) Notification of occurrence of bubbling symptom:
The case where the state transition of 44 or 45 shown in FIG. 7 occurs is a case where the symptom satisfies the bubbling condition. In this case, the occurrence of the symptom abnormality is notified as the occurrence of the bubbling symptom.
Once this notification has been made, this notification is not repeated until the bubbling symptom recovery is notified.

(B) Notification of bubbling symptom restoration:
The state transition of 46 or 47 shown in FIG. 7 occurs when the symptom does not satisfy the bubbling condition. In this case, the fact that the symptom abnormality has not occurred is notified as bubbling symptom recovery. Once this notification is made, this notification is not repeated until the occurrence of the bubbling symptom is notified.

(C) Notification of occurrence of continuation symptom: When the state transition of 46 or 48 shown in FIG. 7 occurs, during the observation period defined by the bubbling condition,
This is the case where the symptom is generated less than the specified number of times. In this case, the occurrence of the symptom continuation is notified as the occurrence of the continuing symptom. Once this notification has been made, this notification will not be repeated until it is notified that the continuation symptom has been restored.

(D) Notification of restoration of continuation symptom: When the state transition of 45 shown in FIG. 7 occurs,
This is the case where the symptom is generated more than the specified number of times during the observation period specified by the bubbling condition. When the state transition of 49 shown in FIG. 7 occurs, the symptom does not occur during the observation period defined by the bubbling condition. In these cases, the fact that the symptom continuation has not occurred is notified as restoration of the continuing symptom. Once this notification is made, this notification is not repeated until the occurrence of the continuing symptom is notified.

Since the bubbling symptom and the continuing symptom are a kind of symptom, it is easy for the existing network management system to receive a notification, or to process occurrence and recovery.

In the above embodiment, the symptom occurrence frequency is measured by paying attention to the number of occurrences during the specified observation period. The measurement timing is based on the specified observation period (for example,
0 seconds) (the number of occurrences in the past 20 seconds is counted every 20 seconds), or a fixed period shorter than the specified observation period (for example, the number of occurrences in the past 20 seconds every 1 second) , And when a symptom occurs (the number of occurrences in the past 20 seconds is counted every time a symptom occurs). These aspects are:
An appropriate one may be selected in consideration of the characteristics of the symptom, the desired measurement accuracy, the overhead required for the measurement, the labor required for realizing the measurement, and the like.

The technical scope of the present invention is not limited to these embodiments, but includes the scope equivalent to the claims, and various modifications can be made without departing from the spirit of the invention. is there.

[0066]

According to the first aspect, the occurrence state of the symptom is notified according to the occurrence frequency of the symptom. A large number of notifications are required for individual symptom occurrence and recovery, but only a small number of notifications are required because the symptom occurrence status is notified. That is, the state of occurrence of the symptom can be efficiently notified, and the system administrator can easily grasp the state of occurrence of the symptom.

According to the second aspect, the occurrence state of the symptom is detected and notified as a state transition according to the occurrence frequency of the symptom. Therefore, the occurrence state of the symptom can be efficiently notified, and the system administrator can easily grasp the occurrence state of the symptom.

According to the third aspect of the present invention, the transition between the three states of the symptom abnormality occurrence state, the symptom continuation occurrence state, and the symptom non-occurrence state is notified by the occurrence and restoration of the bubbling symptom and the occurrence and restoration of the continuing symptom. . Therefore, in the network management system,
There is no need to handle transitions between the three states, and it is sufficient to handle the two states of occurrence and recovery of the bubbling symptom and the continuing symptom, similarly to the conventional symptom. That is, it is easy to handle the occurrence state of the symptom by the existing network management system.

Further, the three cases of a symptom abnormal occurrence state, a symptom continuation occurrence state, and a symptom non-occurrence state are simplified to two kinds of a bubbling symptom and a continuing symptom. On the other hand, the system administrator can focus on whether a bubbling symptom has occurred, whether a continuing symptom has occurred, or whether these symptoms have not occurred. Work load is reduced as compared with the case where the management is performed while paying attention to

According to the fourth aspect, the bubbling condition of the symptom occurrence state detecting section can be set using a model in which a bubbling symptom and a continuing symptom are described in a modeling language. Therefore, new setting or setting change of the bubbling condition can be easily performed.

[Brief description of the drawings]

FIG. 1 is a diagram showing an embodiment of a network management system according to the present invention.

FIG. 2 is a diagram showing another embodiment of the network management system according to the present invention.

FIG. 3 shows a format for defining a bubbling symptom and a continuing symptom in a modeling language used to implement the present invention.

FIG. 4 shows a format for defining a bubbling condition in a modeling language used for implementing the present invention.

FIG. 5 shows an example of a model of a network described by a modeling language used for implementing the present invention.

FIG. 6 is a diagram showing a schematic configuration of a compiling device for compiling a network model.

FIG. 7 illustrates a symptom occurrence state and a notification performed by a symptom occurrence state notification unit.

[Explanation of symbols]

11: Network interface unit 12: Managed network 13: Configuration management unit 14: Event database unit 15: User interface unit 16: Managed object repository 17: Event repository 18: Fault management unit 19: Existing network management system 20: Schema Definition file 21: Symptom occurrence state detecting unit 22: Symptom occurrence state notifying unit 23: Root cause estimating unit 31: Basic network model source file 32: User-defined source file 33: Precompile unit 34: Source connection file 35 : Conversion table file 36: Lexical / syntax analysis unit 37: Semantic analysis unit 41: Symptom abnormality occurrence state 42: Symptom continuation occurrence state 43: Symptom non-occurrence state 44: Bubbling symptom 45: State transition notifying bubbling symptom occurrence and continuation symptom restoration 46: State transition notifying bubbling symptom restoration and continuation symptom occurrence 47: Notifying bubbling symptom restoration State transition 48: State transition notifying the occurrence of the continuing symptom 49: State transition notifying the restoration of the continuing symptom

──────────────────────────────────────────────────続 き Continued on the front page (51) Int.Cl. ⁷ Identification symbol FI Theme coat ゛ (Reference) H04L 12/28 H04L 11/00 310D 12/24 11/08 12/26

Claims (4)

[Claims] 1. A network management method for detecting and notifying the occurrence of a symptom, comprising:
Notify that a symptom has occurred and if the symptom is no longer occurring at the specified frequency or more, notify that the symptom is no longer occurring and enter a state where the symptom is less than the specified frequency. If
A network management method, comprising: notifying that a symptom continuation occurrence state has occurred; and notifying that the symptom continuation occurrence state has ceased if the symptom is no longer occurring less than a prescribed frequency. 2. A network management system for detecting and notifying the occurrence of a symptom, wherein a state in which a symptom occurs at a prescribed frequency or more is defined as a symptom abnormality occurrence state, and a state in which a symptom occurs less than a prescribed frequency is symptom continued occurrence. If the state where no symptom is generated is defined as the symptom non-generated state, the symptom generation detector that detects the occurrence of the symptom and the state transition between the symptom abnormal generated state, the symptom continuous generated state, and the symptom non-generated state A network management system comprising: a symptom occurrence state detection unit that detects a state; and a symptom occurrence state notification unit that notifies a part or all of the state. 3. The symptom occurrence state notifying section notifies the occurrence of the symptom abnormality state as the occurrence of the bubbling symptom, and notifies the absence of the symptom abnormality state as the recovery of the bubbling symptom. 3. The network management system according to claim 2, wherein the state is notified as the occurrence of a continuing symptom, and the absence of the symptom continuation occurrence state is notified as a restoration of the continuing symptom. 4. The network management system according to claim 2, wherein the symptom occurrence state detection unit is set by a model that describes a bubbling symptom and a continuing symptom in a modeling language.