WO2011161835A1

WO2011161835A1 - Method and device for causal analysis of configuration changes

Info

Publication number: WO2011161835A1
Application number: PCT/JP2010/061563
Authority: WO
Inventors: 恵美子小林; 裕工藤; 公徳菅内; 哲也増石; 高広藤田; 能嗣小野
Original assignee: 株式会社日立製作所
Priority date: 2010-06-21
Filing date: 2010-07-07
Publication date: 2011-12-29
Also published as: JP2012003647A; JP5417264B2

Abstract

A computing system comprises a plurality of target computers and an analysis computer, wherein one or more of a first target computer on which a prescribed application is already installed and running, sends a log which includes information on the plurality of configuration changes which took place before the prescribed application was started to the analysis computer; the analysis computer receives the log and calculates for each type of configuration change the startup failure rate which is the rate at which the prescribed application start has failed after the configuration change, on the basis of the log. Then, a second target computer receives from the analysis computer first information which includes the startup failure rate for each type of configuration change with respect to the prescribed application and shows on the basis of the startup failure rate the type of configuration change which is the cause of the failure of startup of the prescribed application.

Description

Method and apparatus for causal analysis configuration change

The present invention relates generally to cause analysis within a computer, and more particularly to cause analysis with configuration changes to find solutions to application failures without using a knowledge database by analyzing configuration changes. .

One of the most stressful tasks for desktop computing environment managers is the cause analysis (troubleshooting) of cases where trouble occurs. Cause analysis is also crucial for help desk personnel who need to provide a solution to the caller. End users tend to install many types of software or change OS settings, which can cause problems. In addition, because many automatic upgrade programs run routinely within the end user's computer, the configuration of the computer can be changed without the end user's awareness. Thus, the end user may not know when the configuration has become faulty and may not remember when the problem has occurred. Administrators or help desk personnel in such desktop computing environments need to use their expertise to gain a deep understanding of the background of the trouble in order to provide a solution to the end user.

Current solutions include, for example, technology that remotely examines event logs in computers, technology that collects and stores configuration items and their change history, technology that detects application launches, and stores those launch histories , Technologies that store knowledge in past solutions, and technologies that deduct the root cause by combining the information described above.

Patent Document 1 is an example in which a root cause is deduced by an event log, a configuration change, and a knowledge database. Paragraph 0134 discloses the collection of error log, event information, and configuration change time series data from the target monitoring computer. Paragraph 0137 and FIGS. 16, 17, and 18 disclose a comparison of error conditions on the target computer with those in past data.

Examples of remotely collecting event logs include Patent Document 2 and Patent Document 3. Patent Document 4 is an example of failure analysis using a knowledge base. Patent document 5 is an example of failure analysis using an error log. Patent document 6 is an example which acquires a configuration change remotely.

[Correction based on Rule 91 15.12.2010]
JP 2007-293393 A US Pat. No. 6,289,379 US Pat. No. 5,857,190 US Pat. No. 6,012,152 US Pat. No. 6,598,179 US Patent Application Publication No. 2007/0214193 A1

Administrators or help desk personnel need the kind of knowledge to provide solutions by reviewing the event log, configuration change history, application launch history, or the like. Knowledge can be acquired from a knowledge database that provides "causes" and "solutions" described by others. This requires maintenance costs because someone needs to keep the knowledge database up to date.

Another object of the present invention is to provide software problem analysis information related to a configuration change without using a knowledge database when the end user makes a configuration change.

The exemplary embodiment of the present invention provides a technique for determining which configuration changes caused problems without the need for a knowledge database. Thus, the present invention does not provide a root cause but provides an “acceptability limit” (ie, final answer) that needs to be removed. The present invention provides a direct way of dealing with solution-oriented problems rather than "root cause" orientation.

The end user makes an inquiry. The help desk begins the analysis. The target period is detected in the first step. For detection of the target period, the cause analysis program detects the last success of the application launch and the first failure of the application launch based on both the event log and the application launch history. Regarding the configuration change detection, the configuration change is determined by a combination of the configuration change history and the target period detection result. These configuration changes may have affected application startup. One of these configuration changes is an acceptable limit. The next step is checking other computers. To determine the configuration change that is most likely the cause, the cause analysis program checks other computers that have experienced the same configuration change. The cause analysis program checks and counts the results of application startup before and after each configuration change. If the same configuration change is found in the other computer, the program checks whether each configuration change caused the same problem or repaired in that computer. The program counts similar cases for all computers. Subsequently, the program calculates the ratio of instances with a change from success to failure and the ratio of instances with a change from failure to success for all instances for each configuration change. The cause analysis program then displays the results. The results of the analysis are shown in a ranking format using a chart. The help desk can answer questions about which configuration changes are most susceptible.

The present invention does not use any knowledge database described by humans. Even if the user knows the root cause, the user may not know how to easily repair it, and therefore does not seek to find the root cause. Instead, the present invention identifies acceptable limits. What the user should do is remove the tolerance limit. For the user, fixing the problem is more effective than telling the root cause.

Aspects of the present invention are directed to a method of causal analysis for a target computer of a plurality of computers, wherein the target computer indicates an application launch failure of a computer application upon a first failure, a first With successful application launch of the computer application at the first success time preceding the failure of the computer application, with successful launch of the other application of the computer application within a first time period between the first success time and the first failure time. Without any other application startup failure (see, for example, FIG. 14). The method includes (1) identifying one or more first configuration changes that occurred during a first time period of a computer application, and (2) a causal configuration change analysis (A) or repair configuration Performing at least one of change analysis (B). Analysis (A) shows that for each of all other computers of the plurality of computers except the target computer, each of the other computers is the application of the same computer application at the second success. The activation success is the same as the application activation failure of the same computer application in the second failure after the second success in the second time period between the second success and the second failure. Identifying other application launch failure instances that the computer application is experiencing without other application launch successes and without other application launch failures, and for a second time period One or more second structures generated in Identifying the change and obtaining a total causal configuration change count for each of the one or more second configuration changes by summing for all of the plurality of computers except the target computer. (For example, see FIG. 17). Analysis (B) shows that for each of all other computers of the plurality of computers other than the target computer, each of the other computers is the application of the same computer application at the time of the third failure. The launch failure of the same computer application at the third success time after the third failure is the same within the third time period between the third failure time and the third success time. Identifying an instance of a successful application launch that occurs without other successful application launches of the computer application and without any other failed launch of the application, and occurs during a third time period One or more third configuration changes Identifying and obtaining a total number of repair configuration changes for each of the one or more third configuration changes by summing for all of the plurality of computers except the target computer (eg, (See FIG. 19).

Another aspect of the present invention is directed to a cause analysis system, which includes a plurality of computers including a target computer, and an analysis computer connected to the plurality of computers. The analysis computer is programmed to perform steps (1) and (2) above. In some embodiments, the analysis computer is one of the plurality of computers (see, eg, FIG. 25).

Another aspect of the present invention is directed to a computer readable storage medium storing a plurality of instructions for controlling a data processor to perform steps (1) and (2) above.

In some embodiments, the method further includes presenting a result for at least one of the causal configuration change result (A1) or the repair configuration change result (B1). In step (A1), the method includes, for each of the one or more second configuration changes, the number of application launch failure instances identified for each of the other computers, and all the other computers. Including listing the number of all instances with each of one or more second configuration changes for each of them (see, eg, FIG. 10). In step (B1), the method includes, for each of one or more third configuration changes, the number of instances of successful application launch identified for each of all the other computers, and all the other computers. Including listing the number of all instances with each of one or more third configuration changes for each of them (see, eg, FIG. 12).

In some embodiments, steps (1) and (2) are performed for multiple computer applications. The method further includes presenting a result for at least one of the cause configuration change result (A2) or the repair configuration change result (B2) for each of the plurality of computer applications. In step (A2), the method includes, for each of the one or more second configuration changes, the number of application launch failure instances identified for each of the other computers, and all the other computers. Listing the number of all instances with each of the one or more second configuration changes for each of the and the date and time analyzed for each of the plurality of computer applications (eg, (See FIG. 21). In step (B2), the method includes, for each of one or more third configuration changes, the number of instances of successful application launch identified for each of all the other computers, and all the other computers. Listing the number of all instances with each of the one or more third configuration changes for each of the and the date and time analyzed for each of the plurality of computer applications.

In certain embodiments, the method further includes performing at least one of a consistent cause configuration change analysis (A3) or a consistent repair configuration change analysis (B3) for the specified computer application. In step (A3), the method searches the result of (A2) for the computer application that matches the designated computer application as a matching cause configuration change result, and analyzes the matching cause configuration change result for analysis. (See, for example, FIG. 22). In step (B3), the method retrieves the result of (B2) for the computer application that matches the specified computer application as a matching repair configuration change result and analyzes the matching repair configuration change result for analysis. Including taking out.

In some embodiments, the method further includes performing at least one of a combination cause configuration change analysis (C) or a combination repair configuration change analysis (D). In step (C), for each of all other computers except the target computer of the plurality of computers, each of the other computers has the same computer application on the fourth success. Application launch success is the same as the application launch failure of the same computer application at the fourth failure after the fourth success within the fourth time period between the fourth success and the fourth failure. Identifying instances of other application launch failures that are experienced without other application launch successes and without other application launch failures of the computer application, and for a fourth time period Fourth configuration change that occurred in the meantime Identifying one or more combinations and obtaining a total causal configuration change count for each of the fourth configuration change combinations by summing all of the plurality of computers except the target computer. Included (see, for example, FIG. 24). In step (D), for each of all other computers except the target computer of the plurality of computers, each of the other computers has the same computer application at the time of the fifth failure. Application launch failure is the same in the fifth time period between the fifth failure time and the fifth success time in the fifth success time after the fifth failure. Identifying an instance of successful application launch that is experienced without other application launch successes and without other application launch failures of the computer application, and during a fifth time period One of the fifth configuration changes that occurred Or by identifying a plurality of combinations and summing the total number of repair configuration changes for each of the one or more fifth configuration changes for all of the plurality of computers except the target computer. Including that.

In some embodiments, the method further includes presenting a result for at least one of the combination cause configuration change result (C1) or the combination repair configuration change result (D1). In step (C1), the method includes, for each one or more combinations of the fourth configuration change, the number of application launch failure instances identified for each of all the other computers, and all the other Listing the number of all instances with each of the one or more combinations of the fourth configuration changes for each of the computers. In step (D1), the method includes, for each of one or more combinations of the fifth configuration change, the number of successful application launch instances identified for each of all the other computers, and all the other Listing the number of all instances with each of one or more combinations of the fifth configuration change for each of the computers.

Another aspect of the invention is directed to a method in a computer system for performing a cause analysis for a target computer of a plurality of computers, wherein the target computer is a computer at a first failure. An application launch failure of the application at a first success time preceding the first failure, an application launch success of the computer application within a first time period between the first success time and the first failure time The computer application has experienced no other application startup success and no other application startup failure. The method includes: one or more first configuration changes that occurred during a first time period of the computer application; and each first configuration change of the one or more first configuration changes. Presenting a causal configuration change table listing corresponding pictorial charts having pictorial charts having failure rate areas and success rate areas. The failure rate area indicates that, for each of all the computers other than the target computer among the plurality of computers, each of the other computers has successfully started the same computer application at the second success time. The application launch failure of the same computer application at a second failure after the second success is detected within the second time period between the second success and the second failure. A representation of failure cases identifying instances of other application launch failures that are experienced without other application launch successes and without other application launch failures are shown. During the second time period, a second configuration change occurs that is equal to the corresponding first configuration change listed on the table. The success rate area indicates that each of all the other computers except the target computer among the plurality of computers has successfully started the same computer application at the time of the third success. For the same computer application in the third time period between the third success time and the third failure time. An expression of a success case that identifies an instance other than the other application activation failure instances experienced without other application activation successes and without other application activation failures is shown. During the third time period, a third configuration change occurs that is equal to the corresponding first configuration change listed on the table.

In some embodiments, the above chart includes a bar graph, and the failure rate area is the percentage of failure cases as compared to the number of failure cases or the total number of both failure cases and success cases. The failure success area indicates at least one of the number of success cases or the percentage of success cases as compared to the total number of both failure cases and success cases. The cause configuration change table includes a configuration item and a change type of one or more first configuration changes, a change date and time corresponding to one or more first configuration changes, and a failure rate area and a success rate area. List the pictorial charts shown. The method further includes presenting a user with a sort key index for sorting the cause configuration change table according to any one of the configuration item, the change type, the change date and time, and the failure rate of the pictorial chart. And presenting a cause configuration change table rearranged according to the selection entered by the user in response to the selection of the sorting key index entered by the user.

These and other features and advantages of the present invention will become apparent to those skilled in the art upon review of the following detailed description of specific embodiments.

FIG. 2 is a block diagram illustrating an example of a hardware configuration for a client-server architecture in which the method and apparatus of the present invention can be applied. FIG. 2 is a block diagram illustrating an example of functional blocks of the present invention applied to the architecture of FIG. 1. It is explanatory drawing which shows the example of the relationship between the application starting result which illustrated the basic concept of this invention, and a structure change. It is explanatory drawing which showed the example of the user interface of a cause analysis program. It is explanatory drawing which showed the example of the result screen of a cause analysis program. It is explanatory drawing which showed the example of the event log table resident in an analysis computer. It is explanatory drawing which showed the example of the structure change log | history table resident in an analysis computer. It is explanatory drawing which showed the example of the application starting history table resident in the analysis computer. It is explanatory drawing which showed the example of the cause structure change temporary table resident in the analysis computer according to the 1st embodiment of this invention. It is explanatory drawing which showed the example of the cause structure change table resident in an analysis computer. It is explanatory drawing which showed the example of the repair structure change temporary table resident in an analysis computer. It is explanatory drawing which showed the example of the repair structure change table resident in an analysis computer. 6 is a flowchart illustrating an example of log collection executed by a log collection program resident in an analysis computer. It is the flowchart which illustrated the cause analysis by the example performed by the cause analysis program resident in the analysis computer according to the 1st embodiment of this invention. 6 is a flowchart illustrating an example of a target period detection process performed by target period detection residing in an analysis computer. It is the flowchart which illustrated the process which checks the application starting result performed by the starting result checker resident in an analysis computer as an example. 2 is a flowchart illustrating by way of example a cause configuration change analysis process performed by a cause configuration change analysis resident in an analysis computer in accordance with the first embodiment of the present invention. It is the flowchart which illustrated the subroutine of the cause structure change analysis process of FIG. 17 as an example. FIG. 6 is a flow chart illustrating, by way of example, a repair configuration change analysis process performed by a repair configuration change analysis resident in an analysis computer. 20 is a flowchart illustrating an example of a subroutine of the repair configuration change analysis process of FIG. 19. It is explanatory drawing which showed the example of the cause structure change table according to the 2nd embodiment of this invention. It is the flowchart which illustrated the cause analysis by the example performed by the cause analysis program according to the 2nd embodiment of this invention. It is explanatory drawing which showed the example of the cause structure change table according to the 3rd embodiment of this invention. 6 is a flowchart illustrating an example of a cause configuration change analysis process executed by a cause configuration change analysis according to a third embodiment of the present invention. It is explanatory drawing which illustrated the example of the structure of the hardware architecture of the whole system, a software module, and a table according to the 4th Embodiment of this invention. It is the block diagram which illustrated the example of the functional block of the analysis computer and target computer agent in a 5th embodiment. It is the flowchart which illustrated an example of the process of the totalization program in a 5th embodiment. It is explanatory drawing which showed the example of the user interface which provides the problem information of the agent in a 5th embodiment. It is explanatory drawing which showed the example of the user interface which provides the countermeasure information of the agent in a 5th embodiment. It is explanatory drawing which showed another example of the user interface which provides the problem information of the agent in a 5th embodiment. It is the flowchart which illustrated an example of the process of the totalization program in a 6th embodiment. It is the flowchart which illustrated an example of the process of the cause analysis program in a 6th embodiment.

In the following detailed description of the present invention, reference is made to the accompanying drawings that form a part hereof, and in which is shown by way of illustration, and not by way of limitation, exemplary embodiments in which the invention may be practiced. In the drawings, like numerals describe substantially similar components throughout the several views. It should be further noted that this detailed description is set forth below and provides various exemplary embodiments as illustrated in the drawings, which are described and illustrated herein. The present invention is not limited to the embodiments described, and can be extended to other embodiments as known or will be known to those skilled in the art. When this specification refers to "one embodiment", "this embodiment", or "these embodiments", the particular features, structures, or characteristics described with respect to the embodiments are at least The appearances of these phrases in various places in this specification, which are meant to be included in one embodiment, do not necessarily all refer to the same embodiment. In addition, in the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the present invention. However, as will be apparent to those skilled in the art, all of these specific details may not be required to practice the present invention. In other circumstances, well-known structures, materials, circuits, processes, and interfaces have not been described in detail and / or illustrated in block diagram form in order not to unnecessarily obscure the present invention. Have been.

Furthermore, some parts of the detailed description below are given in the form of algorithms and symbolic representations of operations within a computer. These algorithmic descriptions and symbolic representations are the means used by those skilled in the data processing arts to most effectively convey the essence of their innovation to others skilled in the art. An algorithm is a series of predefined steps that lead to a desired outcome or result. In the present invention, the steps performed require a perceptible amount of physical manipulation to achieve a perceptible result. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals or instructions capable of being stored, transferred, combined, compared, and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, instructions, or the like. It should be borne in mind, however, that all of these and similar terms are associated with the appropriate physical quantities and are merely convenient labels applied to those quantities. Unless otherwise noted, the terms “processing”, “computing”, “calculation”, “decision”, “display”, or the like are used throughout this description, as will be apparent from the discussion below. Manipulated data represented as physical (electronic) quantities in computer system registers and memory, and in computer system memory or registers or other information storage, transmission, or display devices It is recognized that it may include the operations and processes of a computer system or other information processing device that translates into other data that is similarly represented as a physical quantity.

The present invention also relates to a device for performing the operations in this. The apparatus may include one or more general-purpose computers that are specially configured for the required purpose or that are selectively activated or reconfigured by one or more computer programs. It can be. Such computer programs may include, but are not limited to, optical disks, magnetic disks, read-only memory, random access memory, solid state devices and drives, or any other type of medium suitable for storing electronic information, etc. In a computer readable storage medium. The algorithms and displays given here are essentially unrelated to any particular computer or other device. A variety of general purpose systems may be used with programs and modules in accordance with the teachings herein, or it may prove advantageous to construct a more specialized apparatus that performs the desired method steps. In addition, the present invention is not described with reference to any particular programming language. As will be appreciated, a variety of programming languages may be used to implement the teachings of the invention as described herein. The programming language (s) instructions may be executed by one or more processing devices, eg, a central processing unit (CPU), processor, or controller.

Exemplary embodiments of the present invention provide an apparatus, method, and computer for finding solutions to application failures by analyzing configuration changes without the use of a knowledge database, as described in more detail below.・ Provide programs.

A. First Embodiment System Configuration FIG. 1 illustrates an example of a hardware configuration for a client-server architecture in which the method and apparatus of the present invention can be applied. An analysis computer 101 and a plurality of target computers 102 are connected through a LAN 103. The analysis computer 101 is a general-purpose computer including a CPU 111, a memory 112, a disk 113, a video interface 114, and a network interface 115. Each element is connected through a system bus 116. The analysis computer 101 has a cause analysis program 121 and a log collection program 122 in its memory 112. The cause analysis program 121 includes a target period detection 131 executed by the CPU 111, a cause configuration change analysis 132, a repair configuration change analysis 133, and an activation result checker 134. The analysis computer 101 has a cause configuration change temporary table 144, a repair configuration change temporary table 145, a cause configuration change table 146, a repair configuration change table 147, and log information 123 in the disk 113. The log information 123 includes an event log table 141, an application activation history table 142, and a configuration change history table 143. The analysis computer 101 has a network interface 115 connected to the LAN 103 and used for collecting log information 171 from a plurality of target computers 102. A display 117 is connected to the video interface 114 and is used for displaying the result of the cause configuration change analysis by the user interface of the cause analysis program 121 and the cause analysis program 121.

The target computer 102 is a general-purpose computer including a CPU 151, a memory 152, a disk 153, a video interface 154, and a network interface 155. Each element is connected through a system bus 156. The target computer 102 has an agent 161 that transmits log information 171 to the analysis computer 101 via the LAN 103. The target computer 102 has log information 171 in its disk 153. A display 157 is connected to the video interface 154.

FIG. 2 illustrates an example of a functional block diagram of the present invention applied to the architecture of FIG. The log collection program 122 is resident in the analysis computer 101, collects log information 171 by communicating with each agent 161 resident in the target computer 102, and collects the information as an event of the log information 123 in the analysis computer 101. Store in the log table 141, the application activation history table 142, and the configuration change history table 143.

The cause analysis program 121 reads the log information 123 and executes cause configuration change analysis as shown below. The target period detection 131 reads the event log table 141, the application activation history table 142, and the configuration change history table 143, and when the specific application can be activated without any problem and when the application could not be activated without any problem ( = Detect the period between times) Thereafter, the target period detection 131 determines a configuration change on the target computer within the period by referring to the configuration change history table 143. The cause configuration change analysis 132 checks the log information 123 of other computers and stores the result in the cause configuration change table 146. The cause configuration change temporary table 144 is used as temporary data when the cause configuration change analysis 132 analyzes the cause configuration change.

The repair configuration change analysis 133 detects the repair configuration change and stores the result in the repair configuration change table 147. The repair configuration change temporary table 145 is used as temporary data when the repair configuration change analysis 133 analyzes the repair configuration change. The repair configuration change is a configuration change for repairing a problem situation such as an application activation failure. The activation result checker 134 is a subroutine for detecting whether or not a specific application has been successfully activated by referring to both the event log table 141 and the application activation history table 142.

FIG. 3 shows examples 301 to 304 of the relationship between the application startup result and the configuration change illustrating the basic concept of the present invention.

Schematic 301 shows the status of the target computer 102 for this cause configuration change analysis. According to diagram 301, there are four configuration changes between a successful application launch and a failed launch. There are no other launches between these configuration changes. Thus, application launch failure may have occurred due to one of these four configuration changes. Diagrams 302, 303, and 304 show other computer situations that will be used for detailed analysis.

According to Scheme 302, the same configuration change has occurred on another computer A, but the deletion of “VPN-CLIENT v1.8” and the addition of “VPN-CLIENT v2.0” both affect the startup of the application. Not give. Therefore, the certainty that these two configuration changes affected the activation of the application is lower. In contrast, the addition of “PRINTER DRIVER A” and “PATCH-2322” has resulted in success and failure. Therefore, the certainty that these two configuration changes have affected the activation of the application is higher.

According to Scheme 303, the addition of “PRINTER DRIVER A” has resulted in success and failure. Therefore, the degree of certainty that the configuration change has affected the activation of the application is further increased. In addition, the deletion of “PRINTER DRIVER A” after failure has resulted in a failure and success. Therefore, it seems that the deletion of “PRINTER DRIVER A” repaired the problem. There is a higher degree of certainty that this configuration change would have repaired the launch of the application. In addition, the addition of “PATCH-2322” has resulted in success and success, so the confidence that this configuration change has affected the launch of the application is lower.

According to Scheme 304, the addition of “PATCH-1234” is between failure and success, so the addition of “PATCH-1234” seems to have repaired the problem. This type of observation can lead to two types of results. One is the certainty as to which configuration change has affected the activation of the application. The other is the certainty as to which configuration changes can repair application launch problems (failures). Although the number of other computers in this example is three, the accuracy of the analysis can be made higher by increasing the number of other computers.

2. User Interface of Analysis Program FIG. 4 shows an example of the user interface 401 of the cause analysis program 121. The user can start the analysis by using this user interface 401. The cause analysis program user interface 401 has two text boxes for inputting analysis conditions. One is a computer ID 411, which can be used by the user to specify the identifier of the analysis target computer. The other is the application name 412, which can be used by the user to specify the application name that has the problem. The user can start analysis by pressing an “analysis start” button 413.

FIG. 5 shows an example of the result screen of the cause analysis program 121. Possible cause configuration changes are displayed in a ranking format in the upper pane. A column 511 shows configuration items. Column 512 shows the change type. Column 513 shows the date and time corresponding to the configuration change (ie, 511 and 512). FIG. 5 shows four configuration change records 521-524. A column 514 shows a bar graph indicating the certainty factor corresponding to the configuration change. An area 525 indicates the number of configuration changes (“PRINTER DRIVER A”-“addition”) in the record 521 that has affected the activation of the specified application in all computers. An area 526 indicates the number of configuration changes (“PRINTER DRIVER A” — “addition”) that did not affect the activation of the specified application in all computers. The percentage above the bar graph indicates the ratio of 525 to 526. A symbol 515 is an index of the rearrangement key. In this example, these configuration changes are shown in the order of rate (confidence) instead of number. This indicator can be moved to another column by clicking the link (underline) in each column.

• Possible repair configuration changes are displayed in a ranked format in the lower pane. A column 531 shows configuration items. Column 532 shows the change type. A column 533 shows a bar graph indicating the certainty factor corresponding to the configuration change. FIG. 5 shows three configuration change records 541-543. An area 544 indicates the number of cases of configuration change ("PRINTER DRIVER A"-"deleted") in the record 541 in which the start failure of the application specified in all computers is repaired. An area 545 indicates the number of configuration changes ("PRINTER DRIVER A"-"deleted") that have not repaired the failure to start the designated application in all computers. The percentage above the bar graph indicates the ratio of 544 and 545. A symbol 534 is an index of the rearrangement key. In this example, these configuration changes are shown in the order of rate (confidence) instead of number.

3. Data Structure FIG. 6 shows an example of an event log table 141 that resides in the analysis computer 101. The event log data in this table is used to determine whether the specified application has been successfully launched. The activation result checker 134 checks the number of events immediately after the application is activated. When several events are found within a specific period immediately after activation, the activation result checker 134 determines that activation of the application has failed.

The event log table 141 includes three columns of computer ID (601), date and time (602), and event type (603). The computer ID 601, date and time 602, and event type 603 are collected from the agent 161 of each target computer 102 by the log collection program 122 and stored in this table. The table outline of the event log table in each target computer 102 is the same as that of the event log table 141 of the analysis computer 101 in this embodiment. FIG. 6 shows event log records 415 to 417 for Comp-001, records 421 to 422 for Comp-002, record 431 for Comp-003, record 441 for Comp-006, and Comp Records 451 to 452, etc. for -007 are shown. The event log table in each target computer 102 has its own event log data. The event log table 141 in the analysis computer 101 has all event log data collected from each target computer 102.

FIG. 7 shows an example of the configuration change history table 143 resident in the analysis computer 101. The configuration change history data in this table determines what type of configuration change was made between successful and unsuccessful launches, and which type of configuration change failed to repair the launch of an application Used for.

The configuration change history table 143 includes four columns of a computer ID 701, a change date 702, a configuration item 703, and a change type 704. These four columns of data are collected from the agent 161 of each target computer 102 by the log collection program 122 and stored in this table. The table outline of the configuration change history table in each target computer 102 is the same as that of the configuration change history table 143 of the analysis computer 101 in this embodiment. The configuration change history table in each target computer 102 has its own configuration change history data. The configuration change history table 143 in the analysis computer 101 has all the configuration change history data collected from each target computer 102.

Examples of configuration items include software, application (add / delete), patch (add / delete), driver (add / delete), OS settings, processor scheduling (program / background service), memory usage (program / System cache), optional registry items, hardware, memory capacity, hard drive capacity, BIOS settings, hyper thread (on / off), and virtualization technology (on / off). FIG. 7 shows configuration change history records 711 to 716 for Comp-001, records 721 to 726 for Comp-002, records 731 to 734 for Comp-003, and records 741 to 743 for Comp-004. , Records 751 to 752 for Comp-005, records 761 to 762 for Comp-006, and the like are shown.

FIG. 8 shows an example of the application activation history table 142 that is resident in the analysis computer 101. The application activation history data in this table is used to determine when the application is activated before and after the configuration change. This table includes three columns of a computer ID 801, a start date / time 802, and an application name 803. These three columns of data are collected from the agent 161 of each target computer 102 by the log collection program 122 and stored in this table. The table outline of the application activation history table in each target computer 102 is the same as that of the application activation history table 142 of the analysis computer 101 in this embodiment. The application activation history table in each target computer 102 has its own application activation history data. The application activation history table 142 in the analysis computer 101 has all application activation history data collected from each target computer 102. FIG. 8 shows application activation history records 811 to 820 for Comp-001, records 821 to 822 for Comp-002, records 831 to 835 for Comp-003, and records 841 to 844 for Comp-004. , A record 851 for Comp-005, and the like are shown.

FIG. 9 shows an example of the cause configuration change temporary table 144 resident in the analysis computer 101 according to the first embodiment of the present invention. This table is a temporary table when the cause analysis program 121 determines a cause configuration change. This table shows the result of application activation before and after the configuration change. This table includes six columns: computer ID 901, change date 902, configuration item 903, change type 904, start-before 905, and start-after 906. Launch-Previous 905 shows the launch result of the application before the configuration change. Start-After 906 shows the result of starting the application after the configuration change.

For each analysis target computer 102, the record indicates the period from the last successful application launch to the first failed application launch. Assume that the value of the computer ID 901 of the analysis target computer 102 in FIG. 9 is “Comp-001”. For example, all values of the activation-before 905 and activation-after 906 pairs in the records (911-914) are success and failure, respectively. For the other computers, the records indicate the startup results of the application before and after the same configuration change as the analysis target computer 102. For example, the value of the pair of the configuration item 903 and the change type 904 is “PRINTER DRIVER A-Add”, “PATCH-2322-Add”, “VPN-CLIENT v2.0-Add”, or “VPN-CLIENT v1.8”. -Must be one of "Delete". FIG. 9 shows cause configuration change records 911 to 914 for Comp-001, records 921 to 924 for Comp-002, records 931 to 932 for Comp-003, and records 941 to 942 for Comp-004. , Records 951 to 952 for Comp-005, record 961 for Comp-006, record 971 for Comp-007, and the like.

FIG. 10 shows an example of the cause configuration change table 146 resident in the analysis computer 101. This table is a result table created by the cause analysis program 121. This table shows the configuration change that failed to start the application and the corresponding certainty factor. This table includes five columns: a configuration item 1001, a change type 1002, a change date and time 1003, the number of failed cases 1004, and the number of all cases 1005. The number of all cases 1005 indicates the number of all cases for the pair of the configuration item 1001 and the change type 1002. The number of failed cases 1004 indicates the number of failed cases for the pair of the configuration item 1001 and the change type 1002. FIG. 10 shows four cause configuration change records 1011 to 1014. For example, in the record 1011, the configuration change is “PRINTER DRIVER A-added”, the number of failed cases 1004 is 12, and the number of all cases 1005 is 15.

FIG. 11 shows an example of the repair configuration change temporary table 145 resident in the analysis computer 101. This table is a temporary table when the cause analysis program 121 determines a repair configuration change. This table shows the result of starting the application before and after the configuration change performed between the start failure of the specified application and the start success. This table includes six columns: computer ID 1101, change date 1102, configuration item 1103, change type 1104, start-before 1105, and start-after 1106. The meaning of each column is the same as the cause configuration change temporary table 144. FIG. 11 shows repair configuration change records 1111 to 1113 for Comp-001, a record 1121 for Comp-002, a record 1131 for Comp-003, a record 1141 for Comp-004, and the like.

FIG. 12 shows an example of the repair configuration change table 147 resident in the analysis computer 101. This table is a result table created by the cause analysis program 121. This table shows the configuration change that repaired the launch of the failed application and the corresponding confidence. This table includes four columns: configuration item 1201, change type 1202, number of repair cases 1203, and number of all cases 1204. The number of all cases 1204 indicates the number of all cases for the pair of the configuration item 1201 and the change type 1202. The number of repair cases 1203 indicates the number of repair cases for the configuration item 1201 and change type 1202 pair. For example, in the record 1211, the configuration change is “PRINTER DRIVER A-added”, the number of repair cases 1203 is 29, and the number of all cases 1204 is 33. FIG. 12 shows repair configuration change records 1211 to 1213.

4). Process Flow FIG. 13 is an example of a flowchart illustrating log collection performed by a log collection program 122 resident in the analysis computer 101. The log collection program 122 starts the process periodically at specific intervals. As illustrated in FIG. 13, in step 1301, the log collection program 122 finds a target computer for log collection. In step 1302, the log collection program (122) checks whether all discovered computers have been processed. If yes, the process ends. If no, the process proceeds to step 1303. In step 1303, the log collection program 122 collects event logs through communication with an agent 161 that resides in the target computer 102. It also updates the event log table 141 in the analysis computer 101. In step 1304, the log collection program 122 collects the application activation history through communication with the agent 161 resident in the target computer 102. It also updates the application activation history table 142 in the analysis computer 101. In step 1305, the log collection program 122 collects the configuration change history through communication with the agent 161 resident in the target computer 102. It also updates the configuration change history table 143 in the analysis computer 101. After processing log information from all discovered computers (checked in step 1302), log collection program 122 ends the process.

FIG. 14 is an example of a flowchart illustrating cause analysis executed by the cause analysis program 121 resident in the analysis computer 101 according to the first embodiment of the present invention. The cause analysis program 121 starts a process by a user operation on the cause analysis program user interface 401. As illustrated in FIG. 14, in step 1401, the cause analysis program 121 receives the computer ID 411 and the application name 412 as parameters from the cause analysis program user interface 401. In this description, the computer ID is “Comp-001” and the application name is “DOC EDITOR”. In step 1402, the cause analysis program 121 initializes temporary tables and result tables (144, 145, 146, and 147).

In step 1403, the cause analysis program 121 calls the target period detection 131 using the values of the computer ID 411 and the application name 412 as parameters. The result is stored in the cause configuration change temporary table 144. At the time of this step, records (911 to 914) are stored in the configuration change temporary table 144. Therefore, the configuration change that caused the application startup failure is considered to be one of those configuration changes (911 to 914).

In step 1404, the cause analysis program 121 calls the cause configuration change analysis 132 using the values of the computer ID 411 and the application name 412 as parameters. The result is stored in the cause configuration change table 146. At the time of this step, records (1011 to 1014) are stored in the cause configuration change table 146.

In step 1405, the cause analysis program 121 calls the repair configuration change analysis 133 using the value of the application name 412 as a parameter. The result is stored in the repair configuration change table 147. At the time of this step, records (1211 to 1213) are stored in the repair configuration change table 147. In step 1406, the cause analysis program 121 displays the result on the display 117.

FIG. 15 is an example of a flowchart illustrating the target period detection process executed by the target period detection 131 resident in the analysis computer 101. The target period detection 131 starts the process by a call from the cause analysis program 121. As illustrated in FIG. 15, in step 1501, the target period detection 131 receives a computer ID and an application name as parameters. In this description, the computer ID is “Comp-001” and the application name is “DOC EDITOR”.

In step 1502, the target period detection 131 extracts a record having the same computer ID as the computer ID received in step 1501 from the configuration change history table 143. It also rearranges the records in descending order of the modification date 702. At the time of this step, records having the computer ID 701 “Comp-001” are extracted (711 to 716 on the configuration change history table 143).

In step 1503, the target period detection 131 checks whether or not a record is extracted in step 1502. If yes, the process proceeds to step 1504. If no, the process ends.

In step 1504, the target period detection 131 takes out one record from the head and reads the values of the change date 702, the configuration item 703, and the change type 704. In the first execution of this loop, the value of the change date 702 is “06/04/2008 08:20:11”, the configuration item 703 is “PRINTER DRIVER A”, and the change type (704) is “add”. .

In step 1505, the target period detection 131 calls the activation result checker 134 using the values of the computer ID (step 1501), the application name step (1501), and the modification date (step 1504) as parameters. In the first execution of this loop, these parameters are “Comp-001”, “DOC EDITOR”, and “06/04/2008 08:20:11”.

In step 1506, the target period detection 131 receives the values of the start-before and start-after variables as a result of step 1505. The result indicates whether the application was able to start before and after the configuration change without any errors. In the first execution of this loop, the value of the startup-previous result is “success” and the value of the result of startup-after is “failure”.

In step 1507, the target period detection 131 checks whether or not the startup result after the configuration change is successful. If yes, the process ends. If no, the process proceeds to step 1508.

In step 1508, the target period detection 131 creates records of computer ID 901, change date 902, configuration item 903, change type 904, start-before 905, and start-after 906. It also inserts this record into the cause configuration change temporary table 144. At this point in the first loop, a record 911 is stored in the cause configuration change temporary table 144.

In step 1509, the target period detection 131 checks whether all the records extracted in step 1502 have been processed. If yes, the process ends. If no, the process returns to step 1504. In this embodiment, the records (911 to 914) are stored in the configuration change temporary table 144 after the target period detection 131 is executed.

FIG. 16 is an example of a flowchart illustrating a process of checking an application activation result executed by the activation result checker resident in the analysis computer 101. The activation result checker 134 starts the process by a call from the target period detection 131, the cause configuration change analysis 132, and the repair configuration change analysis 133. As illustrated in FIG. 16, in step 1601, the activation result checker 134 receives a computer ID, an application name, and a change date / time as parameters. For example, it is assumed that the computer ID is “Comp-001”, the application name is “DOC EDITOR”, and the change date is “06/04/2008 08:20:11”.

In step 1602, the activation result checker 134 acquires the application activation time immediately before the change date (step 1601) by referring to the application activation history table 142 for the computer ID (step 1601) and the application name (step 1601). When the received change date is “06/04/2008 08:20:11”, the application start time of “DOC EDITOR” immediately before “06/04/2008 08:20:11” is the application start history table. 142 can be found as “06/02/2008 14:26:03” (818).

In step 1603, the activation result checker 134 counts the number of events within a specific time immediately after the application activation time (step 1602) by referring to the event log table 141 for the computer ID (step 1601). When the activation time is “06/02/2008 14:26:03”, the number of events within 10 seconds is zero.

In step 1604, the activation result checker 134 checks the number of events counted in step 1603. If it is greater than 0, the process proceeds to step 1606. Otherwise, the process proceeds to step 1605. In step 1605, the activation result checker 134 sets the activation-previous variable to success. Since the number of events is 0, the start-before variable is set to success. In step 1606, the activation result checker 134 sets the activation-previous variable to failure.

In step 1607, the activation result checker 134 acquires the application activation time immediately after the change date (step 1601) by referring to the application activation history table 142 for the computer ID (step 1601) and the application name (step 1601). When the received change date is “06/04/2008 08:20:11”, the application start time of “DOC EDITOR” immediately after “06/04/2008 08:20:11” is the application start history table 142 can be found as “06/04/2008 08:29:23” (record 417).

In step 1608, the activation result checker 134 counts the number of events within a specific time immediately after the application activation time (step 1607) by referring to the event log table 141 for the computer ID (step 1601). When the activation time is “06/04/2008 08:29:23”, the number of events in 10 seconds is 1.

In step 1609, the activation result checker 134 checks the number of events counted in step 1608. If it is greater than 0, the process proceeds to step 1611. Otherwise, the process proceeds to step 1610. In step 1610, the activation result checker 134 sets the activation-post variable to success. In step 1611, the activation result checker 134 sets the activation-post variable to failure. Since the number of events is 1, the start-after variable is set to failure.

In step 1612, the activation result checker 134 returns the values of the activation-before and activation-after variables. In this description, the activation-before return value is success and the activation-after value is failure.

FIG. 17 is an example of a flowchart illustrating the cause configuration change analysis process executed by the cause configuration change analysis 132 resident in the analysis computer 101 according to the first embodiment of the present invention. The cause configuration change analysis 132 starts a process by a call from the cause analysis program 121. As illustrated in FIG. 17, in step 1701, the cause configuration change analysis 132 receives a computer ID and an application name as parameters. In this description, the computer ID is “Comp-001” and the application name is “DOC EDITOR”. In step 1702, the cause configuration change analysis 132 calls the subroutine of FIG. 18 together with the computer ID (step 1701) and application name (step 1701) values. At the time of this step, records (911 to 971) are stored in the cause configuration change temporary table 144. In step 1703, the cause configuration change analysis 132 receives the configuration change list as a return value in step 1702. Items in the list include configuration items, change types, and change dates. In this description, the configuration change list is “PRINTER DRIVER A-added- 06/04/2008 08:20:11”, “PATCH-2322-added-06 / 04/2008 07:43:11”, “VPN- Includes CLIENT v2.0-Added-06/03/2008 14:27:35 and "VPN-CLIENT v1.8-Deleted-06/03/2008 13:59:28".

In step 1704, the cause configuration change analysis 132 checks whether all items in the list received in step 1703 have been processed. If yes, the process ends. If no, the process proceeds to step 1705. In step 1705, the cause configuration change analysis 132 extracts one item from the list (step 1703), and reads the configuration item, the change type, and the change date and time. In step 1706, the cause configuration change analysis 132 refers to the cause configuration change temporary table 144 (configuration item (step 1705) = configuration item in table 144) and (change type (step 1705) = table 144. The number of records satisfying the conditions (startup in table 144-before = success) and (startup in table 144-after = failure). In step 1707, the cause configuration change analysis 132 refers to the cause configuration change temporary table 144 (configuration item (step 1705) = configuration item in the table 144) and (change type (step 1705) = table 144. Count the number of records that satisfy the condition In step 1708, the cause configuration change analysis 132 inserts the result record into the cause configuration change table 146. This record consists of a configuration item (step 1705), a change type (step 1705), a change date and time (step 1705), the number of failed records (result of step 1706), and the number of all related records (result of step 1707). including. At the time of this step, records (1011 to 1014) are stored in the cause configuration change table 146.

FIG. 18 is an example of a flowchart illustrating a subroutine of the cause configuration change analysis process in step 1702 of FIG. This subroutine starts the process by a call from cause configuration change analysis 132. As illustrated in FIG. 18, in step 1801, the subroutine receives the computer ID and application name as parameters. In this description, the computer ID is “Comp-001” and the application name is “DOC EDITOR”. In step 1802, this subroutine extracts all records from the cause configuration change temporary table 144. It also reads all configuration item and change type pairs and sets them as a list in the CONFIG-LIST variable. At the time of this step, the CONFIG-LIST variables are “PRINTER DRIVER A-Add”, “PATCH-2322-Add”, “VPN-CLIENT v2.0-Add”, and “VPN-CLIENT v1.8-Delete”. including. In step 1803, the subroutine reads from the configuration change history table 143, except for the record having the same configuration item 903 and change type 904 pair as in CONFIG-LIST (step 1802), except for the record for the computer ID received in step 1801. Extract.

In step 1804, this subroutine checks whether all the records extracted in step 1803 have been processed. If yes, the process ends. If no, the process proceeds to step 1805. In step 1805, this subroutine extracts one record from the records extracted in step 1803, and reads the computer ID 901, change date 902, configuration item 903, and change type 904. In step 1806, this subroutine calls the activation result checker 134 together with the computer ID (step 1805), application name (step 1801), and change date / time (step 1805). In step 1807, this subroutine receives the values of the start-before and start-after variables as a result of step 1806. The result indicates whether the application was able to start without any errors before and after the configuration change. In step 1808, this subroutine creates a record including computer ID 901, change date 902, configuration item 903, change type 904, start-before 905, and start-after 906. The record is inserted into the cause configuration change temporary table 144.

FIG. 19 is an example of a flowchart illustrating a repair configuration change analysis process executed by the repair configuration change analysis 133 resident in the analysis computer 101. The repair configuration change analysis 133 starts the process by a call from the cause analysis program 121. As illustrated in FIG. 19, in step 1901 the repair configuration change analysis 133 receives the application name as a parameter. In this description, the application name is “DOC EDITOR”. In step 1902, the repair configuration change analysis 133 calls the subroutine of FIG. 20 together with the value of the application name (step 1901). In step 1903, the repair configuration change analysis 133 extracts a record satisfying the conditions (start-before 1105 = failure) and (start-after 1106 = success) from the repair configuration change temporary table 145 (step 1902). In step 1904, the repair configuration change analysis 133 extracts a pair of the configuration item 1103 and the change type 1104 from the record extracted in step 1903 without duplication. In step 1905, the repair configuration change analysis 133 deletes a record in which the value of the configuration item 1103 and the change type 1104 is not included in the pair extracted in step 1904 from the record extracted in step 1903.

In step 1906, the repair configuration change analysis 133 checks whether all pairs extracted in step 1904 have been processed. If yes, the process ends. If no, the process proceeds to step 1907. In step 1907, the repair configuration change analysis 133 extracts one pair and reads the values of the configuration item 1103 and the change type 1104. In step 1908, the repair configuration change analysis 133 refers to the repair configuration change temporary table 145 (configuration item (step 1907) = configuration item in the table 145) and (change type (step 1907) = table 145. The number of records satisfying the condition (change type in the table) and (start-up in the table 145-after = success) is counted. In step 1909, the repair configuration change analysis 133 refers to the repair configuration change temporary table 145, so that (configuration item (step 1907) = configuration item in table 145) and (change type (step 1907) = table 145. Count the number of records that satisfy the condition In step 1910, the repair configuration change analysis 133 inserts the resulting record into the repair configuration change table 147. The record includes a configuration item (step 1907), a change type (step 1907), the number of successful records (result of step 1908), and the number of all related records (result of step 1909).

FIG. 20 is an example of a flowchart illustrating a subroutine of the repair configuration change analysis process in step 1902 of FIG. This subroutine starts the process by a call from the repair configuration change analysis 133. As illustrated in FIG. 20, in step 2001, the subroutine receives the application name as a parameter. In step 2002, this subroutine extracts from the cause configuration change temporary table 144 a record in which the value of 906 after startup is unsuccessful.

In step 2003, this subroutine checks whether all the records extracted in step 2002 have been processed. If yes, the process proceeds to step 2012. If no, the process proceeds to step 2004. In step 2004, this subroutine extracts one record from the records extracted in step 2002, and reads the computer ID 901 and the modification date 902. In step 2005, this subroutine extracts records from the configuration change history table 143 that satisfy the conditions (computer ID 701 = computer ID (step 2004)) and (change date / time 702> change date / time (step 2004)).

In step 2006, this subroutine checks whether all the records extracted in step 2005 have been processed. If yes, the process proceeds to step 2003. If no, the process proceeds to step 2007. In step 2007, this subroutine extracts one record from the records extracted in step 2005, and reads the computer ID and the change date and time. In step 2008, this subroutine calls the activation result checker 134 together with the computer ID (step 2007), application name (step 2001), and change date (step 2007). In step 2009, this subroutine receives the values of the start-before and start-after variables as a result of step 2008. In step 2010, this subroutine creates a record including computer ID 1101, change date 1102, configuration item 1103, change type 1104, start-before 1105, and start-after 1106. The record is inserted into the repair configuration change temporary table 145. In step 2011, this subroutine checks whether the value after start-up (step 2009) is successful. If yes, the process returns to step 2003. If no, the process returns to step 2006. In step 2012, this subroutine removes duplicate records on the repair configuration change temporary table 145.

B. Second Embodiment FIG. 21 shows an example of the cause configuration change table 146-21 according to the second embodiment of the present invention. In the second embodiment, if the same analysis has been performed in the past, the cause analysis program 121 reuses and displays the results of the analysis and store performed in the past. In order to do this, it is necessary to expand the cause configuration change table 146 of FIG. The columns 1001 to 1005 in FIG. 21 are the same as those in FIG. In addition, new columns for application name 2101 and analysis date 2102 are introduced. For example, the record 2111 indicates that the analysis for the application name “DOC EDITOR” was performed at the analysis date “06/05/2008 14:20:12”. When the application name is “DOC EDITOR” and the analysis conditions are specified so that the result of the target period detection 131 is the same, the cause analysis program 121 displays the analysis result based on the cause configuration change table 146-21. It is possible to display. The same concept can be applied to the repair configuration change table 147 of FIG.

FIG. 22 is an example of a flowchart illustrating cause analysis executed by the cause analysis program 121 according to the second embodiment of the present invention.

Steps

1401, 1403, 1404, 1405, and 1406 are the same as those in FIG. The difference between FIG. 14 and FIG. 22 is as follows. In step 1402-22 (instead of step 1402), the cause analysis program (121) does not initialize the result table (cause configuration change table 146 and repair configuration change table 147). In step 2201, the cause analysis program 121 searches the cause configuration change table 146-21 (shown in FIG. 21) for records that include the same application name and configuration change as the application name 412 and the configuration change in step 1403, respectively. In step 2202, the cause analysis program 121 checks whether or not a past result record has been found. If yes, the process proceeds to step 1406. If no, the process proceeds to step 1404. The result stored in step 1404 is based on the outline of the cause configuration change table 146-21 (FIG. 21).

C. Third Embodiment FIG. 23 shows an example of the cause configuration change table 146-23 according to the third embodiment of the present invention. In the third embodiment, the cause analysis program 121 performs analysis based on the combination of configuration changes. In order to do this, it is necessary to expand the cause configuration change table 146 of FIG. As shown in FIG. 23, columns 1001-1005 are the same as in FIG. In addition, a new column for combination ID 2301 is introduced. Records 2311 to 2317 exist here. For example, record 2311 indicates that the analysis was performed by using all combinations of each configuration change. The same concept can be applied and extended to the repair configuration change table 147 of FIG.

FIG. 24 is an example flowchart illustrating the cause configuration change analysis process performed by the cause configuration change analysis 132 in accordance with the third embodiment of the present invention.

Steps

1701, 1702, and 1703 are the same as those in FIG. The difference between FIG. 17 and FIG. 24 is as follows. In step 2401, the cause configuration change analysis 132 creates a list of all combinations of configuration changes 1703. When the configuration changes are “PRINTER DRIVER A-Add”, “VPN-CLIENT v2.0-Add”, and “VPN-CLIENT v1.8-Delete”, the combinations thereof are as follows.
・ "PRINTER DRIVER A-Addition", "VPN-CLIENT v2.0-Addition", "VPN-CLIENT v1.8-Delete"
・ "PRINTER DRIVER A-Addition", "VPN-CLIENT v2.0-Addition"
・ "PRINTER DRIVER A-Addition", "VPN-CLIENT v1.8-Delete"
・ "VPN-CLIENT v2.0-Add", "VPN-CLIENT v1.8-Delete"
・ "PRINTER DRIVER A-Addition"
・ "VPN-CLIENT v2.0-Addition"
・ "VPN-CLIENT v1.8-Delete"
In step 2402, the cause configuration change analysis 132 checks whether all items in the list created in step 2401 have been processed. If yes, the process ends. If no, the process proceeds to step 2403. In step 2403, the cause configuration change analysis 132 extracts one item from the list (step 2401), and reads the configuration item, the change type, and the change date and time. In step 2404, the cause configuration change analysis 132 refers to the cause configuration change temporary table 144 (configuration item and change type pair (step 2403) = configuration item and change type pair in the computer in the table 144). And the number of computers satisfying the condition (the most recent activation of the computer in the table 144-the later value = failure). In step 2405, the cause configuration change analysis 132 refers to the cause configuration change temporary table 144 (configuration item and change type pair (step 2403) = configuration item and change type pair in the computer in the table 144). Count the number of computers that satisfy the condition. In step 2406, the cause configuration change analysis 132 inserts the result record into the cause configuration change table 146-23 (FIG. 23).

D. Fourth Embodiment FIG. 25 illustrates an example of the overall system hardware architecture configuration, software modules, and tables in accordance with a fourth embodiment of the present invention. In a fourth embodiment for a peer-to-peer architecture, all computers can be servers and clients depending on the situation. A centralized server is not necessary. Each computer 2501 has a cause analysis program (121), an agent (161), log information (171), and a log collection program (122). The log information (171) in each computer includes not only log information of the computer but also log information of other computers.

Naturally, the system configuration illustrated in FIGS. 1 and 2 is a pure example of an information system in which the implementation of the present invention can be considered, and the present invention is not limited to a specific hardware configuration. Computers and storage systems that implement the present invention are well known I / O devices (eg, CDs) that can store and retrieve the modules, programs, and data structures used to implement the present invention described above. And DVD drives, flexible disk drives, hard drives, etc.). These modules, programs, and data structures can be encoded on such computer readable media. For example, the data structure of the present invention can be stored on a computer readable medium independent of one or more computer readable media on which the programs used in the present invention reside. The components of the system can be interconnected by any form or medium of digital data communication, eg, a communication network. Examples of communication networks include local area networks, wide area networks such as the Internet, wireless networks, storage area networks, and the like.

In the description, numerous details are set forth for purposes of explanation in order to provide a thorough understanding of the present invention. However, as will be apparent to those skilled in the art, not all of these specific details are required to practice the invention. It should also be noted that the present invention may be described as a process generally illustrated as a flowchart, flow diagram, structure diagram, or block diagram. A flowchart may describe the operations as a sequential process, but many of the operations can be performed in parallel or concurrently. In addition, the sequence of operations can be rearranged.

As is well known in the art, the operations described above can be performed by hardware, software, or some combination of software and hardware. While various aspects of embodiments of the present invention can be implemented using circuitry and logic devices (hardware), other aspects are stored on a machine-readable medium and executed by the processor when executed by the processor. It can be implemented using instructions (software) that will cause the method of performing embodiments of the present invention to be performed. Further, some embodiments of the invention may be performed solely in hardware, while other embodiments may be performed solely in software. Furthermore, the various functions described can be performed within a single unit, or can be distributed in many ways across multiple components. When performed by software, the method can be performed by a processor, such as a general purpose computer, based on instructions stored on a computer-readable medium. If desired, the instructions can be stored on the media in a compressed and / or encrypted format.

In view of the above, the present invention provides a method, apparatus, and program stored on a computer-readable medium for finding solutions to application failure by analyzing configuration changes without the use of a knowledge database Will be clear. In addition, although specific embodiments have been illustrated and described in this specification, those skilled in the art will be able to substitute any particular embodiment disclosed to achieve the same objective. I will recognize that. This disclosure is intended to protect any and all adaptations or variations of the present invention, and the terms used in the following claims are disclosed in the specification. It should be understood that the invention should not be construed as limited to any particular embodiment. Rather, the scope of the present invention is to be determined entirely by the following claims, which are to be construed with the full range of equivalents to which the claims are entitled, in accordance with established claim interpretation.

E. Fifth Embodiment In the fifth embodiment, the agent in the target computer monitors the installation of the application and notifies the analysis computer of an installation start event when the installation is detected. A totaling program is added to the analysis computer in this embodiment. In the aggregation program, if there is an application name that matches the cause configuration change table for the notified application, the corresponding analysis result is transmitted to the target computer.

FIG. 26 is a functional block diagram of the agent 161 arranged in the target computer according to the fifth embodiment and a diagram showing a portion related to the present embodiment among the functional blocks in the analysis computer 101. In the analysis computer, a totaling program 2601 is added to the functional configuration shown in FIG. The aggregation program reads and uses the cause configuration change table 146 and the repair configuration change table 147 created by the cause analysis program. Needless to say, the aggregation program 2601 is recorded in the memory 112 of the analysis computer 101 and executed by the CPU 111.

The agent 161 has application monitoring means 2602 for monitoring and notifying application installation, and analysis information management means 2603 for receiving and storing analysis results and outputting via the user interface 2606. The received information is stored as a problem configuration change table 2604 and a countermeasure configuration change table 2605.

The processing flow of the agent program will be described (not shown). When the start of application installation is detected, for example, by starting an installer program, a configuration change event including information on addition of the corresponding application name and change type is transmitted to the analysis computer.

Upon receiving the analysis result information from the analysis computer, the agent 161 creates and updates the problem configuration change table 2604 and / or the countermeasure configuration change table 2605 based on the analysis result information. Then, the agent 161 creates and outputs a screen based on the result.

Here, the agent may interrupt the application installation process. In that case, a user interface for notifying the user of the interruption is provided. When the installation is stopped, the analysis result is waited to be received. If there is no reception for a predetermined time, the installation process is resumed. When the received analysis result is output to the screen, a user interface that allows the user to select whether to continue or cancel the installation is provided together with a message “Do you want to continue the installation?”.

Next, the problem configuration change table 2604 will be described. The problem configuration change table is a table showing configuration changes that may become a problem analyzed by the analysis computer 101. The problem configuration change table 2604 has one or more records of the time when the analysis computer performed the analysis processing for each application to be installed (which may be included in the installation target). The record has the following attribute values.
* A value that indicates a possible configuration change * Failure rate.

Next, the countermeasure configuration change table 2605 will be described. The countermeasure configuration change table is a table showing a configuration change analyzed by the analysis computer 101 and possibly solving the problem. The countermeasure configuration change table has one or more records for the time when the analysis computer performed the analysis processing for each application to be installed (which may be included in the installation target). The record has the following attribute values.
* A value that indicates a configuration change that may solve the application problem * Success rate.

FIG. 27 shows a flowchart of a totaling program in the analysis computer.

The following is an explanation of the case where the analysis result information is sent including the problematic configuration change. In this case, the execution of steps 2706 to 2709 in FIG. 27 is omitted.

(Step 2701) The aggregation program receives the configuration change event.

(Step 2702) The aggregation program searches the cause configuration change table for the received application name.

(Step 2703) The aggregation program determines whether or not there is a record having an application name that matches the received application name in the search in Step 2702.

(Step 2704) The tabulation program calculates the ratio of the number of failure cases to the total number of cases as the certainty factor for each configuration item record.

(Step 2705) The tabulation program extracts a record to be transmitted next based on the certainty factor.

Then, the information of the extracted record is included in the analysis result information and transmitted to the target computer that is the transmission source of the configuration change event notification (step 2710), and the process is terminated.

Note that the extraction method in step 2705 includes a method using a threshold and a method limited to a specific number.

(Method 1) In the case of a method using a threshold value, the tabulation program receives the certainty threshold value from the administrator or the user of the target computer and records the threshold value in the memory 112 to manage the threshold value. The certainty level is compared with a threshold value, and only records of configuration items that are equal to or higher than the threshold value are extracted.

(Method 2) When limiting to a specific number, a specific number (for example, 3) is defined in advance. Up to the top three records are extracted based on the calculated certainty factor. If the definition of threshold or specific number is NULL, all records are assumed.

FIG. 28 shows an output example in which the agent 161 refers to the problem configuration change table 2604 and displays it on the display unit 157 via the video I / F 154. In the upper row, information on configuration items that may cause activation failure is displayed for the application to be installed. For each configuration item and its change type (2801), a failure rate is displayed as a certainty factor (2802), and a message (2803) for the end user is output according to the certainty factor. Depending on the certainty value, the message is 75% or more, for example. << Warning> If this configuration change has been made, there is a high possibility that the application will fail to start. In%, "<Caution> If this configuration change has been made, the application may fail to start." If it is less than 50%, "<Information> This configuration change will not affect the application."

In addition to the cause configuration change table information, the configuration items, the number of repair cases, and the total number of cases are stored in the table for each application name in the same manner as in FIG. . Steps 2706 to 2709 in FIG. 27 are steps for realizing such processing.

(Step 2706) The aggregation program searches the repair configuration change table and extracts information on the corresponding application.

(Step 2707) The aggregation program determines whether or not there is a record having an application name that matches the received application name in the search in Step 2706.

(Step 2708) The tabulation program calculates the ratio of the number of failure cases to the total number of cases as the certainty factor for each configuration item record.

(Step 2709) The aggregation program extracts the record to be transmitted next based on the certainty factor and includes it in the analysis result information.

The agent 161 receives the analysis result information and creates or updates the countermeasure configuration change table using the record included in the analysis result information. In this embodiment, since there is no problem in the application on the target computer, the countermeasure may be output simultaneously with the trouble information or may be output when there is a request from the user interface. Good.

FIG. 29 shows an output example in which the agent 161 refers to the countermeasure configuration change table 2705 and displays the display unit 157 as the effectiveness of the countermeasure against the activation failure of the corresponding application via the video I / F 154. For each configuration item and its change type (2901), the success rate of the countermeasure is displayed as the certainty (2902), and a message (2903) for the end user is output based on the certainty. The message is, for example, “This configuration change may be able to repair an application startup failure problem”.

As a modified example of the fifth embodiment, a method for extracting a record to be transmitted is not a method based on a certainty factor, but a method based on a configuration of a configuration change event transmission source computer. The process is the same up to step 2703, and a record with a matching application name in the cause configuration change table is extracted. Next, the aggregation program refers to the configuration change history table shown in FIG. 7, and records that match the configuration items and change types in the record extracted in step 2703 with respect to the records whose computer ID matches the source computer. Find if there is. Only records whose configuration item matches the change type are sent.

 Extraction of records to be transmitted is performed to provide the minimum necessary information. It is possible to reduce the amount of transfer to the target computer by deleting information related to configuration items that have a low certainty factor or are not related to the configuration of the computer.

Furthermore, as another example of the fifth embodiment, a method for providing information not only when an application is installed but also when a configuration item is changed such as applying a patch or deleting software will be described. In addition to application installation, the agent monitors changes in configuration items such as patch application, driver update, and deletion, and notifies the analysis computer as a configuration change event when detected. Here, the configuration item is included as the application name, and the change type such as addition or deletion is included in the configuration change event.

In the first embodiment, the addition of a patch or the deletion of software is recorded in the cause configuration change table as a configuration item that is a cause of a cause of failure of other applications. Therefore, the aggregation program receives the configuration change event, and searches the configuration item when there is no record as the application name as a result of searching the cause configuration change table in the flow shown in FIG. 27 for the received application name. . Further, it searches for a match with the change type, extracts it, and sends it to the agent.

The screen output information on the target computer in this case is shown in FIG. The success rate of the countermeasure is displayed as a certainty factor (3002) for each affected configuration item and its change type (3001) for the software name subject to the configuration change (3002). 3003) is output.

The same concept can be applied to the repair configuration change table.
As another modification, a method of using information of a cause configuration change table in which configuration items are combined will be described. The analysis results performed based on the combination of configuration changes shown in the third embodiment are stored in the cause configuration change table shown in FIG. Here, the table of FIG. 23 is expanded to introduce columns of application name and analysis date (not shown). When saving the result of the cause configuration change analysis in FIG. 24, the name of the target application and the date and time of analysis are saved.

The processing in the aggregation program in this embodiment is different from the flow shown in FIG. 27 in that instead of searching the cause configuration change table of FIG. 21 in step 2702, the cause configuration change table expanded from FIG. 23 is searched. It is. A record having the same application name is extracted from the expanded cause configuration change table, and the number of failure cases with respect to the total number of cases is calculated as the certainty for each combination ID. Based on the certainty factor, the combination ID record to be transmitted is determined.

F. Sixth Embodiment In the fifth embodiment, there is a cause analysis request for the corresponding application before, and when the analysis is performed, the result is provided to the end user of the target computer. Here, in order to provide the latest analysis result when the analysis is not performed, the present embodiment shows a method of performing the analysis at the time of receiving the configuration change event and providing the result.

∙ Analyze whether there is a problem with the startup of another application on another computer when installing the application, rather than analysis after the application has failed to start on the target computer.

FIG. 31 is an example of a flowchart of processing executed by the aggregation program in the analysis computer according to the sixth embodiment of the present invention. The aggregation program receives the installation start event notification from the agent as in FIG. 27 (step 2701), and extracts the transmission source computer ID and the application name included in the notification (step 2702). Next, the tabulation program calls the cause analysis program 121 (a) using the computer ID and application name as parameters (step 3103). Here, the processing of the cause analysis program is partially different from the processing of FIG. 14 in the first embodiment, and will be described with reference to FIG.

In the tabulation program, after the cause analysis program 121 (a) is finished, as in the fifth embodiment, the number of failure cases with respect to the total number of cases is set as the certainty factor for each configuration item in the resulting cause configuration change table. Calculate (step 2704), extract a record to be transmitted based on the certainty factor (step 2705), and transmit it to the agent (step 2710).

In the cause analysis program (a), a repair configuration change table may be created as in the first embodiment. In that case, the reliability is similarly calculated for the corrected configuration change table obtained as a result, a record to be transmitted is determined based on the reliability, and the record is transmitted to the agent.

FIG. 32 shows a flowchart of the cause analysis program 121 (a) in the present embodiment.
(Step 3201) The cause analysis program receives the computer ID and application ID from the aggregation program.

(Step 3202) The cause analysis program initializes a temporary table and a result table.

(Step 3203) The cause analysis program next reads the configuration change history table and extracts a record having the same computer ID as the received computer ID. Here, when the data of the configuration change history table is stored for a long time, the extraction target may be limited to records up to a certain period before.

(Step 3204) The cause analysis program stores the extracted result in the cause configuration change temporary table. Since the activation check is not performed for this computer ID, the activation-before and activation-after columns of the stored record are left NULL.

(Step 3205) The cause analysis program then analyzes the case of another target computer. Since the analysis processing is the same as in the first embodiment, the subroutine of FIG. 18 is called here.

(Step 3206) The cause analysis program receives the configuration change list as a return value of the subroutine. Items in the list include configuration items, change types, and change dates.

(Step 3207) The cause analysis program checks whether all items in the list have been processed. If not, the process proceeds to Step 3208.

(Step 3208) The cause analysis program refers to the cause configuration change temporary table created as a result of the subroutine (3205), and counts the number of records satisfying the following condition. The configuration item in the configuration change list, the change type and the configuration item in the table, and the change type are the same, and the conditions are “start-before = success” and “start-after = failure”.

(Step 3209) The cause analysis program refers to the cause configuration change temporary table, and except for the record about the computer ID received in Step 3201, the configuration change list configuration item, the change type and the table configuration item, and the change type are Count the number of the same record.

(Step 3210) The cause analysis program registers the result record in the cause configuration change table. The cause configuration change table has the table configuration shown in FIG. 21, the application name received in step 3201, the analysis date / time, the configuration item included in the configuration change list (step 3206), the change type, the change date / time, and the count in step 3208. The value is registered as the number of failed cases, and the count value in step 3209 is registered as the number of all cases.

As a modified example of the sixth embodiment, when there is already a cause configuration change table by the corresponding application, based on the analysis date and time, if it is not a predetermined period or more, no new analysis is performed and the information of the corresponding table is used To do. In this case, in the process of the aggregation program shown in FIG. 31, after step 2702, the cause configuration change table is searched, and when the record of the corresponding application is found, the analysis date and time is confirmed. If within a certain period, the cause analysis program is not called, and the corresponding record is used to calculate the certainty factor for each configuration item and the subsequent processing (steps 2704 to 2706). If the analysis date is not within a certain period, the process proceeds to step 3103.

As a modification of the fifth or sixth embodiment, a method for outputting data held by the agent will be described. The problem configuration change table and the countermeasure configuration change table received and held from the analysis computer include a cause configuration item or a repair configuration item and its certainty factor for each application. The agent provides a user interface that accepts application name input. When the user inputs an application name, the agent searches for information on the application in the table. If there is information, as shown in the examples of FIGS. Output.

Furthermore, as a sixth alternative embodiment, there is a method of periodically starting a counting program in an analysis computer and updating information. Unlike the processing of FIG. 31, the counting program does not receive a computer ID or application name at the time of activation. Therefore, the application names in the cause configuration change table to be stored are extracted in order, the configuration change items after the previous analysis date and time are extracted for each computer for all applications, and cause analysis is performed. The information totalized periodically is updated and stored in the cause configuration change table, and is transmitted to the target computer periodically or upon receiving a configuration change event or a request from an agent.

In addition to the configuration change such as application installation and patch application, there is a method of analyzing application startup failure cases affected by user operations. In this case, the log collection program of the analysis computer collects user operation logs and manages them in the operation history table. In the agent, the configuration change monitoring means monitors user operations such as OS setting changes, and notifies the analysis computer when a specific operation is performed. The analysis computer searches the operation history table by the aggregation program and the cause analysis program, analyzes the case where the application startup failure occurs after performing the same operation, and aggregates the certainty factor. The result is sent to the agent, and the agent outputs it to the screen.

As described above, the analysis result of the analysis computer that does not use the knowledge database for the problem of the application due to the configuration change in the computer is provided at the timing when the end user changes the configuration, and the end user is encouraged to deal with the problem. Support can be realized.

In the fifth and sixth embodiments described above, an application introduction method in a computer system having a plurality of target computers and an analysis computer, which is included in the plurality of target computers and has a predetermined application installed and started The one or more first target computers transmit a log including information on a plurality of configuration changes performed before the predetermined application is started to the analysis computer, and the analysis computer receives the log. In the above description, for each type of configuration change based on the log, the startup failure rate, which is the rate at which a predetermined application startup failed after the configuration change, has been described.

Further, the second target computer included in the plurality of target computers and other than the one or more first target computers is: (1) Startup failure for each type of configuration change related to the predetermined application from the analysis computer It has been described that the first information including the rate is received, and (2) the type of configuration change that causes the startup of the predetermined application to fail is displayed based on the startup failure rate.

The start failure rate included in the first information is a start failure rate for each of some types of all the configuration change types detected by the analysis computer based on the log, and It has been explained that the type of copy may be selected by the analysis computer based on the activation failure rate.

Further, the analysis computer calculates a startup success rate, which is a rate of successful startup of the predetermined application after the configuration change, for each type of the configuration change based on the log, and the second target computer (3) receiving second information including a startup success rate for each type of configuration change related to the predetermined application from the analysis computer; and (4) starting the predetermined application successfully based on the startup success rate. It has been explained that the type of configuration change that causes a failure may be displayed.

In addition, the second target computer has already installed a plurality of applications other than the predetermined application, and the second target computer fails to start for a predetermined type included in all of the configuration change types. It has been described that a possible application may be selected from the predetermined application and the plurality of applications, and an identifier of the selected application may be displayed.

In addition, the type has been described as an example of a configuration item or / and a change type, but another type may be a type of a configuration change operation.

In the above description, the information of the present invention has been described using expressions such as “aaa table”, “aaa list”, “aaaDB”, “aaa queue”, etc., but these information are not necessarily limited to tables, lists, DBs, queues, It may be expressed by other than the data structure. Therefore, “aaa table”, “aaa list”, “aaaDB”, “aaa queue”, etc. may be referred to as “aaa information” to indicate that they are not dependent on the data structure. Further, in describing the contents of each information, the expressions “identification information”, “identifier”, “name”, “name”, and “ID” are used, but these can be replaced with each other.

Note that the analysis computer may be a plurality of computers. It should be noted that the memory 152 and the disk 153 of the target computer 102 may be treated as a storage resource (that is, a storage device) collectively without being distinguished from each other. Similarly, the memory 112 and the disk 113 of the analysis computer 101 may be collectively treated as storage resources without being distinguished from each other.

In the above description, there is a case where “program” is used as the subject, and the program is executed by the processor to perform processing determined by using the memory and the communication port (communication control device). The subject may be an explanation. Further, the processing disclosed with the program as the subject may be processing performed by a computer such as a management server or an information processing apparatus. Further, part or all of the program may be realized by dedicated hardware.

Various programs may be installed in each computer by a program distribution server or a storage medium that can be read by the computer.

101 Analysis computer 102 Analysis target computer 103 LAN
111 CPU
112 Memory 113 Disk 114 Video interface 115 Network interface 116 System bus 117 Display 121 Cause analysis program 122 Log collection program 123 Log information 131 Target period detection 132 Cause configuration change analysis 133 Repair configuration change analysis 134 Startup result checker 141 Event Log table 142 Application startup history table 143 Configuration change history table 144 Cause configuration change temporary table 145 Repair configuration change temporary table 146 Cause configuration change table 146-21 Cause configuration change table 146-23 Cause configuration change table 147 Repair configuration change table 151 CPU
152 Memory 153 Disk 154 Video interface 155 Network interface 156 System bus 157 Display 161 Agent 171 Log information

Claims

An application introduction method in a computer system having a plurality of target computers and analysis computers,
One or more first target computers that are included in the plurality of target computers and have a predetermined application installed and started up include a log that includes information on a plurality of configuration changes made before the predetermined application is started up. , Send to the analysis computer,
The analysis computer receives the log, for each type of configuration change based on the log, and calculates a startup failure rate that is a rate at which a predetermined application startup failed after the configuration change,
A second target computer included in the plurality of target computers and other than the one or more first target computers is:
(1) receiving first information including a startup failure rate for each type of configuration change related to the predetermined application from the analysis computer;
(2) Based on the activation failure rate, the type of configuration change that causes the activation of the predetermined application to fail is displayed.
An application introduction method characterized by that.
The application introduction method according to claim 1,
The start failure rate included in the first information is a start failure rate for each of some types of all the configuration change types detected by the analysis computer based on the log,
The partial type is selected by the analysis computer based on the startup failure rate,
An application introduction method characterized by that.
An application introduction method according to claim 2,
The first information includes a total time indicating when the activation failure rate is calculated,
The second target computer displays the total time;
An application introduction method characterized by that.
An application introduction method according to claim 3,
For each type of configuration change based on the log, the analysis computer calculates a startup success rate, which is a rate of successful startup of the predetermined application after the configuration change,
The second target computer is
(3) receiving second information including a startup success rate for each type of configuration change related to the predetermined application from the analysis computer;
(4) Based on the activation success rate, a type of configuration change that causes the predetermined application to be successfully activated is displayed.
An application introduction method characterized by that.
The application introduction method according to claim 4,
The second target computer has already installed a plurality of applications other than the predetermined application,
The second target computer selects, from the predetermined application and the plurality of applications, an application that may fail to start for a predetermined type included in all the configuration change types, and an identifier of the selected application Display,
An application introduction method characterized by that.
An application introduction method according to claim 5,
The process (1) is executed in association with installation of the predetermined application.
An application introduction method characterized by that.
An application introduction method according to claim 6,
The type is a configuration item or / and a change type.
An application introduction method characterized by that.
A second target computer connected to an analysis computer that manages a first target computer that has started a predetermined application;
The second target computer is
Receiving first information including a startup failure rate for each type of configuration change related to the predetermined application from the analysis computer;
Based on the activation failure rate, a display for displaying the type of configuration change that causes the activation of the predetermined application to fail, and
Have
The activation failure rate is a value calculated by the analysis computer as a ratio of failure of predetermined application activation after the configuration change for each of a plurality of types of configuration change performed by the first target computer before the predetermined application activation. Is,
A second target computer characterized by the above.
A second target computer according to claim 8, comprising:
The startup failure rate included in the first information is a startup failure rate for each of some types of all configuration change types detected by the analysis computer,
The partial type is selected by the analysis computer based on the startup failure rate,
A second target computer characterized by the above.
A second target computer according to claim 8, comprising:
The first information includes a total time indicating when the activation failure rate is calculated,
The second target computer displays the total time;
A second target computer characterized by the above.
A second target computer according to claim 8, comprising:
For each type of configuration change, the analysis computer calculates a startup success rate that is a rate at which the predetermined application was successfully started after the configuration change,
The CPU receives second information including a startup success rate for each type of configuration change related to the predetermined application from the analysis computer,
The display unit displays a type of configuration change that causes the predetermined application to be successfully activated based on the activation success rate.
A second target computer characterized by the above.
A second target computer according to claim 8, comprising:
The second target computer has already installed a plurality of applications other than the predetermined application,
The CPU selects, from the predetermined application and the plurality of applications, an application that may fail to start for a predetermined type included in all of the configuration change types,
The indicator displays an identifier of the selected application;
A second target computer characterized by the above.
A second target computer according to claim 8, comprising:
The display on the display unit is executed in association with installation of the predetermined application.
A second target computer characterized by the above.
A second target computer according to claim 8, comprising:
The type is a configuration item or / and a change type.
A second target computer characterized by the above.