JPH10312321A - On-line system fault analyzing method - Google Patents

Abstract

PROBLEM TO BE SOLVED: To minimize the influence of a fault by actualizing processes from the detection of a fault of an on-line system to a display of a countermeasure method in real time. SOLUTION: When a fault message is generated, a counter 1 is made to one (step 152). The history accuracy and monitor accuracy of the instance in the place that the counter indicates as to all instances in a message table are found (step 168). A display of the generation cause of the fault message is made and the instance having the maximum history accuracy in the message table is displayed as an optimum countermeasure method (the instance having the maximum monitor accuracy is displayed when there is more than history having the maximum history accuracy) (step 156). When a countermeasure is automatically set, a countermeasure command and a countermeasure confirmation command are executed (step 160) and after a recovery from the fault, the countermeasure result is displayed (step 164), but when the fault is not recovered, a counter measure module is actuated to take a manual countermeasure (step 166).

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a failure analysis method for displaying a cause of a failure and a method of dealing with the failure with respect to hardware and software failures from information output from the system, and more particularly, from the detection of the failure. To online systems that require high-speed real-time processing.

[0002]

2. Description of the Related Art Devices and systems for diagnosing faults of hardware such as equipment and faults of software such as application programs have been developed and operated in various fields. Failure management plays a major role in managing these systems. For example,
As shown in Japanese Patent Application Laid-Open No. 06-161760, there is a device having a device having a real-time property for device diagnosis. In this technique, the diagnosis performed by an expert is mechanized, and the determination is not varied, thereby enabling a quick diagnosis. Also, Japanese Patent Application Laid-Open No. 08-237
As disclosed in Japanese Patent Publication No. 188, the communication terminal device stores data relating to the communication history and transmits data at the time of a communication failure to the information storage device via the network, thereby efficiently maintaining the communication terminal device. I can do it.

[0003] In companies and government offices, various online systems operate in fields requiring high-speed processing and reliability. In these systems, software such as an application program runs on hardware such as equipment, and diagnoses failures of individual hardware and software.

[0004]

However, such a conventional method has the following problems.

That is, when a plurality of hardware and software failures occur simultaneously, it is difficult to realize the processing from the detection of the failure to the handling of the failure at a high speed.

As described above, the conventional method deals with an individual failure of hardware or software, and deals with a failure of a system constituted by a plurality of hardware devices and software and possibly affecting each other. There was a problem that it was not possible.

An object of the present invention is to provide an online system failure analysis method capable of dealing with a failure of an online system composed of a plurality of hardware devices and software in real time.

Another object of the present invention is to improve the accuracy and speed of work and to facilitate the work by mechanizing complicated trouble recovery work conventionally performed by humans, thereby minimizing damage due to trouble. Another object of the present invention is to provide a means for a person who does not have specialized knowledge to perform a disaster recovery operation.

[0009]

SUMMARY OF THE INVENTION The present invention accumulates information relating to the history of messages output from an online system to a monitoring terminal for a certain period of time and monitors the operation status of hardware / software, and a failure occurs. Then, the cause of the failure is displayed and the method of handling the past optimum case is displayed.

The message output from the online system to the monitoring terminal is constantly monitored by the message monitoring module, and the history of the output message for a certain period of time is accumulated in the history accumulation table as needed. When a failure occurs, the history accumulation table at the time of occurrence of the failure is copied as a work history accumulation table. The history of past cases in the work history accumulation table and the message table is stored in the message I
Matching is performed using D as a key, and the number of matches is stored as a history certainty factor. Subsequently, the operation status of the hardware / software at the time of occurrence of the failure and the operation status of the hardware / software at the time of occurrence of the past case in the message table are matched with the hardware / software name and the monitoring item as keys. And the number of matches is stored as the monitoring certainty factor. Then, the case with the highest historical certainty is determined as the optimal case (when there are a plurality of cases with the highest historical certainty, the case with the highest monitoring certainty is determined). In addition,
Cause and classification information of fault messages and past case information are managed in a message table. Subsequently, the cause of the failure is displayed and the method of coping with the optimum case is displayed. Recovery from failure by handling is performed by executing a handling command and a handling confirmation command and confirming the result.

[0011] A failure analysis method characterized by constantly monitoring hardware and software, and real-time display of the cause of the failure and the method of dealing with the failure of the hardware and software is realized.

There are two types of information related to the fault, information related to the cause of the fault and information related to past fault cases.

[0013]

Embodiments of the present invention will be described below in detail.

FIGS. 1, 2, 3 and 4 are flowcharts showing an embodiment of a processing procedure when the present invention is applied to an online system, and FIG. 5 is an online system failure analysis according to the present invention. It is a block diagram showing composition of a method. 6 and 7 are data tables used when implementing the online system failure analysis method according to the present invention.

In FIG. 5, the failure analysis processing is realized by five modules in the monitoring terminal. The message monitoring module 12 first stores all messages output from the online system 10 to the monitoring terminal via the message acquisition unit 11 in the history accumulation table 17. Next, the classification information relating to the output message is referred to the message table 19 and stored in the history accumulation table 17. The hardware monitoring module 13 constantly monitors the operating status of the hardware, and stores it in the hardware monitoring table 20. Software monitoring module 14
, Constantly monitors the software operation status, and stores it in the software monitoring table 21. The history accumulation table 17 is used to accumulate information related to the history of messages output from the online system 10.
The work history storage table 18 is used to secure a message history at the time of occurrence of a failure and to compare the message history with a history of past cases in the message table. The handling history table 22 is used to store a handling result after a failure has occurred. The message to be monitored is stored in the message table 19 in a form categorized by hardware / software and system message / application message using the message ID as a key. The hardware monitoring table 20 is a table for constantly monitoring the operation status of the hardware, and the setting of the monitoring target is set in advance. Software monitoring table 21
Is a table for constantly monitoring the operation status of the software, and the setting of the monitoring target is set in advance. The failure analysis module 15 is activated when a failure occurs, displays the cause of the failure, displays a method of coping with a past optimum case, and stores the coping result in the coping history table 22. The handling history table 22 is a table for storing information on the handling of a fault message that has occurred.

FIGS. 6 and 7 show the record format of each table in FIG. 5. The relationship between the tables in FIGS. 6 and 7 will be described below. FIG. 6A is a record format of the history accumulation table 17 and the work history accumulation table 18 in FIG. Here, each item of FIG. 6A <history accumulation table and work history accumulation table> will be described. The message ID is the online system 10 in FIG.
5 is used as a key for identifying a message output to the monitoring terminal of FIG. 5 and is accumulated in the <history accumulation table> of FIG. 5A every time a message occurs. The occurrence time stores the time when the message was output. The software / hardware division and the failure / warning division are stored with reference to FIG. 6B <message table>. The message stores comment information in the output message in text format. FIG.
B <message table> is a record format of the message table 19 in FIG. Subsequently, FIG. 6B
Each item of the <message table> will be described. The message ID is managed as a key in FIG. 6B <message table>, and is classified by hardware / software and system message / application message. The fault / warning category indicates whether the message indicates a fault or a warning.
The cause is information described in the manual, and the importance indicates the meaning of the message. The number of cases indicates how many past cases are stored in the <message table> in FIG. 6B. For only the fault message, the history of the output message when a past case has occurred is managed in a history accumulation table, and the information on the handling of the past case is managed in a handling table. Then, FIG. 6C
Each item of the <action table> will be described. FIG. 6C <
The countermeasure table> stores the countermeasures taken for the fault that has occurred. In the countermeasure, the content of the actual countermeasure is stored. The response command stores the command used for the actual response, and the response result command stores the execution result of the response command. The response confirmation command stores a command for confirming that the response command has been executed correctly, and the response confirmation result stores confirmation items of the execution result of the response confirmation command. In the history certainty factor, the result of matching using a message ID as a key between the failure accumulation time table shown in FIG. 6A <work history accumulation table> and the case history accumulation table stored in FIG. 6B <message table> is stored. In the monitoring certainty factor, the result of matching using the hardware / software operating status at the time of occurrence of the failure and the hardware / software name and the monitoring item as keys is stored. In the automatic / manual response setting, it is set whether a response is automatically performed when the degree of certainty is highest among past failures. Subsequently, FIG. 7D
<Hardware monitoring table> is a record format of the hardware monitoring table 20 of FIG. 5, and sets a monitoring item and a monitoring result for each hardware. FIG. 7E
<Software monitoring table> is a record format of the software monitoring table 21 in FIG. 5, and sets a monitoring item and a monitoring result for each software. FIG. 7F
The <response history table> corresponds to the response history table 22 in FIG.
This is a table for storing when the handling of the generated failure message is completed, and is stored as an example in the message table 19 of FIG. 4 when the failure analysis is completed.

Next, each operation of FIG. 5 will be described based on the flowcharts of FIGS. 1, 2, 3, and 4.

The operation from the start (step 100) to the end of the message monitoring module 12 in FIG. 5 will be described.
Processing is performed until the failure analysis is completed (step 10
2). First, it is confirmed whether a message is output from the online system 10 of FIG. 5 (step 10).
4). If the message has been output, the message ID is used as a key to refer to the message table 19 in FIG. 5, and the information on the output message is accumulated in the history accumulation table 17 in FIG. 5 (step 106). At the time of storing, the message ID, the occurrence time, the soft / hard classification, the failure / warning classification, and the message are referred from the message table 19 in FIG. When a message not registered in the message table 19 of FIG. 5 is output, the message is not stored in the history storage table. Next, it is determined whether the output message is a failure message (step 108), and if it is a failure, the following processing is performed. First, the history accumulation table at the time of occurrence of the failure message is copied as a work history accumulation table (step 110). Subsequently, if the failure message is related to hardware (step 112), the hardware monitoring table is updated (step 114). If not, the software monitoring table is updated (step 116). Subsequently, if a countermeasure exists in the message table 19 of FIG. 5 (step 118), the failure analysis module of FIG. 5 is started (step 120). If no workaround exists,
Only the cause of the failure is displayed (step 122). FIG. 6B <Message Table>
Is performed depending on whether the number of cases is 0 or not.

Next, the processing from activation (step 130) to termination of the hardware monitoring module 13 in FIG. 5 will be described. The hardware monitoring module 13 stores the operating status of the hardware in the hardware management table 20 until the failure analysis is completed (Step 132) (Step 134).

Next, the processing from activation (step 140) to termination of the software monitoring module 14 of FIG. 5 will be described. The software monitoring module 14 stores the operating status of the software in the software management table 21 until the failure analysis is completed (Step 142) (Step 144).

Next, the processing from the start (step 150) to the end of the failure analysis module 15 in FIG. 5 will be described.
First, the counter used for finding the optimum case from the past cases is set to 1 (step 152). First, it is determined whether the counter is larger than the number of cases in FIG. 6B <message table> (step 154). If not,
The matching result is stored in the history certainty factor of FIG. 6C <action table> of the matching result using the message ID of the history storage table and the work history storage table of the cases stored in the order indicated by the counter as keys. Subsequently, the hardware / software names and monitoring items of the software / hardware monitoring table of FIG. 6A <history accumulation table> and the software / hardware monitoring tables of FIGS. 7D and 7E of the cases stored in the order indicated by the counter Is stored in the monitoring certainty factor. Subsequently, 1 is added to the counter (step 168). The counter is shown in FIG.
If it is larger than the number of cases in the message table>, the following processing is performed (step 154). The case with the highest historical certainty is taken as the best case (when there are multiple cases with the highest historical certainty, the case with the highest monitoring certainty is taken). Do (Step 1
56). Subsequently, referring to the automatic / manual countermeasure setting in FIG. 6C <countermeasure table>, it is determined whether the countermeasure is set automatically (step 158). If the automatic setting has not been made, the coping module is activated and a coping is performed by a person (step 166). In the case of automatic setting, FIG.
The action command and the action confirmation command of the action table> are executed (step 160). Subsequently, it is determined whether or not the failure has been recovered by comparing the response result and the response confirmation result in the <response history table> of FIG. 7F (step 162), and when recovery has been performed, the failure recovery is displayed (step 164). If not recovered, the coping module is activated and a coping by a person is performed (step 166).

Next, the processing from activation (step 170) to termination of the handling module 16 in FIG. 5 will be described. First, a response input by a person is waited for (step 172), and after the input, a response result and a response confirmation result are stored in FIG. 7F <response history table> (step 174). Whether or not the failure has been recovered is determined by comparing the response result and the response confirmation result in FIG. 7F <response history table> (step 176), and when recovery has been performed, failure recovery is displayed (step 178). If it has not recovered, a human response is taken (step 17).
2, 174, 176).

[0023]

As described above, according to the present invention, it is possible to deal with a failure of an online system composed of a plurality of hardware devices and software in real time. Can be minimized. In addition, by mechanizing and supporting a complicated failure recovery operation conventionally performed by a human, even a person without specialized knowledge can perform the failure recovery operation.

[Brief description of the drawings]

FIG. 1 is a flowchart showing an embodiment of a processing procedure of the present invention.

FIG. 2 is a flowchart showing an embodiment of a processing procedure of the present invention.

FIG. 3 is a flowchart showing an embodiment of a processing procedure of the present invention.

FIG. 4 is a flowchart showing an embodiment of a processing procedure of the present invention.

FIG. 5 is a system block diagram of an online system failure analysis method according to the present invention.

FIG. 6 is a data table constituting an online system failure analysis system according to the present invention.

FIG. 7 is a data table constituting an online system failure analysis system according to the present invention.

[Description of Signs] 10 online system 11 message acquisition unit 12 message monitoring module 13 hardware monitoring module 14 software monitoring module 15 failure analysis monitoring module 16 handling module 17 history accumulation table 18 work history accumulation table 19 message table 20 hardware monitoring table 21 Software monitoring table 22 Response history monitoring table.

Claims (3)

[Claims] 1. A method for accumulating information relating to data output from a system, checking a correspondence between information relating to a failure and information relating to data outputted from the system, and detecting a failure when the correspondences match. A failure analysis method characterized by realizing the display of the cause related to the failure and the method of dealing with the failure. 2. The method according to claim 1, wherein the monitoring of the hardware and the monitoring of the software are constantly performed, and for the failure of the hardware and the software, the cause of the failure and the method of dealing with the failure are displayed. Failure analysis method. 3. The failure analysis method according to claim 2, wherein the information relating to the failure manages information relating to a cause of the failure and information relating to past cases of the failure.