Information processing system

Abstract

The present invention aims at notifying a user of a result of automatic response to a fault that has occurred in a monitored system, thereby reducing the burden on the user. An information processing system includes a monitoring unit that acquires information of a fault that has occurred in a monitored system; a coping method definition holding unit that holds a coping method definition for the fault; a coping method execution control unit that selects the coping method definition for responding to the fault that has occurred in the monitored system; a coping method execution control unit and a response processing unit that automatically execute a response processing in accordance with the coping method definition that has been selected; a coping result output unit that judges whether or not an execution result of the response processing is a predetermined content; and a coping result output unit that outputs information indicating that the user's response is not needed when the execution result of the response processing is the predetermined content, and outputs information indicating that the user's response is needed when the execution result is not the predetermined content.

Description

Technical Field

[0001] This invention relates to an information processing system. Background Technology

[0002] Previously, a system was proposed that corresponds to an event that has already occurred in an object system, identifies matching or similar events, and supports responses to said events.

[0003] Patent Document 1 discloses a method that automatically retrieves information stored in a database based on information about events that have occurred in the target system, obtains information including response procedures for known events that match, and outputs the obtained information as information applied to the events that have occurred, and performs processing such as displaying or notifying the responder's terminal.

[0004] Patent Document 2 discloses a method for extracting a template identifier (ID) associated with an error message contained in a received event from a user's computer system, extracting actual parameter information required for executing the application template from the template ID, and executing the application program by extracting the actual parameters of the application template from a management database based on the actual parameter information.

[0005] Patent document 3 discloses a data holding unit that holds action state information for each event generated in an information processing system and determines a similar event to a selected event chosen from multiple events.

[0006] [Existing Technical Documents]

[0007] [Patent Literature]

[0008] Patent Document 1: Japanese Patent Application Publication No. 2011-76161

[0009] Patent Document 2: Japanese Patent Application Publication No. 2013-8178

[0010] Patent Document 3: Japanese Patent Application Publication No. 2018-81403 Summary of the Invention

[0011] [The problem the invention aims to solve]

[0012] When users deal with faults that have already occurred in the monitored system, it becomes a burden for them. Even in systems that automatically handle known faults, faults similar to the known faults may not be resolved with the same approach. Therefore, users have to judge the appropriate approach or the necessity of the approach, or the user's need for the approach, thus becoming a burden for them.

[0013] The purpose of this invention is to automatically respond to faults that have occurred in the monitored system based on known information, and to notify the user of the response results, thereby reducing the user's burden.

[0014] [Technical means to solve the problem]

[0015] The present invention, according to technical solution 1, is an information processing system, comprising:

[0016] The fault information acquisition component acquires information about faults that have occurred in the monitored system.

[0017] The coping method definition retains the component, which retains the coping method definition for coping methods that are envisioned to occur in the monitored system;

[0018] Select a component, based on the information obtained by the fault information acquisition component, and select a response method definition for the fault that has occurred in the monitored system from the response method definition retention component.

[0019] The execution unit automatically performs the response processing according to the response method definition selected by the selection unit;

[0020] The response result judgment component determines whether the execution result of the response processing performed by the execution component is the predetermined content; and

[0021] The output component, when the result judgment component determines that the execution result is a predetermined content, outputs information indicating that no user response is required; when the execution result is not a predetermined content, it outputs information indicating that the user response is required.

[0022] The present invention in technical solution 2 is based on the information processing system described in technical solution 1.

[0023] The selection component selects a method to deal with faults that have occurred in the monitored system based on the classification of the occurrence of events that have occurred in the monitored system.

[0024] The present invention, in technical solution 3, is based on the information processing system described in technical solution 2, wherein the fault information acquisition component acquires the action log of the monitored system.

[0025] The selection component retrieves a predetermined string from the text of the action log obtained by the fault information acquisition component, and uses the detected string to classify the occurrence status of events that have occurred in the monitored system.

[0026] The present invention, in technical solution 4, is based on the information processing system described in technical solution 1.

[0027] The fault history retention component retains the execution history of the fault response when the user handles a fault in the monitored system; and

[0028] Define the production component and, based on the execution history maintained by the response history maintenance component, create the response method definition for the fault.

[0029] The present invention of technical solution 5 is an information processing system described in technical solution 4, which further includes an editing operation receiving component, which prompts the execution history held by the response history holding component for the editing operation performed by the user.

[0030] The present invention, in technical solution 6, is an information processing system described in technical solution 4, further comprising an input operation receiving component. This input operation receiving component receives input operations related to response actions taken by the user to address faults in the monitored system.

[0031] The response history retention component retains the information received by the input operation acceptance component as at least part of the execution history.

[0032] [The effects of the invention]

[0033] According to the invention of technical solution 1, for faults that have occurred in the monitored system, compared with the situation where the user has to deal with them, the user can be automatically dealt with based on known information, and the user can be notified of the result of the response, thereby reducing the user's burden.

[0034] According to the invention of technical solution 2, compared with the case of automatically responding only to predetermined faults, the conditions for determining the response method can be flexibly set according to the specific occurrence of the actual situation.

[0035] According to the invention of technical solution 3, compared with the situation where the occurrence of a situation is determined based on action conditions, the occurrence of a situation can be determined by text analysis of the action log.

[0036] According to the invention of technical solution 4, compared with the case of automatically responding only to predetermined faults, similar faults of the same type can be automatically responded to in the future.

[0037] According to the invention of technical solution 5, compared with the case of automatically responding only to predetermined faults, the creation of execution history that is suitable for the definition of more effective coping methods can be supported through the user's editing operation.

[0038] According to the invention of technical solution 6, compared with the case of automatically responding only to predetermined faults, the invention can support the creation of an execution history suitable for the definition of a more effective response method based on the response processing performed by the user. Attached Figure Description

[0039] Figure 1 This is a diagram showing the overall structure of the information processing system using this embodiment.

[0040] Figure 2 It is a diagram that shows the functional structure of the system being monitored.

[0041] Figure 3 This is a diagram illustrating the functional structure of a fault response system.

[0042] Figure 4 This is a diagram illustrating an example of the processing functions of the response processing unit.

[0043] Figure 5 It is a flowchart showing the actions of the fault response system.

[0044] Figure 6 This is a diagram illustrating an example of a coping method definition.

[0045] Figure 7 This is a diagram showing an example of the main operation screen in the user interface (UI) screen.

[0046] Figure 8 This is an example of a screen displaying associated logs.

[0047] Figure 9 This is an example image showing the upgrade execution screen.

[0048] Figure 10 This is an example of a screen displaying the results.

[0049] Figure 11 This is a diagram illustrating an example of how user-manual actions are used to process response history information.

[0050] [Explanation of Symbols]

[0051] 100: Fault Response System

[0052] 110: Surveillance Department

[0053] 120: Execution Control Department for Handling Procedures

[0054] 130: Coping Method Definition and Maintenance Section

[0055] 140: Response and Handling Department

[0056] 141: Log Information Acquisition Department

[0057] 142: User Information Acquisition Department

[0058] 143: Upgrade Execution Department

[0059] 144: Action Confirmation Test Execution Department

[0060] 145: Collaborator System Operation Confirmation Department

[0061] 150: Accounts Payable Method Definition Management Department

[0062] 160: Output Department

[0063] 170: Faulty DB Access Department

[0064] 181: Fault Investigation UI Department

[0065] 182: Faulty DB Update Department

[0066] 183: Fault Investigation and Handling Record Maintenance Department

[0067] 184: Coping Method Generation Department

[0068] 200: Fault Database (DB)

[0069] 300: Monitoring Object System Detailed Implementation

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

[0071] <System Composition>

[0072] Figure 1 This is a diagram illustrating the overall structure of the information processing system using this embodiment. The information processing system of this embodiment includes: a fault response system 100, a fault database (DB) 200, and a monitoring object system 300.

[0073] The fault response system 100 is an information processing system that monitors the monitored system 300. When an error or other fault occurs in the monitored system 300, the fault response system 100 performs response processing. When a fault occurring in the monitored system 300 can be handled automatically, the fault response system 100 automatically performs the necessary response processing. On the other hand, when a fault occurring in the monitored system 300 cannot be handled automatically, the fault response system 100 notifies the user of the monitored system 300, urging the user to take action.

[0074] The fault database 200 stores and manages information related to faults that have occurred in the monitored system 300. The fault database 200 records information from the occurrence of a fault to the completion of a response to it. Various types of database systems accessible via a network can be used as the fault database 200. When a database server, such as a cloud server, is used as the fault database 200, it must be operated externally (from the fault response system 100) through an Application Programming Interface (API). Figure 1 In the example shown, there is one fault DB200, but there can be multiple faults DB200.

[0075] The monitoring object system 300 is an information processing system that becomes the monitoring object of the fault response system 100. The monitoring object system 300 can be any information processing system as long as it has the ability to monitor actions through the fault response system 100 and detect the components that have caused the fault.

[0076] exist Figure 1 In the configuration shown, the fault response system 100 is implemented, for example, through a server built on a network. Furthermore, the monitoring target system 300 can also be implemented through a server built on a network; if connected to the fault response system 100 via a network, the monitoring target system 300 itself can also be a local system. The fault response system 100 and the monitoring target system 300 are not limited to a single hardware component (server machine, etc.), but can also be configured as multiple hardware components or virtual machines.

[0077] <Functional Composition of Monitoring Object System 300>

[0078] Figure 2 This diagram illustrates the functional configuration of the monitoring system 300. The monitoring system 300 includes a function execution unit 310, a log management unit 320, and a detection unit 330. The server implementing the monitoring system 300 is implemented, for example, as a computer. As hardware, it includes a central processing unit (CPU) as the arithmetic unit, and a main storage device (main memory) and external storage devices as storage units. The CPU loads programs stored in the external storage device into the main storage device for execution. For example, random access memory (RAM) can be used as the main storage device. For example, a disk drive or a solid-state drive (SSD) can be used as the external storage device.

[0079] The function execution unit 310 is implemented, for example, by executing an application program via the CPU. Under the control of the application program, the function execution unit 310 performs data processing or control utilizing various functions. Furthermore, the function execution unit 310 generates an action log corresponding to the executed processing or control.

[0080] The log management unit 320 stores and manages the action logs generated corresponding to the actions of the function execution unit 310. When a fault occurs during the execution of processing or control performed by the function execution unit 310, information indicating the occurrence of the fault is also recorded in the action log.

[0081] The detection unit 330 analyzes the action log stored in the log management unit 320 and detects specific strings, then performs specific processing. The specific strings refer to the strings that appear in the action log when a specific fault, such as an error, occurs during the processing or control performed by the function execution unit 310. For example, strings such as "FATAL" or "SEVERE" can be used as specific strings. Specific processing refers to the actions to be performed when these specific strings are detected in the action log. Examples include sending an email to the user informing them of the fault, or notifying the fault response system 100 of the fault occurrence.

[0082] Furthermore, the detection unit 330 submits an action log containing a specific range of detected strings to the fault response system 100. The range of the submitted action log is defined, for example, corresponding to the detected strings or the type of fault identified.

[0083] <Functional Composition of Fault Response System 100>

[0084] Figure 3 This diagram illustrates the functional configuration of the fault response system 100. The fault response system 100 includes: a monitoring unit 110, a fault response method execution control unit 120, a fault response method definition storage unit 130, a fault response processing unit 140, a fault response method definition management unit 150, a fault response result output unit 160, and a fault database access unit 170. Furthermore, the fault response system 100 includes: a fault investigation UI unit 181, a fault database update unit 182, a fault investigation and processing history storage unit 183, and a fault response method generation unit 184.

[0085] The monitoring unit 110 monitors the monitored system 300 and obtains an action log from the detection unit 330. The action log contains information about faults that have occurred in the monitored system 300. If the monitoring unit 110 obtains an action log containing fault information, it activates the fault response method execution control unit 120. Furthermore, the monitoring unit 110 accesses the fault database 200 via the fault database access unit 170 and registers the fault information obtained from the action log in the fault database 200. The monitoring unit 110 is an example of a fault information acquisition unit.

[0086] The coping method execution control unit 120 determines the coping method to be executed based on the fault information detected in the monitored system 300 and the coping method definition for the fault, and controls the execution of the determined coping method. Specifically, the coping method execution control unit 120 first selects a coping method definition for the fault that has occurred in the monitored system 300 based on the fault information recorded in the action log obtained by the monitoring unit 110. Then, the coping method execution control unit 120 calls the coping processing unit 140 according to the selected coping method definition and automatically executes the coping processing. The coping method definition refers to the information of the coping method to be executed corresponding to the fault.

[0087] To further explain the selection of the coping method definition, the coping method execution control unit 120 selects a coping method definition for faults that have occurred in the monitored system 300 based on the classification of the occurrence status of faults that have occurred in the monitored system 300. The occurrence status of a fault refers to the set of events that have occurred in the monitored system 300 from the time the fault occurred until its occurrence. Specifically, it can list the occurrence time, frequency, or interval of one or more specific events. More specifically, the coping method execution control unit 120 retrieves a predetermined string from the text of the action log acquired by the monitoring unit 110, and uses the detected string to classify the occurrence status of faults that have occurred in the monitored system 300. The coping method execution control unit 120 is an example of a selection unit.

[0088] The coping method definition holding unit 130 holds the coping method definition for faults. The coping method definition holding unit 130 is an example of a coping method definition holding component. The coping method definition describes coping methods for faults that are anticipated to occur in the monitored system. Specifically, it describes, for example, the conditions (screening conditions) for determining the coping method to be applied based on error information, the execution means and parameters corresponding to the determined coping method, information written to the fault DB200 when the execution result of the coping matches the prediction, and information written to the fault DB200 when the execution result of the coping does not match the prediction. Here, the predicted execution result refers, for example, to the state or condition when the system recovers (normally recovers) through automatic response. Details of the coping method definition will be described later.

[0089] The response processing unit 140 is a specific processing function invoked by the response method execution control unit 120. The response method execution control unit 120 and the response processing unit 140 are examples of response processing execution components. The processing functions of the response processing unit 140 are prepared according to the type of fault. Details of the processing functions of the response processing unit 140 will be described later.

[0090] The accounts payable method definition management unit 150 manages the accounts payable method definitions held by the accounts payable method definition holding unit 130. The accounts payable method definition management unit 150 adds accounts payable method definitions generated by the accounts payable method generation unit 184 to the accounts payable method definition holding unit 130, updates existing accounts payable method definitions using generated accounts payable method definitions, or deletes accounts payable method definitions that are no longer needed.

[0091] The handling result output unit 160 determines whether the handling result executed by the handling method execution control unit 120 and the handling processing unit 140 is within or outside the expected scope. Furthermore, the handling result output unit 160 outputs the determination result and stores it in the fault database 200 via the fault database access unit 170. More specifically, when the handling result is determined to be a predetermined content (within the expected scope), the handling result output unit 160 outputs information indicating that no user response is required and stores it in the fault database 200. On the other hand, when the handling result is determined to be an unpredictable content (unexpected scope), it outputs information indicating that a user response is required and stores it in the fault database 200. The handling result output unit 160 is an example of a handling result determination unit and an example of an output unit.

[0092] The fault database access unit 170 accesses the fault database 200 to add or update information. Specifically, the fault database access unit 170 sends the judgment result from the response result output unit 160 to the fault database 200. Furthermore, the fault database access unit 170 updates the information stored in the fault database 200 under the control of the fault database update unit 182. The updating of the fault database 200 using the fault database update unit 182 will be described later.

[0093] The fault investigation UI unit 181 generates an operation screen (UI screen) as a user interface for fault investigation. The generated operation screen is sent to the terminal device operated by the user for display. Through the UI provided by the fault investigation UI unit 181, the user can call up various functions of the response processing unit 140 to perform response processing. That is, as a means of performing response processing for faults in the monitored system 300 using the response processing unit 140, unlike the automatic execution controlled by the response method execution control unit 120, it can be performed manually by the user through the operation screen. The execution result of the response processing called up from the operation screen is submitted to the fault database update unit 182.

[0094] Furthermore, the UI provided by the fault investigation UI unit 181 accepts input operations for information on the response processing unit 140, performed manually by the user to address faults in the monitored system 300. The UI provided by the fault investigation UI unit 181 also maintains the information input through the input operations in the fault investigation and processing history retention unit 183. Moreover, the UI provided by the fault investigation UI unit 181 prompts users to edit the execution history retained by the fault investigation and processing history retention unit 183. The fault investigation and processing history retention unit 183 will be described below. The fault investigation UI unit 181 is an example of an input operation acceptance unit and an example of an editing operation acceptance unit.

[0095] The fault database update unit 182 records the information submitted from the fault investigation UI unit 181 in the fault investigation processing history. Furthermore, the fault database update unit 182 accesses the fault database 200 via the fault database access unit 170 and updates the fault database 200 based on the recorded fault investigation processing history.

[0096] The fault investigation and handling history retention unit 183 maintains a fault investigation and handling history that records information submitted from the fault investigation UI unit 181. More specifically, when a fault in the monitored system 300 is handled manually by the user, the fault investigation and handling history retention unit 183 maintains the execution history of the handling. The fault investigation and handling history retention unit 183 is an example of a handling history retention component.

[0097] The coping method generation unit 184 generates coping method definitions for faults based on the execution history maintained by the fault investigation and handling history retention unit 183. That is, the coping method generation unit 184 automatically generates coping method definitions by referring to the fault investigation and handling history to prepare for the possibility of a fault recurring in the future, similar to a fault that has occurred in the past. More specifically, the coping method generation unit 184 generates coping method definitions in the following manner: the user identifies the effective procedures from coping procedures implemented manually in the past and performs the identified procedures in the previously implemented sequence. The automatically generated coping method definitions are reviewed by the user, and if there are no issues, they are added to the coping method definition retention unit 130 via the coping method definition management unit 150. The coping method generation unit 184 is an example of a definition manufacturing component.

[0098] <Processing functions of the response processing unit 140>

[0099] Figure 4 This diagram illustrates an example of the processing functions of the response processing unit 140. The response processing unit 140 includes processing functions such as a log information acquisition unit 141, a user information acquisition unit 142, an upgrade execution unit 143, an action confirmation test execution unit 144, and a collaborator system operation confirmation unit 145.

[0100] The log information acquisition unit 141 is responsible for acquiring log information (action logs) before and after a fault occurs. The log information acquisition unit 141 acquires action logs from the faulty DB200 or the log management unit 320 of the monitored system 300.

[0101] The user information acquisition unit 142 is a function that retrieves attribute information (hereinafter, user information) of the user, indicating the operation recorded in the action log, from the user identifier that has been output to the action log. Examples of user information include: the user's name, the group name to which the user belongs, and information about the permissions granted to the user. The configuration of the component storing the user information is not limited, as long as the user information can be identified and retrieved through the user identifier. For example, it can be stored in advance in the fault response system 100, obtained from the monitored object system 300, or obtained from an externally prepared user information database.

[0102] The escalation execution unit 143 is a function that sends reports or requests to a pre-designated destination. Messages can be sent via email, tracking tools, or communication tools. An escalation refers to entrusting a solution to a monitored system 300 by assigning the task to personnel with more specialized knowledge or authority to find a solution sooner. There are functional escalations and hierarchical escalations. A hierarchical escalation relies on a higher-level authority (such as a manager with more authority) for judgment. This is suitable for situations where the problem cannot be resolved within the target timeframe through established procedures, or where costs are incurred. A functional escalation involves requesting an investigation from the development team (or other personnel with more specialized knowledge) to delegate the task of resolving the problem. This is suitable for situations where there is insufficient knowledge to resolve the issue.

[0103] The action verification test execution unit 144 performs automatic tests on the monitored object system 300 in response to detected faults. Automatic testing refers to verifying whether the function execution unit 310 of the monitored object system 300 has correctly performed the operations using the application. Automatic testing can include, for example, simple tests to verify whether the application is in a stopped state (completely stopped or partially stopped), or tests using several representative scenarios to verify the actions.

[0104] The collaborator system operation verification unit 145 verifies whether the collaborator system of the monitored system 300 has ceased operation. A collaborator system refers to an external system that is processed or controlled collaboratively with the functions of the monitored system 300. In addition to directly verifying the operational status of the collaborator system, it can also be done by checking whether maintenance notices have appeared in the collaborator system.

[0105] The server implementing the fault response system 100 is implemented, for example, by a computer, and as hardware, includes a CPU as a computing unit, and a main storage device and an external storage device as storage units. The CPU reads the program stored in the external storage device into the main storage device for execution. The main storage device can be, for example, RAM. The external storage device can be, for example, a disk drive or an SSD. The functions of the monitoring unit 110, the fault response method execution control unit 120, the fault response processing unit 140, the fault response method definition management unit 150, the fault response result output unit 160, the fault database access unit 170, the fault investigation UI unit 181, the fault database update unit 182, and the fault response method generation unit 184 are implemented, for example, by the CPU executing the program. Furthermore, the fault response method definition holding unit 130 and the fault investigation and processing history holding unit 183 are implemented by the CPU executing the program and by the main storage device or the external storage device as storage units.

[0106] <Operations of Fault Response System 100>

[0107] Figure 5 This is a flowchart illustrating the operations of the fault response system 100. If a fault is detected by the detection unit 330 of the monitored system 300, the monitoring unit 110 of the fault response system 100 obtains the operation log from the monitored system 300 to detect the occurrence of the fault (S501). Furthermore, the coping method execution control unit 120 compares the filtering conditions defined for each coping method (the conditions defined for applying the coping method) with the obtained operation log to determine consistency and identifies the filtering conditions consistent with the operation log (S502).

[0108] Next, the coping method execution control unit 120 sequentially applies all coping method definitions with consistent filtering conditions, specifies the parameters corresponding to the fault content, and calls the coping processing unit 140 to execute the coping processing (S503, S504). After applying all coping method definitions with consistent filtering conditions, the coping result output unit 160 determines whether the execution result of the coping processing is as expected. If it is as expected (YES in S505), the coping result output unit 160 accesses the fault DB 200 via the fault DB access unit 170 and updates the fault DB 200 using the expected information (S506). On the other hand, if the execution result of the coping processing is unexpected (NO in S505), the coping result output unit 160 accesses the fault DB 200 via the fault DB access unit 170 and updates the fault DB 200 using the unexpected information (S507).

[0109] <Example of the composition of the coping method definition>

[0110] Figure 6 This is a diagram illustrating an example of a coping method definition. In Figure 6 The coping method definitions shown include entries for definition number (“No.”), application order, filtering criteria, description, coping handling unit, parameters, and fault database update handling. The definition number (“No.”) is the identification information for each coping method definition. “Application order” indicates the order in which multiple coping method definitions are applied when their filtering criteria match the action log. For example, among coping method definitions with matching filtering criteria, those with the smallest application order value are applied sequentially.

[0111] "Filter criteria" are the conditions defined for applying each coping method; the specific conditions are strings that appear in the action log. For example, Figure 6The coping method definition shown as definition number 21 applies to situations where the action log records the string "xxx.invoker: endpoint timed out". The "Explanation" section explains the content of the filter criteria. It is recorded to help the user understand the content of the filter criteria. For example, in the coping method definition of definition number 21, the action log entry specified by the filter criteria indicates that a timeout occurred during communication with the collaborating system (recorded as "timeout from collaborating system" in the diagram), but this is recorded in the explanation section. Furthermore, the coping method definitions of definitions 1 through 3 do not specify filter criteria. Therefore, they become applicable when the filter criteria of other coping method definitions are inconsistent. Also, the explanation section records that these coping method definitions are for "handling unknown errors".

[0112] "Response Processing Unit" refers to the Response Processing Unit 140 that is executed (called out) when the response method definition is applied. For example, when applying... Figure 6 When defining the coping method as shown in definition number 22, the coping processing unit 140 (referred to as "Log Acquisition / Reference Function" in the figure) that acquires and references the action log, and the coping processing unit 140 (referred to as "Execute Action Confirmation Test" in the figure) that performs the action confirmation test are invoked and executed. Additionally, in Figure 6 In the example shown, the "AND" attribute is assigned to the "Response Processing" item, meaning that both, rather than one, perform the response processing.

[0113] "Parameters" specifies the parameters required to handle the processing content of the processing unit 140. For example, when according to Figure 6 When the handling method definition 22 shown is used to execute the handling process "log retrieval / reference function", the parameters specified are "specified time = 60 seconds", "condition = before", "filter condition = "PUT, / aaa / bbb / cccc / " "<<field 5>>"", and "assumption = log exists". Therefore, it is determined whether the string "PUT, / aaa / bbb / cccc / " exists in field 5 of the action log 60 seconds or more before the string "Unexpected Error" (the "filter condition" for definition 22) appears in the action log. If a matching string exists in field 5 of the action log, the execution result is within the assumption; if no matching string exists in field 5 of the action log, the execution result is outside the assumption. Moreover, when the handling process "retrieve user information" is executed according to the handling method definition 1, the parameter specified is "field = 9", so the information already recorded in field 9 of the action log is retrieved.

[0114] "Faulty DB Update Handling" refers to the update handling performed on faulty DB200 after the execution of the response handling. The update handling specifies the procedures for handling situations where the response handling result is as expected, and the procedures for handling situations where the response handling result is unexpected. For example, when based on... Figure 6 When the response method defined by definition number 22 is executed and the expected result is achieved, the following information is recorded in the fault DB200: "Status = Completed", "Substatus = Awaiting Comment", "IncidentLevel = 3", "Note = Meets known error No. 22", "<<Meets line>>". "<<Meets line>>" indicates a line in the action log containing the string "Unexpected error" which is the filter condition for definition number 22. Furthermore, in the case of an unexpected result, the following information is recorded in the fault DB200: "Note = Does not meet known error No. 22", "PUT before 60 seconds: <<Result 1>>", "Perform action confirmation test: <<Result 2>>".

[0115] Additionally, according to the definition of the payable method, some items may become empty. For example, in Figure 6 In the response method definition shown in definition number 21, when the filtering conditions are met, no special response processing is performed, and the following information is recorded in the fault DB200: "Status = Completed", "Sub-status = Completed", "Event Level = 3", "Comment = Meets known error No. 21". Since no response processing is performed, the items in the response processing section and parameters become empty columns. Furthermore, in the fault DB update processing, the update content is recorded in the expected processing, and the unexpected processing becomes an empty column.

[0116] <Example of application of the coping method definition>

[0117] For use Figure 6 The operation of the fault response system 100, as defined by the fault response method shown, will be explained. Examples of operations include a simple operation that does not invoke the response processing unit 140, and a complex operation that utilizes the response processing unit 140. As an example of the former, [the following is an example of the operation]. Figure 6 The action example shown is based on the coping method definition number 21, which is consistent with the definition. As an example of the latter, it is used to illustrate the action example. Figure 6 The action example shown is illustrated when the coping method definition of definition number 22 is met.

[0118] • Define the coping method for number 21 and the corresponding action example.

[0119] In the operation of the monitored system 300, a response from a collaborating system times out, and this situation is detected as a fault. When the string "xxx.caller: endpoint timeout" is included in the initially detected action log, it conforms to the response method definition of definition number 21. Furthermore, in this case, the fault content can be determined without calling the response processing unit 140. This example is a timeout that occurred midway through the communication path between the monitored system 300 and its collaborating system, i.e., client-server communication. In this case, there is no response processing required by the user, and no special recovery work is needed. Therefore, the record is left in the fault database, and the fault response is completed.

[0120] • Define the coping method for number 22 and define the action example when it is met.

[0121] If a fault is detected in the operation of the monitored system 300, the monitoring unit 110 obtains the operation log, and the response method execution control unit 120 reviews the operation log. The conditions under which a judgment can be made in this state are as follows.

[0122] 1. The detected action log contains the string "Unexpected error" (refer to the filter criteria).

[0123] 2. Logs containing the string "PUT, / aaa / bbb / cccc / " with the same request ID (output to field 5) were output more than 60 seconds ago (see parameters).

[0124] 3. The action confirmation test has ended normally. The test object is output to field 11 (reference parameter).

[0125] The following procedure will be followed.

[0126] (1) Confirm whether the acquired action log contains the string "unexpected error" by string retrieval. If it does, assume it matches the definition of the handling method, call the handling unit 140 and start handling.

[0127] (2) Retrieve the value from the fifth field of the action log. Here, we assume that the request ID is recorded in the fifth field.

[0128] (3) If an action log (line) containing the retrieved value (request ID) and the string "PUT, / aaa / bbb / cccc / " has been output exists more than 60 seconds before the fault occurred (assuming = log exists), it is considered within the assumption. For example, if the log exists 120 seconds ago, it is considered within the assumption because it is more than 60 seconds ago; if it occurs 30 seconds ago, it is considered outside the assumption because it is less than 60 seconds ago.

[0129] (4) Obtain the value from the eleventh field of the action log. Here, we assume that the code that identifies the object being tested for action confirmation is recorded in the eleventh field.

[0130] (5) Specify the acquired values ​​(identification codes) for the test object parameters and execute the action to confirm the test. If the execution result is successful (assumption = test successful), it is judged to be within the assumption.

[0131] (6) If both the action log and the action confirmation test are within the expected range, the error is determined to be known. The fault information in the fault database is updated using the information from the "expected situation" to complete the fault response. In other cases, the fault information in the fault database is updated using the information from the "unexpected situation" to complete the fault response.

[0132] <Example of a UI screen composition for troubleshooting>

[0133] Next, the UI screen provided by the fault investigation UI unit 181 will be described. The UI screen is displayed on the display device of the user's terminal device (not shown). The user's terminal device is connected to the fault response system 100, obtains the UI screen from the fault investigation UI unit 181 for display, and accepts user operations performed using the UI screen, instructing the response method generation unit 184 or the fault database update unit 182. The user's operations are performed using input devices such as a keyboard, mouse, or touch panel.

[0134] Figure 7 This diagram illustrates an example of the main operation screen in a UI. The main operation screen 400 includes a fault display bar 401, a log display bar 402, and an operation object 403. The fault display bar 401 displays information related to the detected fault. Figure 7 In the example shown, the fault ID, the time of occurrence, and information about the log group containing the action log describing the fault are displayed. The action log of the detected fault is displayed in log display bar 402.

[0135] Operation object 403 is an object used to provide instructions for handling manual operations performed by the user. Figure 7 In the example shown, the operation object 403 is equipped with four button objects: "Associate Log", "Get User Information", "Upgrade", and "Execute Automatic Test", as well as a checkbox for selecting the function to execute automatic test (response processing unit 140).

[0136] The "Associated Log" button is an operation object 403 that instructs the user to retrieve and display the action logs (hereinafter, associated logs) associated with the action logs shown in the fault display bar 401 and the log display bar 402. If the "Associated Log" button is pressed, the user will be redirected to the associated log display screen. The "Get User Information" button is an operation object 403 that instructs the user to retrieve user information. If the "Get User Information" button is pressed, information about the user whose actions have been recorded in the action log is retrieved. The "Upgrade" button is an operation object 403 that instructs the user to perform an upgrade. If the "Upgrade" button is pressed, the user will be redirected to the upgrade execution screen. The "Perform Automatic Test" button is an operation object 403 that instructs the user to perform an automatic test. If the "Automatic Test" button is pressed, an automatic test is performed using the function (response processing unit 140) selected in the checkbox, and the user will be redirected to the result display screen showing the execution results.

[0137] Figure 8 This diagram illustrates an example of a related log display screen. The related log display screen 410 includes a filter display screen 411 and a log display bar 412. The filter display screen 411 displays a string used as a filter to retrieve related logs. The log display bar 412 displays related logs containing the string displayed in the filter display screen 411. In other words, action logs retrieved using the string displayed in the filter display screen 411 as the search key are displayed as related logs in the log display bar 412. Figure 8 In the example shown, the string "F8E6002D70E457CE" is displayed in the filter display screen 411. Through the filter, the five identified action logs are displayed as associated logs in the log display bar 412.

[0138] Here, regarding the action log of the aforementioned fault, consider... Figure 6 The situation where the filtering conditions defined in the coping method definition 22 shown are met. Figure 8In the example shown, the fifth action log displayed in the log display bar 412 contains the string "Unexpected Error," which is a filter condition defined as the coping method definition number 22. Furthermore, it is investigated whether the string "PUT, / aaa / bbb / cccc / " exists in field 5 of the action log more than 60 seconds before the string "Unexpected Error" appears in the action log. Thus, the first related log is recorded 90 seconds before the fifth related log, containing the string "PUT, / aaa / bbb / cccc / " in field 5. Therefore, the first and fifth related logs are identified as action logs related to the fault. Each related log display bar has a "Report" button. If the user operates the "Report" button, information indicating that the related log displayed with the operated "Report" button is a fault-related action log is sent to the fault database update unit 182 and the coping method generation unit 184 of the fault response system 100.

[0139] In addition, Figure 8 The second to fourth action logs are displayed in log display bar 412 because they contain the string "F8E6002D70E457CE", but they are not action logs related to the fault. Therefore, in Figure 8 In the logs, they are abbreviated as log2, log3, and log4, and the specific log entries are omitted.

[0140] Figure 9 This is a diagram illustrating an example of an upgrade execution screen. The upgrade execution screen 420 includes a directory information input field 421 and a message input field 422. Figure 9 The example shown illustrates the use of email as a notification for the upgrade. The directory information input field 421 includes input boxes for entering directory information such as the message's source (From), subject (Subject), and destination (To). Furthermore, the message input field 422 includes an input box for entering the message to be sent to the recipient of the upgrade.

[0141] Figure 10 This is an example diagram showing a results display screen. The results display screen 430 includes an execution log display bar 431, a results display bar 432, and a "Report" button 433. The execution log of the automated test is displayed in the execution log display bar 431. Figure 10 In the example shown, the execution log records that function 1 selected on the main operation screen 400 was executed (see reference). Figure 7 The automated test displays the string "Function 1 test successful." in the results display column 432. Figure 10In the example shown, the execution log records information indicating that the automatic test was successfully executed. The "Report" button 433 is an operation object that sends the execution result of the automatic test to the fault response system 100. If the user operates the "Report" button, the execution result of the automatic test is sent to the fault database update unit 182 and the fault response method generation unit 184 of the fault response system 100.

[0142] If by reference Figures 7 to 10 The UI screen described above handles user manual operations, and the history information of the handling is stored by the fault investigation and handling history retention unit 183. The handling method generation unit 184 generates a new handling method definition based on the history information and the user operations already handled by the fault investigation UI unit 181.

[0143] Figure 11 This diagram illustrates an example of the history information for handling responses using the user's manual actions. The history information records: the date and time of the history information, the ID of the faulty DB200 (referred to as "Faulty DB-ID" in the diagram), information indicating the investigation and response to the fault that has been performed (referred to as "Fault Investigation / Response Function" in the diagram), and various items in the update record of the faulty DB200. When multiple faulty DB200s exist, the ID of the faulty DB200 is used to identify the faulty DB200 with recorded information. As information indicating the investigation and response to the fault, the functions performed and the parameters used when performing those functions are recorded. The update record of the faulty DB200 records the facts and supporting evidence. The facts refer to the content performed by the user in each UI screen. The supporting evidence refers to the basis upon which the user performed the content shown in the facts.

[0144] The embodiments of the present invention have been described above, but the technical scope of the present invention is not limited to the described embodiments. For example, in the described embodiments, a detection unit 330 is provided in the monitored object system 300 to detect faults and send an action log to the monitoring unit 110 of the fault response system 100. Alternatively, the detection unit 330 may not be provided in the monitored object system 300, and the monitoring unit 110 of the fault response system 100 may acquire the action log of the monitored object system 300 and detect faults. Furthermore, the monitoring unit 110 may not be provided in the fault response system 100, and the response method execution control unit 120 of the fault response system 100 may only acquire the action log containing information related to the fault detected by the detection unit 330 of the monitored object system 300 and perform response processing. In addition, various modifications or substitutions of configuration without departing from the technical spirit of the present invention are included in the present invention.

Claims

1. An information processing system, characterized by comprising: comprises: a failure information acquisition section that acquires information on a failure that has occurred in a monitored system; a countermeasure method definition holding section that holds a countermeasure method definition that describes a countermeasure method against a failure that is assumed to occur in the monitored system, the countermeasure method definition being determined based on whether a predetermined character string appears in a filter condition of an action log; a selection section that selects, from among the countermeasure method definitions held by the countermeasure method definition holding section, a countermeasure method definition that addresses a failure that has occurred in the monitored system, based on the information acquired by the failure information acquisition section; an execution section that automatically executes a countermeasure process in accordance with the countermeasure method definition selected by the selection section; a countermeasure result judgment section that judges whether an execution result of the countermeasure process executed by the execution section is a predetermined content based on a parameter of the countermeasure method by referring to the action log, rather than taking as a basis for judgment whether the failure has been eliminated; and an output section that outputs information indicating that a user's countermeasure is not required when the execution result is judged to be the predetermined content by the countermeasure result judgment section, and outputs information indicating that a user's countermeasure is required when the execution result is not the predetermined content, wherein the output section also provides an explanation of the content of the filter condition.

2. The information processing system according to claim 1, wherein the selection section selects a countermeasure method that addresses a failure that has occurred in the monitored system by classifying the occurrence situation of the situation that has occurred in the monitored system.

3. The information processing system according to claim 2, wherein the failure information acquisition section acquires the action log of the monitored system, the selection section classifies the occurrence situation of the situation that has occurred in the monitored system using a detected character string by searching for the predetermined character string from the text of the action log acquired by the failure information acquisition section.

4. The information processing system according to claim 1, characterized by, further comprising: a countermeasure history holding section that holds an execution history of a countermeasure process when the countermeasure process is performed by a user against a failure of the monitored system; and a definition creation section that creates the countermeasure method definition against the failure based on the execution history held by the countermeasure history holding section.

5. The information processing system according to claim 4, further comprising an edit operation accepting section that accepts an edit operation performed by a user with respect to the execution history held by the countermeasure history holding section.

6. The information processing system according to claim 4, further comprising an input operation accepting section that accepts an input operation of information on a countermeasure process performed by a user against a failure of the monitored system, and the countermeasure history holding section holds the information accepted by the input operation accepting section as at least a part of the execution history. ​ ​ ​

Images