JP2017107372A - Failure symptom detection system and failure symptom detection method - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a failure symptom detection system and a failure symptom detection method with which it is possible to respond early to a failure that occurs at the time of software execution.SOLUTION: The failure symptom detection system comprises: a detection definition creation device 100 for previously creating, as a detection definition, a log used to determine the name of a process monitoring unit that prescribes a range in which to detect a program failure symptom, and determine the presence of a failure symptom; and a log analysis device 200 for acquiring a log outputted each time a software program is executed, and detecting a failure symptom on the basis of the detection definition created for the log by the detection definition creation device 100. The log analysis device 200 detects an error log linked to a program failure and analyzing, on the basis of the detection definition for each process monitoring unit of a program, whether there is an occurrence of a detection log that is expected to occur when an originally normal process is executed, and detecting the case of no occurrence of a detection log as a failure symptom.SELECTED DRAWING: Figure 1

Description

  TECHNICAL FIELD The present invention relates to a failure sign detection system and method for detecting a failure sign from the characteristics of a system log (hereinafter simply referred to as a log) output during execution of software, thereby preventing the occurrence of a failure in advance or early detection. Is.

  Conventionally, in software fault detection, an error log associated with a fault is defined in advance, and an error is determined based on the occurrence of a defined error log at the site where the software is operating (see, for example, Patent Document 1 below) ).

  Taking the train operation management system as an example, if the train number entered by the commander does not exist in the system, the system will output a defined error log, so check the error log. Fault identification is performed.

JP 2008-9854 A

  The failure detection method using the conventional log generates an error log linked to the failure in this way, so in the case of a failure that does not explicitly generate an error log, the discovery is delayed, resulting in trouble with business. There was a problem that there was a possibility.

  The present invention has been made to solve the above-described problems. In addition to explicitly generating an error log associated with a failure, an error log is explicitly generated in addition to this. It is an object of the present invention to provide a failure sign detection system and a failure sign detection method that can be detected as a failure sign even when the failure is not detected, and can quickly cope with more failures.

  The failure sign detection system according to the present invention detects a failure sign based on a log output each time a software program to be analyzed for a failure is executed, and detects the failure sign of the program. A detection definition creation device that creates and registers as a detection definition the name of the process monitoring unit that defines the range and the log used to determine whether there is a sign of failure, and is output each time the software program is executed A log analysis device that acquires a log and detects a failure sign based on the detection definition created by the detection definition creation device for the acquired log, and the log analysis device is associated with a program failure. For each processing monitoring unit of the program based on the detection definition created in advance by the detection definition creation device. Analyzing the occurrence of the detection log which is scheduled the original occurs when normal processing is performed, if the detected log does not occur, is characterized by detecting this as a failure predictor.

  In addition, the failure sign detection method according to the present invention detects a failure sign of the above-mentioned program in order to detect the failure sign based on a log that is output each time a software program to be analyzed for failure is executed. The first step of creating and registering as a detection definition the name of the process monitoring unit that defines the range and the log used to determine whether or not there is a sign of failure, and the software program to be analyzed for failure are executed A second step of acquiring a log output each time, detecting a failure sign for the acquired log based on the detection definition created in advance, and notifying the presence of a failure sign; In the second step, not only when an error log associated with a failure of the software program is detected, but also based on the detection definition created in advance. Detects the start and end of processing for each processing monitoring unit of the program, and detects this as a sign of failure when a detection log that is expected to occur when normal processing is executed does not occur It is characterized by that.

  According to the present invention, not only when an error log associated with a failure is explicitly generated, but also when an error log is not explicitly generated, it can be detected as a failure sign. Early response is possible.

It is a block diagram which shows the structure of the failure sign detection system which concerns on Embodiment 1 of this invention. It is a flowchart which shows the detection process operation of the failure sign of the failure sign detection system which concerns on Embodiment 1 of this invention. It is explanatory drawing which shows an example of the detection definition table and log monitoring status table which are produced with the detection definition production apparatus of the failure sign detection system which concerns on Embodiment 1 of this invention. It is a block diagram which shows the structure of the failure sign detection system which concerns on Embodiment 2 of this invention. It is explanatory drawing which shows an example of the test definition table previously defined by the test information analysis part of the failure sign detection system which concerns on Embodiment 2 of this invention. It is a block diagram which shows the structure of the failure sign detection system which concerns on Embodiment 3 of this invention. It is explanatory drawing which shows an example of the failure determination table preset by the failure applicable determination part of the failure sign detection system which concerns on Embodiment 3 of this invention. It is a block diagram which shows the structure of the failure sign detection system which concerns on Embodiment 4 of this invention. It is explanatory drawing which shows an example of the test definition table defined by the test information analysis part of the failure sign detection system which concerns on Embodiment 4 of this invention. It is a block diagram which shows the structure of the failure sign detection system which concerns on Embodiment 5 of this invention. It is explanatory drawing which shows an example of the source reference relevant management table preset and registered in the influence notification part of the failure sign detection system which concerns on Embodiment 5 of this invention.

Embodiment 1 FIG.
FIG. 1 is a block diagram showing a configuration of a failure sign detection system according to Embodiment 1 of the present invention.

  The failure sign detection system 1 according to the first embodiment of the present invention includes a detection definition creation device 100 and a log analysis device 200. Although not shown between the detection definition creation device 100 and the log analysis device 200, data can be transferred via a network connection or a medium such as a CD. Each device 100, 200 is configured by a general computer.

  The detection definition creation apparatus 100 defines a range for detecting a failure sign of a program in order to detect a failure sign based on a log output each time the program is executed for the software 900 to be analyzed for the failure. A definition input unit 11 and a detection definition creation unit 12 are provided to create and register in advance a detection definition such as a name of a process monitoring unit to be used and a log used to determine whether or not there is a sign of failure.

  On the other hand, the log analysis device 200 acquires a log that is output each time the program is executed in the software 900 that is the target of failure analysis, and the detection definition creation device 100 creates the log that is obtained. A failure sign is detected based on the detected definition, and if there is a failure sign, it is notified, and a log acquisition unit 21, a log analysis unit 22, a detection definition management unit 23, a log status management unit 24, and It comprises a failure sign notification unit 25.

  Next, a specific configuration of each of the devices 100 and 200 will be described.

  In the detection definition creating apparatus 100, the definition input unit 11 is an interface for inputting information necessary for creating a detection definition, and includes, for example, a keyboard, a mouse, and a tablet terminal. The detection definition creation unit 12 creates a detection definition using the information input from the definition input unit 11, and holds this detection definition information as a detection definition table as shown in FIG.

  On the other hand, in the log analysis device 200, the log acquisition unit 21 acquires various logs that are generated when the analysis target software 900 is executed. Further, the detection definition management unit 23 acquires the detection definition created by the detection definition creation unit 12 of the detection definition creation device 100. The log analysis unit 22 analyzes the contents of the log acquired by the log acquisition unit 21 and detects a failure sign. During the log analysis, the log analysis unit 22 uses the detection definition information held by the detection definition management unit 23. The log status management unit 24 includes a memory for managing the status being analyzed by the log analysis unit 22, and holds the analysis result by the log analysis unit 22 as a log monitoring status table as shown in FIG. To do. Further, as a result of the log analysis, the log analysis unit 22 determines the presence / absence of a failure sign based on the information registered in the log state management unit 24. Notify the notification unit 25. The failure sign notification unit 25 has a failure sign on a front screen (not shown) such as a CRT or a liquid crystal (not shown) included in the log analysis device 200 or an external alarm device in response to the notification of the failure sign from the log analysis unit 22. Notify that.

  Next, the failure sign detection processing operation of the failure sign detection system 1 will be described with reference to the flowchart shown in FIG. In addition, the code | symbol S means each process step.

  The processing operation in the first embodiment includes a creation flow S1 for creating a detection definition, as shown in FIG. 2A, and a log of the software to be analyzed and the detection definition, as shown in FIG. 2B. And an analysis flow S2 for performing failure detection based on the above.

  First, regarding the creation flow S1, detection definition information necessary for detecting a failure sign is input from the definition input unit 11 to the detection definition creation unit 12 (S11), and the detection definition is input to the detection definition creation unit 12. Is registered (S12). As a result, the detection definition creation unit 12 creates a detection definition table as shown in FIG. 3A based on the information input from the definition input unit 11. Then, the information in the detection definition table as shown in FIG. 3A created by the detection definition creation unit 12 is transferred to the detection definition management unit 23 of the log analysis device 200 and registered therein.

  When creating the detection definition table shown in FIG. 3A, the process monitoring unit of the program is set and registered as an analysis target range for detecting a failure sign. Further, it is common for software to output a trace log indicating that processing has been executed in starting and executing various processing. Therefore, using this trace log, a log used for determining whether there is a failure sign is registered for each process monitoring unit. That is, for each process monitoring unit, a log that serves as a mark for starting failure sign detection is registered as a start log, and a log that serves as a mark at the end is registered as a finish log. Furthermore, a log that is normally generated immediately before the end log is generated when the process based on the program in the process monitoring unit is normally executed is registered as a detection log.

  On the other hand, for the analysis flow S2, the log acquisition unit 21 acquires a start log from the software being executed. Here, it is assumed that the software 900 to be analyzed is operating in multi-tax for each process monitoring unit name of the program.

  When this start log corresponds to the start log registered in the detection definition table (FIG. 3A) transferred to the detection definition management unit 23, the log analysis unit 22 uses the process monitoring unit number as a key to log The current state is set to “start” in the log monitoring state table shown in FIG. 3B provided in the state management unit 24 (S21).

  In addition, the log analysis unit 22 monitors the occurrence of the detection log acquired by the log acquisition unit 21, and when a detection log is generated, the log monitoring state table provided in the log state management unit 24 (FIG. 3B). ) Is set to “present” (S22).

  Further, the log analysis unit 22 monitors the occurrence of the end log acquired by the log acquisition unit 21. When the end log is generated, the log analysis unit 22 performs the log monitoring state table (FIG. 3B) provided in the log state management unit 24. The current state is set to “end” (S23).

  Then, the log analysis unit 22 performs log analysis with reference to the log monitoring state table (FIG. 3B) provided in the log state management unit 24 (S24). That is, it is determined whether or not a detection log is generated for a process monitoring unit whose end log status is “End” (S25).

  The log analysis unit 22 indicates that when the detection log is not “existing” even though the end log is in the “end” state, the program of the process monitoring unit has been normally executed normally. Since the detection log that should occur in this case has not occurred, it is determined that there is a failure in the program of the processing monitoring unit, and the failure predictor notification unit 25 notifies the CRT or the like (not shown) provided in the log analysis apparatus 200 to that effect. A notification is sent to a front screen such as a liquid crystal display or to an external alarm device (S26).

  As a specific example of the above processing, in the log monitoring status table of FIG. 3B, for the program whose processing monitoring unit name is “10001”, the task has not yet been completed, so the status of the start log is “start”. The exit log has not been generated yet. Therefore, no detection log is generated, and no failure predictor notification is output from the failure predictor notification unit 25.

  For the program whose process monitoring unit name is “10002”, since the task has already been completed, an end log is generated and the current state is “end”. Nevertheless, since the detection log generation state is “None”, in this case, there is a possibility that a failure has occurred in the program processing whose process monitoring unit name is “10002”. Therefore, a failure sign notification is output from the failure sign notification unit 25.

  On the other hand, for the program whose process monitoring unit name is “10003”, since the task has already been completed, an end log is generated and the current state is “end”. In addition, since the detection log is generated normally, the generation state is “present”. In this case, it is determined that the program process having the process monitoring unit name “10003” has been normally executed, and therefore, the failure predictor notification unit 25 does not output a failure predictor notification.

  For the program whose process monitoring unit name is “10011”, an error log associated with a clear failure of the program is generated before the execution of the task is completed. Regardless, the failure sign notification unit 25 outputs a failure sign notification.

  As described above, in the first embodiment, based on the detection definition created in advance by the detection definition creation device 100, the log analysis device 200 detects the start and end of processing for each process monitoring unit of the program, and the processing is normally normal. When it is found that the detection log that is expected to occur when is executed, this is detected as a failure sign. As a result, in addition to the case where an error log associated with a failure is detected, a failure sign can be detected even when an error log is not explicitly generated. For this reason, the effect that an early response | compatibility with respect to more faults is attained is acquired.

Embodiment 2. FIG.
FIG. 4 is a block diagram showing the configuration of the failure sign detection system according to the second embodiment, and parts corresponding to those of the configuration of the first embodiment shown in FIG.

  The feature of the second embodiment is that a test information analysis apparatus 300 is added to the configuration of the first embodiment, and as a result, the software 900 to be analyzed is tested as shown in FIG. The detection definition table as shown can be easily created.

  A product in which the software 900 to be analyzed is installed is tested to determine whether or not the software 900 operates as prescribed before the product is shipped. In the test, not only data that is expected to give a normal result in advance is entered, but data that gives an incorrect result is intentionally entered to generate an error and the software 900 operates correctly. Confirm.

  Therefore, in the second embodiment, the test information analysis apparatus 300 is configured by the test information input unit 31, the test information analysis unit 32, and the test information transmission unit 33.

  Here, the test information input unit 31 is an interface for inputting test information necessary for defining test contents, and is configured by, for example, a keyboard, a mouse, a tablet terminal, or the like. In this case, the test information required to define the test content includes normal / abnormal assuming the test number associated with each program to be monitored, the process monitoring unit name, and the test result of the program. Is input.

  The test information analysis unit 32 holds the test information defining the test contents input from the test information input unit 31 in a memory as a test definition table as shown in FIG. 5, and based on this test definition table, software Log information obtained when a test result obtained by executing a program for each processing monitoring unit of the software 900 becomes normal when a test for whether or not the 900 program operates as predetermined for each processing monitoring unit is performed. To extract.

  That is, the test information analysis unit 32 extracts a detection log obtained when the processing result of the program executed for each processing monitoring unit is normal. Then, the test information analysis unit 32 transmits the extracted information (process monitoring unit name and detection log) as detection definition information to the detection definition creating apparatus 100 via the test information transmission unit 33.

  Then, the detection definition creation unit 12 manually adds a start log and an end log to the detection definition information sent from the test information analysis apparatus 300 for each process monitoring unit name, thereby allowing the detection definition information shown in FIG. The detection definition table as shown in a) is completed.

As a result, the detection definition table as shown in FIG. 3A can be easily created when the test of the software 900 is performed. Therefore, the detection definition table necessary for performing the failure sign analysis can be created. As compared with the case of creating the original, the effect that the labor and preparation time can be reduced is obtained.
Since other configurations and operational effects are the same as those in the first embodiment, detailed description thereof is omitted here.

Embodiment 3 FIG.
FIG. 6 is a block diagram showing the configuration of the failure sign detection system according to the third embodiment of the present invention, and the same reference numerals are given to the portions corresponding to the configuration of the second embodiment shown in FIG.

  When a part of the processing range in the program of the software 900 to be analyzed is executed, depending on the processing contents, the entire processing result is not affected even if no detection log is generated unless an error log is generated. There may be a program that does not interfere with operation.

  Therefore, in the third embodiment, a failure appropriateness determination unit 26 is added in the log analysis apparatus 200 to the configuration of the second embodiment, and the failure appropriateness determination unit 26 has a configuration as shown in FIG. If a detection log is not generated, a failure determination table that can define that it is not necessary to notify a failure sign is preset and registered in the memory.

  For example, in the failure determination table shown in FIG. 7, for a program whose process monitoring unit name is “1001” or “1003”, a detection log is generated when the task has already been completed and the current state is “finished” If there is no failure, it is set in advance to allow (YES) notification by the failure sign notifying unit 25 that there is a failure sign.

  On the other hand, for the program whose process monitoring unit name is “1002”, the failure predictor notifying unit 25 even if no detection log is generated when the task has already been completed and the current state is “finished”. Notification in advance is set to be unnecessary (No).

  Therefore, in the above-described first embodiment, as shown in FIG. 3B, for the program whose process monitoring unit name is “1002”, the task has already been completed and the current state becomes “finished”. In the third embodiment, the failure predictor notification unit 25 refers to the failure determination table shown in FIG. 7 while the failure predictor notification unit 25 notifies the failure log if no detection log is generated. Thus, notification by the failure sign notification unit 25 is suppressed even when no detection log is generated.

As described above, in the third embodiment, the failure determination unit 26 is provided, and when executing a part of the processing range in the program, the processing result does not affect the entire processing result. In this case, even if no detection log is generated, it is determined that there is no particular problem in operation and it is possible to suppress the failure sign notification. As a result, it is possible to save the trouble of confirming the presence / absence of notifications for all programs of each process monitoring unit name, and it is possible to reduce the confirmation time especially when there is a failure predictor notification that increases the number of confirmations. It is done.
Since other configurations and operational effects are the same as those in the second embodiment, detailed description thereof is omitted here.

Embodiment 4 FIG.
FIG. 8 is a block diagram showing the configuration of the failure sign detection system according to the fourth embodiment of the present invention, and parts corresponding to those of the configuration of the third embodiment shown in FIG.

  As shown in FIG. 8, the feature of the fourth embodiment is that a source management device 400 including a log addition processing unit 41 and a log additional information transmission unit 42 is added to the configuration of the third embodiment, and this Thus, the detection definition table as shown in FIG. 3A can be automatically created in accordance with the test of the software 900 to be analyzed.

  Here, the log addition processing unit 41 inputs information of a start log indicating the start time of the source code of the program and an end log indicating the end time for each process monitoring unit corresponding to the test number, and the log additional information transmission unit 42. Transmits the information of the start log and the end log added by the log addition processing unit 41 to the test information analysis apparatus 300.

  Since the information of the start log and the end log transmitted from the log addition processing unit 41 is taken into the test information analysis unit 32 via the test information input unit 31, the test definition table provided in the test information analysis unit 32 includes As shown in FIG. 9, not only the test number associated with each program to be monitored, the process monitoring unit name, information indicating that the test result of the program is normal / abnormal (see FIG. 5), The source code of the program for each process monitoring unit corresponding to the test number, the start log indicating the start time of the source code, and the end log information indicating the end time are also registered.

  As described in the second embodiment, the test information analysis apparatus 300 is configured to perform a test as to whether or not it operates as predetermined for each processing monitoring unit of the program of the software 900 to be analyzed. The log information obtained when the test result by the program execution for every 900 processing monitoring units becomes normal is extracted. Information extracted in this case includes a process monitoring unit name, a detection log, a start log, and an end log. Since the information extracted in this way is transmitted as a detection definition to the detection definition creation device 100, the detection definition creation unit 12 automatically creates a detection definition table as shown in FIG. .

As described above, in the fourth embodiment, the source management device 400 is added to the configuration of the third embodiment, and as a result, as shown in FIG. Since the detection definition table is automatically created, the time and preparation time are greatly reduced compared to the case where the detection definition table necessary for failure sign analysis is created by the detection definition creation device 100 independently. The effect that it can be obtained.
Since other configurations and operational effects are the same as those in the third embodiment, detailed description thereof is omitted here.

Embodiment 5. FIG.
FIG. 10 is a block diagram showing the configuration of the failure sign detection system according to the fifth embodiment of the present invention. The same reference numerals are given to the portions corresponding to the configuration of the fourth embodiment shown in FIG.

  In the fifth embodiment, as shown in FIG. 10, an influence notification unit 43 is added to the configuration of the fourth embodiment in the source management apparatus 400. A source reference relation management table that defines the relation between the source code related to each process monitoring unit name and the source code of the reference source or the reference destination program as shown in FIG. The information on the source reference relation management table is notified to the failure appropriateness determination unit 26.

  Thereby, as a result of the log analysis by the log analysis unit 22, the detection log is generated even though the task of the program having the predetermined process monitoring unit name has already been completed and the current state is “finished”. 7 and the failure determination table shown in FIG. 7 registered in advance in the failure determination unit 26 is allowed (YES) to notify a failure predictor when no detection log has occurred. If it is determined that the failure is detected, the failure determination unit 26 refers to the source reference relation management table shown in FIG. 11 notified from the influence notification unit 43, and the source code of the program having the process monitoring unit name and its source code The source code of the reference source or reference destination program is notified on a front screen such as a CRT or a liquid crystal (not shown) via the failure sign notification unit 25.

  For example, when it is determined that there is a failure sign in a program having the process monitoring unit name “10001”, the source code “AAA.c” and its reference source are based on the source reference relation management table shown in FIG. The source code “main.c” of the program and the source code “AAA-1.c” and “AAA-2.c” of the reference destination program are notified.

As a result, when a detection log does not occur when the source code of a program having a predetermined process monitoring unit name is changed, the source code of the changed source code reference source or the reference destination program Since it is possible to confirm again that there is a possibility that a failure sign has occurred, it is possible to detect a failure sign for a peripheral processing program that may occur in accordance with a change in the source code. For this reason, the effect that the early response | compatibility with respect to more faults is attained is acquired.
Other configurations and operational effects are the same as those of the fourth embodiment, and thus detailed description thereof is omitted here.

  The present invention is not limited to the configurations of the first to fifth embodiments described above, and may be modified to a part of the configurations of the first to fifth embodiments without departing from the spirit of the present invention. Part of the configuration can be omitted, and the configurations of the first to fifth embodiments can be combined as appropriate.

1 failure sign detection system, 100 detection definition creation device, 11 definition input unit,
12 detection definition creation unit, 200 log analysis device, 21 log acquisition unit, 22 log analysis unit, 23 detection definition management unit, 24 log state management unit, 25 failure sign notification unit,
26 failure determination unit, 300 test information analyzer, 31 test information input unit,
32 test information analysis unit, 33 test information transmission unit, 400 source management device,
41 log addition processing unit, 42 log additional information transmission unit, 43 influence notification unit.

Claims (6)

A failure sign detection system that detects a failure sign based on a log that is output each time a software program that is subject to failure analysis is executed,
A detection definition creation device for creating and registering as a detection definition a name of a process monitoring unit that defines a range in which a failure sign of the program is detected and a log used to determine whether or not there is a failure sign, and a program for the software A log analysis device that acquires a log that is output each time it is executed, and that detects a failure sign based on the detection definition created by the detection definition creation device for the acquired log;
The log analysis device detects an error log associated with the failure of the program, and performs normal processing for each processing monitoring unit of the program based on the detection definition created in advance by the detection definition creation device. A failure sign detection system that analyzes whether or not a detection log that is expected to occur when executed is detected, and detects the detection log as a failure sign when the detection log is not generated. A test information analyzer, the test information analyzer is configured to input test information for defining test contents for each processing monitoring unit of the software program, and the test information input unit inputs the test information. Based on the test information, when the test of whether the software program operates as prescribed for each processing monitoring unit is performed or not, when the test result by the program execution for each processing monitoring unit becomes normal A test information analysis unit that extracts log information obtained, and a test information transmission unit that transmits the log information extracted by the test information analysis unit as detection definition information to the detection definition creation device. The failure sign detection system according to claim 1. Log addition that adds start log information indicating the start time and end log information indicating the end time of the program source code for each process monitoring unit to the test information input to the test information input unit of the test information analyzer The failure sign detection system according to claim 2, further comprising a processing unit. Even if it is analyzed by the above log analysis device that no detection log has been generated, if it is not necessary to notify the failure sign in a system operation, the failure determination that suppresses the notification that the failure sign is present The failure sign detection system according to any one of claims 1 to 3, further comprising a unit. An impact notification unit that defines the relationship between a specific source code and its reference source and reference source code, and the log analyzer detects the detection log as a failure sign when no detection log is generated. 5. The system according to claim 1, further comprising the step of notifying that there is a possibility that a failure sign has occurred for a reference source and a reference source code of a specific source code based on information of an influence notification unit. The failure sign detection system described in 1. In order to detect a failure sign based on a log that is output each time a software program that is subject to failure analysis is executed, the name of the process monitoring unit that defines the range in which the failure sign of the program is detected and the failure sign A first step of creating and registering a log used for determining whether or not there is a detection definition in advance;
Obtain a log that is output each time a software program that is subject to failure analysis is executed, detect a failure sign for the acquired log based on the detection definition created in advance, And a second step for notifying that if any,
In the second step, not only when an error log associated with a failure of the software program is detected, but also based on the detection definition created in advance, the start and end of processing for each process monitoring unit of the program. A failure sign detection method, wherein when a detection log that is detected and is expected to occur when normal processing is executed does not occur, this is detected as a failure sign.

Images