JP5384136B2 - Failure analysis support system - Google Patents

Description

  The present invention provides a failure analysis support comprising: a failure detection device on which analysis target software is installed; and a failure detection device that detects a failure occurring in the target software based on information provided from the detection target device. About the system.

  Conventionally, in the technical field of computer systems, the CPU load is reduced, and the user-friendly execution log recording, the execution log display method, the computer system using the display method, and the display method are programmed and recorded. Proposals have been made for the purpose of providing such recording media. In this proposal, the state transition of the execution log of the program in the computer system is displayed in time series, and the width on the time axis is variable according to the frequency of occurrence of the state transition of the execution log per time. In addition to the application (program), the proposal includes a task with the lowest priority for checking whether or not an execution log once recorded in the log buffer is necessary, and records the result of the log check. By attaching an appropriate mark to the recorded log, only the log without the mark is transferred to another computer system (see, for example, Patent Document 1). In addition, in the above technical field, a method of analyzing a failure while performing step execution, a method of outputting debug information and analyzing it later are known (for example, see Non-Patent Document 1). In addition to the above, there is also known a method using a general event tracer for executing a trace for acquiring information related to a behavior to be analyzed (for example, see Non-Patent Document 2). Further, in addition to the above, a technique using a public tool for implementation when performing drawing is also known (see, for example, Non-Patent Document 3).

Japanese Patent Laid-Open No. 10-333938 Acquisition of execution history using SWAP mechanism (Information Processing Society of Japan [System Software and Operating System] Vol. 97, No. 20 (19970227)) Measuring and Characterizing System Behavior Using Kernel-LevelEvent Logging http://sourceforge.net/projects/timedoctor

In recent years, with the increase in the number of functions of so-called consumer devices (referred to as embedded devices or embedded home appliances (products)) such as mobile phone terminals and television receivers, the scale of software installed in the devices has also increased. It tends to increase. In general, as the scale of software increases, the number of potential bugs increases accordingly, and there is a high possibility that defects due to the presence of the potential bugs will occur after the product equipped with the software is shipped. Become. Therefore, in order to avoid such a situation, model-based development (representing the specifications in a model that can be simulated in software development, so that large-scale software development can be performed with high quality and high efficiency, Research on software development methodologies, such as a development method that consists of repeated verification and correction by model simulation within each process, is underway. In addition to the above methods, research on software development methodologies such as software product lines (methods for re-dividing software into small units called domains) is also underway. By developing a large-scale software by adopting the above-described model-based development or a software product line or the like, the number of occurrences of bugs in the large-scale software can be suppressed to some extent. However, adopting any of the above development methods does not completely eliminate bugs in the developed large-scale software. The reason is that even if a new development method as described above is introduced, past assets (conventional embedded devices and conventional software installed in the embedded devices) can be reused as they are on a large scale. One of the reasons is that it has potential bugs in order to develop simple software. In addition, the software to be developed is diverse because it is installed in many types of devices, and early development of many types of software is required by many software development engineers. This is a heavy burden for software development engineers. Therefore, the reason why the introduction of new development methods as described above has not been thoroughly implemented is also cited as the above reason.

  Conventionally, when a bug occurs in software, as a countermeasure, either a method of analyzing a failure while performing step execution as described in Non-Patent Document 1 described above, or a method of outputting debug information and analyzing it later Is used. However, if the former method is adopted, interactive analysis is performed, so that it is not suitable for debugging an application (program) having a time restriction represented by timing dependency or the like. In the former method, in order to reproduce the bug, if the condition that the location where the bug occurred is roughly known or the cause of the bug is not satisfied, By actually running the program over and over again, there is a drawback that the problem cannot be solved unless the cause of the bug is found by trial and error. On the other hand, when the latter method is employed, there is a problem that the analysis itself becomes difficult because the output information becomes enormous when the debug information required for analysis cannot be narrowed down. Therefore, as a countermeasure when the output information becomes enormous due to the latter method, the event log per hour is related to the event log display method of the computer system as described in Patent Document 1 described above. Proposal of a method that makes it easy to distinguish the display log by dynamically changing the time axis scale interval in the dense part and the time axis scale interval in the part where the event log per time is discrete. Has been.

  However, in the method according to the proposal, it is possible to improve the visibility of the display log by increasing the density of the scale of the time axis at a place where the density of the event log is low (that is, where the event log is a discrete part). Although it is possible, the amount of data to be analyzed is not reduced for the user. For this reason, if the target software trace lasts for a long time and the amount of event logs acquired increases accordingly, the time required for the user to analyze the acquired event logs also increases in proportion to the amount of event logs. I have to be. Therefore, there is a problem that the analysis time of a huge amount of event logs obtained as a result of long-time tracing by the user cannot be shortened.

  Therefore, an object of the present invention is to analyze the presence / absence of a fault on the software by the user, even if the amount of data acquired due to the trace of the software extending for a long time becomes huge. An object of the present invention is to provide a failure analysis support system that can reduce the time required to analyze a large amount of data.

  A failure analysis support system according to the present invention includes a failure detection device on which analysis target software is mounted, and a failure detection device that detects a failure that has occurred in the analysis target software based on information provided from the failure detection device. The failure detection apparatus has a trace execution unit that executes a trace of the analysis target software, and the failure detection apparatus is output from the failure detection apparatus by the trace execution unit. An information change unit that changes the information related to the traced software to be analyzed into information in a format with high analysis efficiency, and an information analysis that analyzes the information output from the information change unit based on the selected failure detection method Visualization of information obtained as a result of analysis by the information analysis unit, triggered by an information display output request from the user and the user Having an information visualization processing unit for displaying the output as information, a.

  In a preferred embodiment according to the present invention, the information analysis unit calculates a failure occurrence time in the analysis target software from a result of the analysis of the information.

  In an embodiment different from the above, the selected failure detection method is designated by the user from a plurality of failure detection methods set in advance.

  In an embodiment different from the above, the information to be changed by the information changing unit is information related to a trace result per fixed time by the trace execution unit.

  In an embodiment different from the above, the information visualization processing unit uses the information related to the name of the failure detection method specified by the user as a key, and the information changed by the information change unit into a format with high analysis efficiency. From the allocated information, the information related to the failure occurrence time in the analysis target software is extracted from the allocated information, and the information related to the trace result is extracted from the information related to the trace result based on the time information. Extract information in the vicinity of the fault detection location.

  Further, in an embodiment different from the above, the information visualization processing unit is output from the information in the vicinity of the fault detection location extracted from the information related to the trace result, and the information change unit. From the information that has been changed to a format with high analysis efficiency, a process for drawing the trace result in the vicinity of the location where the failure is detected, and the display of the visualized image information after the drawing process is highlighted Process to do.

  According to the present invention, when analyzing the presence or absence of a failure on the software by the user, even if the amount of data acquired due to the trace of the software is extended for a long time, the user It is possible to provide a failure analysis support system that can shorten the time required to analyze a large amount of data.

The functional block diagram which shows the whole structure of the failure analysis assistance system which concerns on one Embodiment of this invention. The functional block diagram which shows the internal structure of the failure detection part described in FIG. The functional block diagram which shows the internal structure of the visualization process part described in FIG. Explanatory drawing which shows an example of the data structure of the metadata produced | generated from CPU usage efficiency in the failure analysis assistance system described in FIG. Explanatory drawing which shows an example of the data structure of the metadata produced | generated from the CPU usage efficiency per process in the failure analysis support system described in FIG. Explanatory drawing which showed the one aspect | mode of the peak detection result visualized by the visualization process part described in FIG. The flowchart which shows an example of the sequence of the peak detection process by a failure detection process part at the time of detecting a peak location from the load of CPU.

  Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings.

  FIG. 1 is a functional block diagram showing the overall configuration of a failure analysis support system according to an embodiment of the present invention.

  As shown in FIG. 1, the failure analysis support system includes a target system 100 and a host computer (hereinafter referred to as “host device”) 300. The target system 100 and the host device 300 are connected via an intranet, a communication network such as the Internet, or the general so that both can directly receive an electrical signal transmitted from the other party. They are connected through (standard) signal lines.

  The target system 100 includes analysis target software 1, a trace execution unit 3, and a trace result transmission unit 5. Here, the target system 100 refers to a multifunctional consumer device (an embedded device such as a mobile phone terminal or a television receiver) as described above. The target system 100 incorporates hardware having information processing functions such as arithmetic processing, information storage, and information input / output, and the hardware is scaled up to realize the above-mentioned multi-function. Installed software. Therefore, the analysis target software 1 corresponds to the scaled-up software. The trace execution unit 3 is realized in hardware for arithmetic processing by software installed in the information storage hardware described above, and the trace result transmission unit 5 is realized in hardware for input / output of the information. The

  The trace execution unit 3 inputs the analysis target software 1 and executes a trace on the analysis target software 1 to obtain information on the behavior of the analysis target software 1 and also obtain the acquired information on the behavior. Then, it outputs to the trace result transmission unit 5 as information related to the trace result of the analysis target software 1. In the present embodiment, for the trace execution unit 3, for example, a general event tracer as disclosed in Non-Patent Document 1 is used. Further, as the trace execution unit 3, ICE (abbreviation of in-circuit emulator which is hardware for debugging. It has a function of controlling the CPU from the outside to stop the movement of the entire system and look inside the memory). The acquired general CPU program counter trace function may be used.

  The trace result transmission unit 5 receives information related to the trace result output from the trace execution unit 3 and transmits information related to the trace result to the host device 300.

  The host apparatus 300 executes analysis of the (analysis target) software 1 based on the trace information of the software operating on the system 100 output from the target system 100, that is, the analysis target software 1. The host device 300 includes a meta information recording unit 7, a trace result recording unit 9, a trace result writing unit 11, a trace result receiving unit 13, a meta information writing unit 15, a failure detection unit 17, and a visualization processing unit 19. And a user request collecting unit 21 and a user request holding unit 23. The hardware resources of the host device 300 corresponding to the meta information recording unit 7 and the trace result recording unit 9 are memories provided in the host device 300. In addition, the trace result writing unit 13, the meta information writing unit 15, the failure detection unit 17, the visualization processing unit 19, the user request collection unit 21, and the user request holding unit 23 are the above-described memories (that is, information storage hardware). It is realized in a CPU (that is, hardware for arithmetic processing) by software (application program) installed in the computer. The trace result receiving unit 13 is realized in an input / output interface (information input / output hardware) of the host device 300.

  The trace result receiving unit 13 receives information related to the trace result transmitted from the trace result transmitting unit 5 (of the target system 100), and outputs the received information related to the trace result to the trace result writing unit 11. To do. The trace result writing unit 11 inputs information related to the trace result output from the trace result receiving unit 13 and executes processing for writing the input information related to the trace result to the trace result recording unit 9. The trace result recording unit 9 holds information related to the trace result written by the trace result writing unit 11 and also holds the trace result held in response to a trace result read request from the failure detection unit 17. Is output to the failure detection unit 17 and the visualization processing unit 19, respectively.

  The user request collection unit 21 inputs information related to a plurality of types of failure detection methods output from the failure detection unit 17, and inputs the information related to the plurality of types of failure detection methods input, for example (of the host device 300 ) Output to a display unit, which is a man-machine interface under the control of the CPU, in a display mode recognizable by the user. When the user 24 inputs a command signal from the operation unit by operating the operation unit (of the host device 300) that is the man-machine interface, the user 24 collects the user request based on the command signal. It is determined which type of failure detection method (information related to) is designated from the information related to the plurality of types of failure detection methods displayed above. As a result of performing the determination process, the user request collection unit 21 designates a specific failure detection method (information related to) selected from the plurality of types of failure detection methods (information related to). The information is output to the user request holding unit 23 as the failure detection method (related information).

  The user request holding unit 23 holds, as a user request, the failure detection method (related information) specified by the user 24, which is output from the user request collecting unit 21, and also detects information related to the failure detection method as a failure detection method. The information is output to the failure detection unit 17 in response to a request for reading a failure detection method (information relating to) from the unit 17. The user request holding unit 23 also visualizes the failure detection technique (related information) held as a user request in response to a read request of the failure detection technique (related information) from the visualization processing unit 19. To the unit 19.

  The meta information recording unit 7 holds the meta information written by the meta information writing unit 15 (information related to failure and information related to analysis described later), and responds to a meta information read request from the visualization processing unit 19 The held meta information is output to the visualization processing unit 19.

  Information related to a plurality of types of failure detection methods is stored in the failure detection unit 17 in advance. For example, information related to the plurality of types of failure detection methods may be requested by a user at an appropriate timing such as when the host apparatus 300 is started. Output to the collection unit 21. The failure detection unit 17 inputs information related to the specified failure detection method output from the user request holding unit 23 and information related to the trace result output from the trace result recording unit 9. Then, based on the information related to the failure detection method, the information related to the trace result is analyzed to detect a failure occurring in the trace result. The failure detection unit 17 outputs the information related to the detected failure and the information related to the analysis of the trace result to the meta information writing unit 15.

  The meta information writing unit 15 inputs the information related to the failure output from the failure detection unit 17 and the information related to the analysis. Then, a process for writing the information related to the failure and the information related to the analysis into the meta information recording unit 7 as meta information is executed. The visualization processing unit 19 includes the meta information output from the meta information recording unit 7, information related to the trace result output from the trace result recording unit 9, and the specified information output from the user request holding unit 23. Information related to the failure detection method is input together. Then, based on the specified failure detection method, a process for visualizing (visualizing) a failure occurrence location and a nearby state on the analysis target software 1 derived from the meta information is executed.

  FIG. 2 is a functional block diagram illustrating an internal configuration of the failure detection unit 17 illustrated in FIG.

  As described above, the failure detection unit 17 performs the analysis recorded in the trace result recording unit 9 based on the information related to the failure detection method specified by the user 24 held in the user request holding unit 23. Information related to the trace result of the target software (1) is analyzed, and the occurrence time of the failure that occurred on the target software (1) is calculated from the analysis result. As shown in FIG. 2, the failure detection unit 17 includes a failure information detection method recording unit 25, a processing data storage unit 27, a failure detection method allocation unit 29, a trace result allocation unit 31, and a trace result processing unit 33. A failure detection processing unit 35.

  The failure information detection method recording unit 25 holds a plurality of types of failure detection processing programs corresponding to each of a plurality of types of failure detection methods, and a failure detection method from among the plurality of types of failure detection processing programs held above. The failure detection processing program assigned by the assigning unit 29 is output to the failure detection method assigning unit 29. The failure detection method assigning unit 29 inputs information related to the specified failure detection method output from the user request holding unit 23 and, based on the information related to the failure detection method, to the failure information detection method recording unit 25. Corresponding types of failure detection processing programs are allocated from the plurality of types of failure detection processing programs held. Then, the assigned one type of failure detection processing program is input from the failure detection method recording unit 25. The failure detection method assigning unit 29 outputs the one type of failure detection processing program input from the failure detection method recording unit 25 to the failure detection processing unit 35.

  The trace result assigning unit 31 executes the assignment process of the failure detection processing program by the failure detection method assigning unit 29, and then includes the information related to the trace result of the analysis target software 1 recorded in the trace result recording unit 9. From this, information related to the trace result per fixed time is read out until the processing related to the analysis target software 1 is completed. Then, the read information (related to the trace result per fixed time) is output to the trace result processing unit 33. The trace result processing unit 33 reads information related to the trace result per certain time output from the trace result assigning unit 31 and changes the information to information in a format with high analysis efficiency (ie, metadata). The information is written into the processed data storage unit 27 by the trace result processing unit 33. The processed data storage unit 27 temporarily holds the information written by the trace result processing unit 33 and stores the information in response to a data read request from the failure detection processing unit 35. Output to.

  The failure detection processing unit 35 reads the one type of failure detection processing program output from the failure detection method assigning unit 29 and also reads the information output from the machining data storage unit 27. Then, the read failure detection processing program is started, and a failure (data) detection process in the analysis target software 1 is executed based on the read information. The failure (data) detected by the failure detection processing unit 35 is output from the failure detection processing unit 35 to the meta information writing unit 15.

  FIG. 3 is a functional block diagram showing an internal configuration of the visualization processing unit 19 shown in FIG.

  As illustrated in FIG. 3, the visualization processing unit 19 includes a meta information allocation unit 37, a trace result allocation unit 39, a display location extraction unit 41, and a drawing execution unit 43. The meta information assigning unit 37 uses the information related to the failure detection method name (ie, the failure detection processing program name) designated by the display location extraction unit 41, which is output from the display location extraction unit 41, as a key. The corresponding meta information is allocated from among the meta information held in 7. The assigned meta information is output from the meta information assigning unit 37 to the display location extracting unit 41.

  The trace result assigning unit 39 uses the time information specified by the display location extracting unit 41 as a key to detect a failure that has occurred in the analysis target software 1 from the information related to the trace result held in the trace result recording unit 9. Allocate information related to the trace result near the location. Information relating to the assigned trace result is output from the trace result assigning unit 39 to the display location extracting unit 41. The display location extraction unit 41 reads the information related to the failure detection method specified by the user 24 output from the user request holding unit 23, that is, the failure detection processing program corresponding to the specification of the user 24, and the read failure Information relating to the detection processing program name is output to the meta information assigning unit 37 as information relating to the designated failure detection method name (by the user 24). The display location extraction unit 41 also reads the meta information output from the meta information assigning unit 37 and activates the failure detection processing program, so that a failure occurred in the analysis target software 1 from the meta information. The related time information is extracted, and the extracted time information is output to the trace result assigning unit 39. The display location extraction unit 41 further outputs the information related to the trace result assigned by the trace result assignment unit 39, which is output from the trace result assignment unit 39, to the extraction result related to the trace result in the vicinity of the failure detection location. Read as. The display location extraction unit 41 outputs the extraction result and the meta information to the drawing execution unit 43.

  The drawing execution unit 43 receives the extraction result output from the display location extraction unit 41 and the meta information, and based on the information, draws the trace result near the detection location of the failure, and A process for highlighting the detected part of the failure with respect to the result of the process is performed. The visualized information after the above processing is displayed and output from the drawing execution unit 43 to the screen display unit 45.

  In this embodiment, the implementation related to the drawing execution unit 43 is, for example, a visualization processing function as disclosed in Non-Patent Document 2 described above, or as disclosed in Non-Patent Document 3. The public tools themselves or equivalents shall be adopted.

  FIG. 4 is an explanatory diagram illustrating an example of a data structure of metadata generated based on CPU usage efficiency in the failure analysis support system illustrated in FIG. 1.

  The metadata includes a failure detection method information recording column 51, a time information recording column 53, a CPU usage rate information recording column 55, and a failure information registration column 57, as shown in FIG. The failure detection method information recording column 51 records the failure detection method designated by the user (24). In this embodiment, the failure detection method information recording column 51 records “CPU usage rate”. Yes. In the time information recording column 53, the time required when the CPU usage rate is actually measured using the failure detection technique “CPU usage rate” in the above system is recorded. In the present embodiment, “0, 1, 2, 3, 4, 5,..., N” is recorded in the time information recording field 53. The CPU usage rate information recording column 55 records the CPU usage rate at each time (time point) recorded in the time information recording column 53. In the present embodiment, in the CPU usage rate information recording column 55, “10%” is displayed at the locations corresponding to the time “0” and “1”, and “10” is displayed at the locations corresponding to the time “2”. “50%” is recorded at a location corresponding to time “3”, “80%” is recorded at a location corresponding to time “4”, and “90%” is recorded. In addition, “40%” is recorded at a location corresponding to the time “5”, and “20%” is recorded at a location corresponding to the time “n”. In the failure information registration column 57, a flag indicating whether or not a failure that has occurred in the analysis target software 1 is registered is registered. In the present embodiment, in the failure information registration column 57, the flag indicating that the occurred failure is registered is “ON” at the locations corresponding to the time “3” and the time “4”, respectively. .

  FIG. 5 is an explanatory diagram illustrating an example of a data structure of metadata generated based on CPU usage efficiency in process units in the failure analysis support system illustrated in FIG.

  As shown in FIG. 5, the metadata includes a failure detection method information recording column 61, a time information recording column 63, an operation process ID recording column 65, a CPU occupation time information recording column 67, and a failure information registration column 69. And including. The failure detection method information recording column 61 records a failure detection method designated by the user (24), similarly to the failure detection method information recording column 51 shown in FIG. 4, and in this embodiment, the failure detection method is recorded. In the information recording column 61, “CPU usage rate” is recorded. Similarly to the time information recording column 53 shown in FIG. 5, the time information recording column 63 is also used when the CPU usage rate is actually measured by using the failure detection method “CPU usage rate” in the above system. The time required is recorded. Each time information recorded in the time information recording column 63 is associated with each time information recorded in the time information recording column 53 shown in FIG. The operation process ID recording column 65 records the ID (that is, identification information) of a process that has been operating within the time recorded in the time information recording column 63. In the present embodiment, the operation process ID is recorded as an operation process ID. In the recording column 65, 3, 5, 1, 2, 4, 5 are recorded as IDs of processes that were operating at time “3”.

  The CPU occupation time information recording column 67 records CPU occupation times by individual processes identified by a plurality of IDs recorded in the operation process ID recording column 65. The CPU occupation time is time information. It shows which process occupies the CPU at which timing and which process within the time recorded in the recording field 63. In the present embodiment, 75 ms, 100 ms, 40 ms, 300 ms, 100 ms, 200 ms, 50 ms, 70 ms, 50 ms, and 15 ms are recorded in the CPU occupation time information recording column 67. The first 75 ms from the left side to the right side in FIG. 5 is the time that the process indicated by ID = 3 occupies the CPU, and the second 100 ms indicates that the CPU is idle. . The third 40 ms is the time that the process indicated by ID = 5 occupies the CPU, and the fourth 300 ms is the time that the process indicated by ID = 1 occupies the CPU. The fifth 100 ms indicates that the CPU is in an idle state, and the sixth 200 ms is the time during which the process indicated by ID = 1 occupies the CPU. The seventh 50 ms is the time that the process indicated by ID = 2 occupies the CPU, and the eighth 70 ms is the time that the process indicated by ID = 4 occupies the CPU. Furthermore, the ninth 50 ms indicates that the CPU is in an idle state, and the tenth 15 ms is a time during which the process indicated by ID = 5 has occupied the CPU.

  Similarly to the failure information registration field 57 shown in FIG. 4, the failure information registration field 69 also registers a flag for indicating whether or not a failure that has occurred in the analysis target software 1 is registered. In the present embodiment, in the failure information registration field 69, the flag indicating that the occurred failure is registered is “ON” at the location corresponding to the fourth 300 ms at the time “3”. .

  FIG. 6 is an explanatory diagram showing an aspect of the peak detection result visualized by the visualization processing unit 19 shown in FIG.

  In the peak detection result shown in FIG. 6, FIG. 6A is a visual image (graphed) of the metadata shown in FIG. 4. In FIG. 6A, the vertical axis indicates that the defined image files (that is, the CPU usage rate described in an easy-to-understand manner in the program, which is indicated by a staircase waveform) are superimposed. The horizontal axis is the time axis (t). An area 71 that is an area surrounded by an ellipse indicates a location of a failure that has occurred in the analysis target software 1 described above. The ellipse means emphasis (location).

  In the peak detection result shown in FIG. 6, FIG. 6B is a part of the metadata shown in FIG. 4 (that is, the metadata shown in FIG. 6A). The metadata shown in FIG. (Graphed). In FIG. 6B, the vertical axis indicates IDLE and PID1 to PID5 (that is, the above-described defined image files are superimposed), and the horizontal axis indicates 0, 200, 400. , 600, 800, 1000, and 1200 are set. An area 73 that is an area surrounded by an ellipse indicates the location of the failure that has occurred in the analysis target software 1 as described above. It should be noted that the drawing of the region 73 (that is, the emphasized portion) can be realized by performing a process of superimposing the defined image files around the time information described above.

  FIG. 7 is a flowchart showing an example of a sequence of peak detection processing by the failure detection processing unit 35 when detecting a peak location from the load of the CPU. The flowchart shown in FIG. 7 relates to a method for detecting a CPU usage rate soaring (peak), which is one of the performance problems that can occur in the analysis target software 1. The processing operation shown in the flowchart of FIG. 7 is for batch processing of the entire data to be processed, or for split processing in which the data to be processed is divided into unit times and processing is performed for each divided data. , Respectively.

  In FIG. 7, the failure detection processing unit 35 first reads data for one event from the trace data stored in the processed data storage unit 27 from the processed data storage unit 27 (step S81). Next, it is checked whether the read data for one event is the head data (step S82). As a result of the check, if it is determined that the data is the top data (YES in step S82), the failure detection processing unit 35 relates to the event occurrence time recorded in the data for the one event determined to be the top data. The information is recorded in a predetermined storage area as the start time (step S83), and the process proceeds to the next step S84. Further, when it is determined that the data is not the top data as a result of the check in step S82 (NO in step S82), the process immediately proceeds to the processing operation shown in step S84.

  Next, it is checked whether the data for one event read in step S81 is the final data of the trace data described above (step S84). If it is determined as a result of this check that the data is not the final data of the trace data (NO in step S84), it is checked whether the data for one event read in step S81 is a process switching event. Here, the process refers to a process viewed at the OS level, and refers to one processing unit viewed from the OS (step S85). As a result of the check, if it is determined that the event is not a process switching event (NO in step S85), the process proceeds to the processing operation shown in step S81. On the other hand, if it is determined as a result of the check that the event is a process switching event (YES in step S85), the process proceeds to the next step S86.

  Next, the failure detection processing unit 35 checks whether the data for one event read in step S81 is the first process switching event (step S86). As a result of the check, if it is determined that the event is the first process switching event (YES in step S86), the process proceeds to the next step S87. That is, the failure detection processing unit 35 calculates the execution time (of the first process switching event) from the start time recorded in step S83 and the occurrence time of data for one event read in step S81, and The calculated execution time is stored in a predetermined storage area, and the process proceeds to the next step S89 (step S87).

  On the other hand, if it is determined as a result of the check that the event is the first process switching event (NO in step S86), the process proceeds to the next step S88. That is, the failure detection processing unit 35 calculates the execution time (of the first process switching event) from the start time of the process being executed and the generation time of the data for one event read in step S81. The calculated execution time is stored in a predetermined storage area, and the process proceeds to the next step S89 (step S88). Next, the failure detection unit 35 executes a process of recording the ID (n) of the start process after switching recorded in the first process switching event that has been read in a predetermined storage area ( Step S89). When the processing is completed, the failure detection unit 35 next processes the occurrence of the data for one event read in step S81 and the process in which ID (n) is recorded in a predetermined storage area in step S89 (ie, switching) A process of recording in a predetermined storage area is executed as the start time of the subsequent start process (step S90), and when the process ends, the process proceeds to the process operation shown in step S81.

  Then, it is checked whether the data for one event read in step S81 is the final data of the trace data described above (step S84). If it is determined as a result of the check that the data is the final data of the trace data (YES in step S84), the failure detection unit 35 refers to the CPU usage rate and the trace execution time recorded for each process unit. Then, the CPU usage rate for each process is calculated (step S91). Next, a process for calculating the CPU usage rate of the entire system is executed from the CPU usage rate for each process calculated in step S91 (step S92). When the above processing is completed, the failure detection unit 35 then obtains a peak CPU usage rate from the CPU usage rate for each process obtained in step S91 and the CPU usage rate for the entire system obtained in step S92. A process for determining (detecting) is executed. For this processing method, any method set by the user (24) may be used. For example, a method for obtaining a peak of CPU utilization from the top 10 locations with high CPU utilization, or sampling only CPU utilization exceeding a preset threshold, and using those sampled CPUs A method for obtaining the CPU usage rate from the rate can be assumed (step S93). The peak data of the CPU usage rate generated through the above process is output from the failure detection unit 35 to the meta information writing unit 15 (step S94), whereby the series shown in FIG. This processing operation ends.

  The preferred embodiment of the present invention has been described above, but this is an example for explaining the present invention, and the scope of the present invention is not limited to this embodiment. The present invention can be implemented in various other forms.

DESCRIPTION OF SYMBOLS 1 Analysis object software 3 Trace execution part 5 Trace result transmission part 7 Meta information recording part 9 Trace result recording part 11 Trace result writing part 13 Trace result receiving part 15 Meta information writing part 17 Failure detection part 19 Visualization processing part 21 User request collection Unit 23 user request holding unit 25 fault information detection method recording unit 27 processing data storage unit 29 fault detection method allocation unit 31 trace result allocation unit 33 trace result processing unit 35 fault detection processing unit 37 meta information allocation unit 39 trace result allocation unit 41 Display location extraction unit 43 Drawing execution unit 45 Screen display unit 100 Target system 300 Host device

Claims (2)

A failure detection device in which analysis target software is installed, a failure detection device that detects a failure that occurred in the analysis target software, based on information provided from the failure detection device;
With
The fault detected device is
A trace execution unit for executing a trace of the analysis target software;
Have
The failure detection device is
An information changing unit that changes information related to the trace result related to the analysis target software traced by the trace execution unit, which is output from the failure detected apparatus, into information in a format with high analysis efficiency;
Based on the selected failure detection method, an information analysis unit that analyzes information output from the information change unit,
Triggered by an information display output request from the user, an information visualization processing unit that displays and outputs information obtained as a result of analysis by the information analysis unit as visualized information;
I have a,
The information visualization processing unit assigns corresponding information from the information changed to a format with high analysis efficiency by the information changing unit, using information related to the name of the failure detection method designated by the user as a key, From the assigned information, information related to the failure occurrence time in the analysis target software is extracted, and based on the time information, information on a part in the vicinity of the failure detection location is extracted from the trace result related to the analysis target software. A failure analysis support system to draw out. The failure analysis support system according to claim 1 ,
The information visualization processing unit outputs the information in the vicinity of the fault detection location extracted from the information related to the trace result related to the analysis target software , and the analysis efficiency output format output from the information change unit. A failure for performing processing for drawing a trace result in a portion near the location where the failure is detected from the changed information and processing for highlighting the visualized image information after the drawing processing is performed Analysis support system.

Images