JP2014049045A - Counter-failure system for job management system and program therefor - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a technique which stores information on countermeasures and information about failure having occurred in the past in a job management system and presents the corresponding countermeasures when failure occurs.SOLUTION: Provided is a counter-failure system for a job management system. The counter-failure system comprises: input and output means; storage means; job execution control means which controls at least one information processing device to execute a job; operation state monitoring means which monitors an operation state of the at least one information processing device; failure monitoring means which determines failure having occurred in the at least one information processing device on the basis of job execution result information; and counter-failure means which stores pieces of information about countermeasures executed against failure as pieces of counter-failure information in the storage means. The counter-failure means acquires information which corresponds to information about failure that occurred in the at least one information processing device and is determined to be failure by the failure monitoring means, from the pieces of counter-failure information, and displays the acquired information on the input and output means.

Description

  The present invention relates to a failure handling system in a job management system that executes a specified business program at a specified date and time, and the program.

  2. Description of the Related Art A job management system is used in a computer system that performs various tasks in order to perform daily operations in a scheduled manner for automatic operation. The job management system can specify an execution schedule for each job, or can distribute a job to a plurality of computers and execute the job.

  On the other hand, the configuration of the job management system has become more complex in proportion to the scale, and in the event of a failure, it takes a lot of effort, such as identifying the location of the failure, investigating the scope of influence, and examining the recovery method. It was hanging. Therefore, in order to cope with a failure, generally, a system that collects system performance information and monitors it daily is used.

JP 2001-175492 A JP 2004-287980 A JP 2007-114908 A

  Many failures that occur in the job management system are caused by environmental changes. Here, “failure” refers to abnormal termination or delay of a job, and “environmental change” refers to an increase in job amount, insufficient disk capacity, insufficient actual memory, communication failure, or the like. In addition, when a failure actually occurs, only the phenomenon of abnormal termination or delay of the job is known on the surface, and it is often difficult to investigate the environmental change that is the root cause. Therefore, the user himself / herself investigates the environmental change, which is the cause of the failure, and the user himself / herself also determines how to deal with the failure. As a result, it took a long time to respond when a failure occurred.

  The present invention has been made in view of such a situation, and provides a technique for accumulating information on failures that have occurred in the past and information on target methods in a job management system, and presenting countermeasures when failures occur.

  In order to solve the above-described problems, according to an embodiment of the present invention, there is provided a failure management system for a job management system that causes at least one information processing apparatus to execute a job. The failure handling system occurred in the input / output means, job execution result information indicating the execution result of the job, operation information indicating an operation status of the at least one information processing apparatus, and the at least one information processing apparatus. Storage means for storing failure history information indicating failure information and failure handling information indicating information relating to a countermeasure taken for a failure that has occurred in the at least one information processing device; and at least one information processing device. The job execution control means for executing the job and storing the job execution result in the storage means as the job execution result information and the operating status of the at least one information processing apparatus are monitored, and the monitored operating status Operation status monitoring means for storing information in the storage means as the operation information, and the job execution result information And determining faults occurring in the at least one information processing apparatus, storing fault information in the storage unit as the fault history information, and information relating to countermeasures taken for the faults. Fault handling means for storing in the storage means as fault handling information, wherein the fault handling means is one of the at least one information processing apparatus determined to be faulty by the fault monitoring means from among the fault handling information. Information that matches the failure information is acquired, and the acquired information is displayed on the input / output means.

  According to another embodiment of the present invention, in order to cause a computer including a calculation unit, a storage unit, and an input / output unit to execute failure handling processing of a job management system that causes at least one information processing apparatus to execute a job. Programs are provided. The program causes the computing means to cause the at least one information processing apparatus to execute the job, and stores the job execution result in the storage means as job execution result information; and the at least one information processing apparatus. Occurring in the at least one information processing device based on the operation status monitoring process for monitoring the operating status of the information processing device and storing the monitored operating status information as the operating information in the storage means, and the job execution result information A failure monitoring process for determining a failure and storing the failure information in the storage means as failure history information; and a failure handling process for storing information relating to a countermeasure taken for the failure in the storage means as failure handling information And the at least one information process determined as a fault by the fault monitoring process from the fault handling information. Acquires information that matches the information of the failure of the device, and a display process of displaying the obtained information to said output means, to the execution.

  According to the present invention, it is possible to accumulate information on a failure that occurred in the past and information on a target method in the job management system and present a coping method when a failure occurs. As a result, it becomes possible to quickly deal with a failure.

  Further features related to the present invention will become apparent from the description of the present specification and the accompanying drawings. Further, problems, configurations, and effects other than those described above will be clarified by the following description of embodiments.

1 is a system configuration diagram showing an embodiment of the present invention. It is a block diagram of the job management manager in one Example of this invention. It is a block diagram of the job execution agent in one Example of this invention. It is a block diagram of the failure response system in one Example of this invention. It is the figure which showed an example of the schedule information table and job schedule definition file which are stored in job schedule definition DB. It is a figure showing an example of a job definition table and a job definition file stored in a job definition DB. It is a figure which shows an example of the execution result table stored in execution result information DB. It is a figure which shows an example of the operation information table stored in the operation information DB for job management managers. It is a figure which shows an example of the operation information table stored in the operation information DB for job execution agents. It is a figure which shows an example of the failure history table stored in failure history DB. It is a figure which shows an example of the failure response table stored in failure response DB. It is a flowchart explaining the accumulation | storage process of failure log | history DB in a failure response system. It is a flowchart explaining the accumulation | storage process of failure response DB in a failure response system. It is an example of the screen displayed on a terminal in step 1301 of FIG. It is a flowchart explaining the presentation process of the failure handling method in a failure handling system. It is a flowchart explaining the prior detection process of the failure in a failure handling system. It is an example of the screen on the terminal which displays a failure prior detection result and updates the information of a failure response table.

  DESCRIPTION OF EMBODIMENTS Hereinafter, a failure handling system in a job management system of the present invention and an embodiment for implementing the program will be described in detail with reference to the accompanying drawings. In the following embodiments, “job” means a unit of work processed by a computer (information processing apparatus), and defines an external program corresponding to various tasks. A “job net” is a collection of a plurality of jobs, and defines the execution order of each job.

<System configuration>
FIG. 1 is a system configuration diagram showing an embodiment of the present invention. As shown in FIG. 1, in this embodiment, host machines 101 </ b> A to 101 </ b> E and a terminal 105 are connected to each other via a network 106. The host machines 101A to 101E and the terminal 105 are configured by an information processing apparatus such as a personal computer or a workstation. The host machines 101A to 101E and the terminal 105 include a central processing unit such as a CPU (Central Processing Unit), a memory, a hard disk (storage device), an input device such as a keyboard, and an output device such as a display. Yes.

  As shown in FIG. 1, a job management manager 102 is installed in the host machine 101A. In addition, job execution agents 103B to 103D are installed in the host machines 101B to 101D, respectively. Further, a failure handling system 104 is installed in the host machine 101E.

  The job execution environment includes one job management manager 102 and three job execution agents (103B to 103D). The job management manager 102 distributes the managed job to each job execution agent (103B to 103D), and each job execution agent (103B to 103D) executes the received job.

  The job distribution destination differs depending on the job contents of each job, and can be arbitrarily designated in the job management manager 102. When the job execution is completed, the job execution agents (103B to 103D) notify the job management manager 102 of the job execution result. Upon receiving the result notification, the job management manager 102 ends the execution of the corresponding job. Note that the terminal 105 can input data and output results to the job management manager 102 and the failure handling system 104 on the terminal 105.

  Hereinafter, specific configurations of the job management manager 102, the job execution agents 103B to 103D, and the failure handling system 104 will be described. The specific configurations of the job management manager 102, the job execution agents 103B to 103D, and the failure handling system 104 (each processing unit illustrated in FIGS. 2 to 4) described below realize the functions of the embodiments. You may implement | achieve with the program code of software. That is, the present embodiment can be realized by storing a predetermined program as a program code in a memory and executing the program code by the central processing unit.

  FIG. 2 is a configuration diagram of the job management manager 102. The job management manager 102 includes a job schedule definition DB 201, a job execution control unit 202, a job definition DB 206, an execution result information DB 207, an operation information DB 208, a job definition update unit 211, and an operation status monitoring unit 212. .

  The job schedule definition DB 201 stores job net schedule information. The job execution control unit 202 includes a schedule calculation unit 203, a job definition reading unit 204, and a job execution processing unit 205, and performs these controls. The schedule calculation unit 203 reads the schedule information of the job net from the job schedule definition DB 201 and calculates the schedule of each job in the job net. When the job net is started, the job definition reading unit 204 executes processing for reading the data of each job in the job net from the job definition DB 206 into the memory.

  In addition, the job execution processing unit 205 distributes an execution request of a job that has not been executed in the job net to the job execution agents (103B to 103D), and receives the job execution result from the job execution agents (103B to 103D). receive. The job execution processing unit 205 stores the execution result of the received job in the execution result information DB 207. The execution result information DB 207 stores job execution results (job status, start time, end time, statistical information, etc.) received by the job execution processing unit 205.

  The operation information DB 208 stores the operation status of the host machine 101A. In addition, the operating status monitoring unit 212 stores the monitoring result of the operating status of the host machine 101A in the operating information DB 208.

  The job management manager 102 further includes a job schedule definition file 209 and a job definition file 210. The job schedule definition file 209 describes job schedule definitions to be registered in the job schedule definition DB 201 in CSV format. In the job definition file 210, job definitions to be registered in the job definition DB 206 are described in the CSV format. The job definition update unit 211 reads the data of the job schedule definition file 209 and the job definition file 210 and stores the data in the job schedule definition DB 201 and the job definition DB 206. Therefore, when the job schedule or the job definition is changed, the job schedule definition file 209 and the job definition file 210 can be updated as described above.

  FIG. 3 is a configuration diagram of the job execution agents (103B to 103D). The job execution agents (103B to 103D) include a job execution unit 301, an operation status monitoring unit 302, and an operation information DB 303.

  The job execution unit 301 receives a job execution request from the job execution processing unit 205 of the job management manager 102, and generates and executes a job process in response to the received request. In addition, the job execution unit 301 notifies the job execution processing unit 205 of “normal end” when the generated process ends normally, and “abnormal end” when the process is generated abnormally. The operation information DB 303 stores the operation status of the host machines (101B to 101D). The operating status monitoring unit 302 stores the operating status monitoring results of the host machines (101B to 101D) in the operating information DB 303.

  FIG. 4 is a configuration diagram of the failure handling system 104. The failure handling system 104 includes a failure monitoring unit 401, a failure handling unit 402, a failure advance detection unit 403, a failure information input unit 404, a failure history DB 405, and a failure handling DB 406.

  The failure history DB 405 stores information on failures that have occurred in the past, and the failure handling DB 406 stores information such as coping methods implemented for failures that have occurred in the past. The failure monitoring unit 401 monitors the failure status of each of the host machines 101A to 101D, and stores a failure information in the failure history DB 405 when a failure has occurred. Further, when a failure has occurred, the failure handling unit 402 compares the failure information with the failure handling DB 406 to search for a handling method for the failure, and transmits the search result to the terminal 105. Further, the failure information input unit 404 receives input of a failure that has occurred and a coping method that has been implemented for the failure, and stores the input information in the failure handling DB 406. In addition, the failure prior detection unit 403 detects a failure in advance by comparing the operation status acquired from the operation information DB (208, 303) of each of the host machines 101A to 101D with the information in the failure handling DB 406.

<Database configuration>
The configuration of each DB used in the present embodiment will be described below. In the following description, the information of the present invention will be described using a “table” structure. However, the information does not necessarily have to be expressed by a table data structure, and may be expressed by another data structure. . Therefore, in order to show that it does not depend on the data structure, it may be simply referred to as “information” below. Each DB described below is stored in the hard disk (storage device) of each information processing apparatus.

  FIG. 5 is a diagram showing an example of a schedule information table and a job schedule definition file stored in the job schedule definition DB 201. The schedule information table 501 includes a job net name 502, a start time 503, and a processing cycle 504 as configuration items. The job net name 502 is a name for uniquely identifying the job net. The start time 503 is a start time set for each job net. A processing cycle 504 is a job net processing cycle.

  In the job schedule definition file 505, information corresponding to each item of the schedule information table 501 is stored in a comma delimited (CSV format). The job definition update unit 211 reads the job schedule definition file 505 and performs import processing, whereby each row of the job schedule definition file 505 is stored as a record in the schedule information table 501. In the illustrated example, a schedule is defined in which JobNetA starts at 00:00 every day, JobNetB starts at 10:15 on the 15th of every month, and JobNetC starts at 03:00 every Thursday.

  FIG. 6 is a diagram illustrating an example of a job definition table and a job definition file stored in the job definition DB 206. The job definition table 601 includes job net / job name 602, upper job net name 603, preceding job name 604, execution destination agent name 605, and execution program 606 as configuration items.

  The job net / job name 602 is a name for uniquely identifying a job net or a name for uniquely identifying a job. The upper job net name 603 indicates the upper job net name including the corresponding job. A preceding job name 604 indicates a job preceding the corresponding job. The execution destination agent name 605 indicates the execution destination of the corresponding job, and is one of the host machines (101B to 101D) in this embodiment. Furthermore, the execution program 606 indicates a path of an external program for executing the job.

  In the job definition file 607, information corresponding to each item of the job definition table 601 is stored in comma delimited (CSV format). When the job definition update unit 211 reads the job definition file 607 and performs import processing, each row of the job definition file 607 is stored as a record in the job definition table 601. In the illustrated example, there are jobs “JobA-1” and “JobA-2” under the job net “JobNetA”. The job “JobA-1” is the first job in the job net, “host machine 101B” is designated as the execution destination agent name 605, and “/opt/xxxx/xxx.sh” is designated as the execution program 606. Has been. For the job “JobA-2”, the preceding job is “JobA-1”, “host machine 101D” is specified as the execution destination agent name 605, and “/opt/yyyy/yy.sh” is specified as the execution program 606 Has been. If there is no setting such as the preceding job name 604 of the job “JobA-1”, no value is set.

  FIG. 7 is a diagram illustrating an example of an execution result table stored in the execution result information DB 207. The execution result table 701 includes job net / job name 702, status 703, start time 704, and end time 705 as configuration items.

  The job net / job name 702 is a name for uniquely identifying a job net or a name for uniquely identifying a job. The status 703 indicates the status of the corresponding job net or job. For example, “in execution”, “normal termination”, “abnormal termination”, or the like is set. The start time 704 indicates the time when the corresponding job net or job is started. An end time 705 indicates the time when the corresponding job net or job ends. Here, the job net / job name 702, the status 703, and the start time 704 are stored when the job net or job starts, and the status 703 and the end time 705 are updated when the job net or job ends.

  FIG. 8 is a diagram illustrating an example of an operation information table stored in the operation information DB 208 for the job management manager 102. The operation information table 801 includes a monitoring time zone 802, an average CPU usage rate 803, an average memory usage rate 804, an average disk I / O 805, a job distribution number 806, a user operation amount 807, and a DB usage rate 808. The number of DB records 809 is included as a configuration item. A monitoring time zone 802 indicates a time zone during which the operation information of the job management manager 102 is monitored. In this embodiment, one record is stored every 5 minutes, but one record may be stored at other time intervals.

  The average CPU usage rate 803 is an average CPU usage rate of the host machine 101A in the corresponding time zone. The average memory usage rate 804 is the average memory usage rate of the host machine 101A in the corresponding time zone. The average disk I / O 805 indicates the average of the proportion of the disk I / O time of the host machine 101A in the corresponding time zone. The job distribution number 806 indicates the total number of jobs distributed from the job execution processing unit 205 of the job management manager 102 to the job execution agents (103B to 103D) in the corresponding time zone.

  The user operation amount 807 indicates the total amount of operations performed by the user on the job management manager 102 during the corresponding time period. The DB usage rate 808 indicates the average of the ratios of used areas in the job schedule definition DB 201, job definition DB 206, execution result information DB 207, and operation information DB 208 in the corresponding time zone. The number of DB records 809 indicates the number of records stored in the job schedule definition DB 201, job definition DB 206, execution result information DB 207, and operation information DB 208 in the corresponding time zone. For each item in the operation information table 801, the operation status monitoring unit 212 collects corresponding data from the host machine 101A and the job management manager 102 at regular intervals. The operation status monitoring unit 212 stores the collected data in the operation information table 801 as a record line by line.

  FIG. 9 is a diagram illustrating an example of an operation information table stored in the operation information DB 303 for job execution agents (103B to 103D). The operation information table 901 includes a monitoring time zone 902, a CPU usage rate 903, a memory usage rate 904, a disk I / O 905, and a job execution count 906 as configuration items.

  A monitoring time zone 902 indicates a time zone during which the operation information of the job execution agents (103B to 103D) is monitored. The CPU usage rate 903 is an average CPU usage rate of the host machine (101B to 101D) in the corresponding time zone. The memory usage rate 904 is an average memory usage rate of the host machines (101B to 101D) in the corresponding time zone.

  The disk I / O 905 indicates the average of the ratio of the disk I / O time of the host machine (101B to 101D) in the corresponding time zone. The job execution number 906 indicates the total number of jobs executed by the job execution unit 301 of the job execution agents (103B to 103D) in the corresponding time period. For each item in the operation information table 901, the operation status monitoring unit 302 collects corresponding data at regular intervals from the host machines (101B to 101D) and the job execution agents (103B to 103D). The operation status monitoring unit 302 stores the collected data in the operation information table 901 as a record line by line.

  FIG. 10 is a diagram illustrating an example of a failure history table stored in the failure history DB 405. The failure history table 1001 includes a failure-occurring host machine 1002, a failure occurrence date and time 1003, and a phenomenon 1004 as configuration items. The failure occurrence host machine 1002 indicates the host machines (101A to 101D) where the failure has occurred. The failure occurrence date and time 1003 indicates the time when the failure occurred in the corresponding host machine (101A to 101D). A phenomenon 1004 indicates a specific phenomenon that has occurred in the corresponding host machine (101A to 101D). Each item of the failure history table 1001 is stored when the failure monitoring unit 401 monitors the failure status of each of the host machines 101A to 101D and determines that a failure has occurred.

  FIG. 11 is a diagram illustrating an example of a failure handling table stored in the failure handling DB 406. The failure handling table 1101 includes a host machine 1102, a phenomenon 1103, a cause 1104, a failure pre-determination condition 1105, and a coping method 1106 as configuration items. A host machine 1102 indicates a host machine that is a target of failure handling. A phenomenon 1103 indicates a specific phenomenon that has occurred in the corresponding host machine. The cause 1104 indicates the cause of the phenomenon that occurred in the corresponding host machine.

  The failure pre-determination condition 1105 is set with a condition for handling before a failure occurs even when no failure has occurred as a result of the operation status monitoring. Here, conditions such as the number of job distributions, the number of job executions, the memory usage rate, and the DB usage rate are set. For example, conditions relating to the configuration items of the operation information tables 801 and 901 can be set as the failure prior determination condition 1105. The coping method 1106 indicates a coping method when a failure occurs or when the failure pre-determination condition 1105 is satisfied. For each item in the failure handling table 1101, the failure information input unit 404 receives input information from the terminal 105 and stores the input information in the failure handling table 1101.

<Processing in the failure response system>
Next, processing in the failure handling system 104 will be described. FIG. 12 is a flowchart for explaining the accumulation process of the failure history DB 405 in the failure handling system 104. Here, a process from when the failure handling system 104 monitors the failure of each host machine (101A to 101D), stores information in the failure history DB 405, and notifies the terminal 105 of the failure will be described.

  In step 1201, the failure monitoring unit 401 refers to the execution result information DB 207 of the host machine 101A and acquires the job execution result. Next, in step 1202, the failure monitoring unit 401 determines whether a failure has occurred based on the information in the execution result table 701. For example, if the status 703 of the execution result table 701 is “abnormal end”, it can be determined that the job has ended abnormally. As another method, the failure monitoring unit 401 may acquire information on the start time 503 in the schedule information table 501 and determine the delay by comparing with the start time 704 in the execution result table 701. If the record itself is not created in the execution result table 701 even when the start time comes, it can be determined that the start of the job net itself is delayed. Further, the failure monitoring unit 401 may determine whether each job in the current processing cycle is delayed by comparing with the time when the processing is normally completed in the past processing cycle in the execution result table 701. If a failure has occurred, the process proceeds to step 1203. If a failure has not occurred, the process ends.

  When the processing proceeds to step 1203, the failure monitoring unit 401 stores information on the failure that has occurred in the failure history DB 405. The fault monitoring unit 401 can acquire information in the job definition DB 206 of the host machine 101A and store the item of the faulty host machine 1002 in the fault history table 1001. For the phenomenon 1004 in the failure history table 1001, information on the phenomenon determined in step 1202 is stored.

Next, in step 1204, the failure monitoring unit 401 notifies the terminal 105 of the failure that has occurred. At this time, the failure monitoring unit 401 acquires the failure information stored in the failure history DB 405 and the operation information of the time zone corresponding to the failure from the operation information DB (208 or 303) of the host machine where the failure has occurred. To the terminal 105.
By periodically performing the above processing, it is possible to notify the terminal 105 of a failure while accumulating failure information in the failure history DB 405.

  Next, another process in the failure handling system 104 will be described. FIG. 13 is a flowchart for explaining the accumulation processing of the failure handling DB 406 in the failure handling system 104. Here, a process until the failure handling system 104 receives input information from the terminal 105 and stores the information in the failure handling DB 406 will be described.

  In step 1301, the failure information input unit 404 receives from the terminal 105 information on the cause of the failure that has occurred, a method for dealing with the failure, and a failure prior determination condition. Here, screens used in the terminal 105 will be described later. Next, in step 1302, the failure information input unit 404 stores the received information in the failure handling DB 406. By performing the above processing, information related to failure handling is accumulated in the failure handling DB 406.

  FIG. 14 is an example of a screen displayed on the terminal 105 in step 1301 of FIG. The screen of FIG. 14 includes a failure history display unit 1401, a failure operating status display unit 1402, and a failure handling information display unit 1403.

  The failure history display unit 1401 displays information corresponding to the records in the failure history table 1001 of the failure history DB 405. That is, the failure history display unit 1401 displays a failure occurrence host machine 1413, a failure occurrence date and time 1414, and a phenomenon 1415. Also, the operation status display section 1402 at the time of failure displays information corresponding to the record of the operation information table (801 or 901) of the host machine where the failure has occurred.

  In the failure handling information display unit 1403, a text box corresponding to the record of the failure handling table 1101 is displayed. In the failure handling information display unit 1403, a host machine 1404, a phenomenon 1405, a failure cause 1407, a failure prior determination condition 1408, and a coping method 1409 are displayed. Here, the failure handler (the user of the terminal 105) performs input to the failure handling information display unit 1403 based on the information of the failure history display unit 1401 and the failure-time operation status display unit 1402. Since the host machine 1404 and the phenomenon 1405 are obvious from the failure-occurring host machine 1002 and the phenomenon 1004 in the failure history table 1001, they are already input.

  The failure handler responds to the failure cause 1407 that is the cause of the failure, the failure prior judgment condition 1408 that is a condition for prior notification before the same phenomenon occurs in the future, and the action to be taken when the phenomenon occurs (this time (Coping method implemented for failure) 1409 is input. In this example, the failure cause 1407, the failure pre-determination condition 1408, and the coping method 1409 are text boxes, but may be selected from a plurality of options prepared in advance.

  Eventually, the failure handler inputs the data, and then presses a [failure handling information registration] button 1410 at the bottom of the screen. Thereby, the input information is transmitted from the terminal 105 to the failure information input unit 404 of the failure handling system 104, and then the failure information input unit 404 stores the received information in the failure handling DB 406.

  Next, another process in the failure handling system 104 will be described. FIG. 15 is a flowchart for explaining a coping method presentation process executed by the failure handling unit 402 of the failure handling system 104.

  First, in step 1501, the failure handling unit 402 acquires failure information of the host machines (101A to 101D). Here, the failure handling unit 402 can acquire the failure information of the host machines (101A to 101D) in conjunction with the failure determination processing (the processing of FIG. 12) in the failure monitoring unit 401. For example, the failure handling unit 402 may acquire the failure information from the failure monitoring unit 401 at a stage after the failure monitoring unit 401 determines the occurrence of a failure (step 1203 in FIG. 12 and the like).

  Next, in step 1503, the failure handling unit 402 reads the failure handling table 1101 of the failure handling DB 406. Next, in step 1504, the failure handling unit 402 causes the host machine and phenomenon information in the failure information acquired in step 1501, and the host machine 1102 and phenomenon in the record of the failure handling table 1101 read in step 1503. 1103 is compared to determine whether both match.

  Next, in step 1505, when a matching record in the failure handling table 1101 is found in the determination in step 1504, the cause 105 of the record and the coping method 1106 are notified to the terminal 105. When there are a plurality of matching records, a plurality of countermeasures may be notified to the terminal 105. The terminal 105 displays the notified cause 1104 and coping method 1106 on the display device. Here, if the notification to the terminal 105 in step 1505 is completed, or if no matching record is found in the determination in step 1504, the process returns to step 1502. Then, the failure handling unit 402 repeatedly executes the processing of steps 1503 to 1505 until the end of the record.

  The cause 1104 and the countermeasure 1106 notified to the terminal 105 may be displayed together with the screen shown in FIG. Further, the terminal 105 may display the cause 1104 and the countermeasure 1106 on a screen different from that in FIG. In this case, the terminal 105 records the failure history table 1001 corresponding to the failure, the record of the operation information table (801 or 901) of the host machine 101A to 101D in which the failure occurred, the notified cause 1104, and the countermeasure. Method 1106 may be displayed on a display device.

  Next, another process in the failure handling system 104 will be described. FIG. 16 is a flowchart for explaining failure pre-detection processing executed by the failure pre-detection unit 403 of the failure handling system 104.

  First, in step 1601, the failure prior detection unit 403 acquires operation information from the operation information DB (208, 303) of each of the host machines 101A to 101D. For example, the failure pre-detection unit 403 acquires operation information at time intervals at which the operation status monitoring units (212, 302) of the host machines 101A to 101D store information in the operation information DB (208, 303).

  Next, in step 1603, the failure prior detection unit 403 reads the failure handling table 1101 of the failure handling DB 406. Next, in step 1604, the failure pre-detection unit 403 determines whether the host machine of the record of the operation information table (801, 901) of each of the host machines 101A to 101D acquired in step 1601 and the host machine 1102 of the failure handling table 1101. It is determined whether the values match and the values of the items in the records of the operation information tables (801, 901) of the host machines 101A to 101D satisfy the failure pre-determination condition 1105 of the failure handling table 1101.

  Next, in step 1605, when a record of the failure correspondence table 1101 that satisfies the determination in step 1604 is found, the failure pre-detection unit 403 determines that the operating status of the host machines 101A to 101D is in a dangerous state, The terminal 105 is notified of the record information (the host machine 1102, the phenomenon 1103, the cause 1104, the failure prior determination condition 1105, and the coping method 1106) in the failure handling table 1101. The terminal 105 displays the notified information on the display device. In addition, when there are a plurality of matching records, a plurality of detection results may be notified to the terminal 105. Here, when the notification to the terminal 105 in step 1605 is completed, or when no matching record is found in the determination in step 1604, the process returns to step 1602. Then, the failure prior detection unit 403 repeatedly executes the processing of steps 1603 to 1605 until the end of the record.

  The information notified to the terminal 105 is displayed on a screen different from the screen shown in FIG. In this case, the terminal 105 records the operation information tables (801, 901) of the host machines 101A to 101D that are determined to be in a dangerous state, the host machine 1102, the cause 1104, and the failure of the failure correspondence table 1101. A prior determination condition 1105 and a coping method 1106 are displayed.

  FIG. 17 is an example of a screen on the terminal 105 that displays the failure pre-detection result and updates the information in the failure handling table 1101. The screen of FIG. 17 includes a failure prior detection result display unit 1701, an operation state display unit 1702 at the time of prior detection, and a failure handling information display unit 1703.

  Information on a fault detected in advance by the fault pre-detection unit 403 is output to the fault pre-detection result display unit 1701. Here, the host machine 1710 in which the operation status is determined to be a dangerous state, the time zone 1711 detected in advance (information corresponding to the monitoring time zones 802 and 902 of the operation information table 801 and 901), and the phenomenon 1712 (information corresponding to the phenomenon 1103 in the failure correspondence table 1101) is displayed on the failure prior detection result display unit 1701. In addition, the pre-detection operation status display unit 1702 displays a record of the operation information table (801 or 901) of the host machine 1710 in the time zone 1711.

  In the failure handling information display unit 1703, a text box corresponding to the record of the failure handling table 1101 is displayed. That is, the failure handling information display unit 1403 displays the host machine 1704, the phenomenon 1705, the cause of failure 1706, the failure prior determination condition 1707, and the coping method 1708. Here, the person who responds to the failure (the user of the terminal 105) can determine whether it is necessary to deal with the failure based on the information in the failure prior detection result display unit 1701 and the operation state display unit 1702 at the time of prior detection.

  In addition, if the person corresponding to the failure needs to change the information displayed on the failure correspondence information display unit 1703, the information on the failure correspondence information display unit 1703 is changed, and then a [failure correspondence information update] button 1709 at the bottom of the screen is displayed. By pressing the button, the updated information can be transmitted to the failure information input unit 404 of the failure handling system 104. Thereafter, the failure information input unit 404 updates the information of the record in the corresponding failure handling table 1101. As a result, the failure prior determination conditions of the host machines 101A to 101D in which the failure is detected in advance can be reset to a more appropriate condition, and the accuracy of the failure prior detection can be further improved while operating the system. In addition, it is possible to update and accumulate the cause of the failure and the coping method with more appropriate contents.

  According to this embodiment, the job management system can determine the failure of each of the host machines 101A to 101D from the job execution result and notify the terminal 105 of the failure information. Thereby, it is possible to promptly notify the failure handler of the failure. Further, according to this embodiment, when a failure occurs in the host machines 101A to 101D, information such as a countermeasure for the failure of the host machines 101A to 101D can be accumulated in the failure correspondence table 1101. When a failure occurs, a record corresponding to the failure is searched in the failure correspondence table 1101 and the matched record is output to the terminal 105. Thereby, based on the history of the coping method implemented with respect to the fault that has occurred in the past, the coping method for the fault that has occurred this time can be examined. As a result, it becomes possible to quickly deal with a failure.

  Further, according to the present embodiment, information (cause 1104) that causes the failure is also displayed on the terminal 105 together with the handling method 1106 of the failure handling table 1101. Therefore, the person with a disability can quickly determine the cause of the disability. Furthermore, according to the present embodiment, a record of the operation information table (801, 901) corresponding to the occurrence of a failure is also displayed on the terminal 105. Therefore, it is possible to easily investigate changes in the environment that are the cause of failure.

  Further, according to the present embodiment, when a failure occurs, the failure pre-determination condition 1105 is stored in the failure handling table 1101 together with the handling method 1106. According to this configuration, the operation information of the host machines 101A to 101D is automatically collected during operation of the job management system, it is determined whether the collected operation information satisfies the failure prior determination condition 1105, and the host machines 101A to 101D. Can be detected in advance. Further, since the terminal 105 displays not only the prior detection of the failure but also a countermeasure 1106, it is possible to prevent the occurrence of the same problem as the failure that has occurred in the past, or to quickly deal with the occurrence of the failure. Can do.

  Further, according to the present embodiment, the contents of the failure handling table 1101 can be updated when a failure is detected in advance. As a result, the failure prior determination conditions of the host machines 101A to 101D in which the failure is detected in advance can be reset to a more appropriate condition, and the accuracy of the failure prior detection can be further improved while operating the system. In addition, it is possible to update and accumulate the cause of the failure and the coping method with more appropriate contents.

  As described above, the present invention is characterized in that various environmental information is automatically collected when a failure occurs, and the investigation when the failure occurs can be facilitated. Furthermore, the present invention has a user interface that can record the judgment criteria and countermeasures of the failure factor as a result of the failure investigation, can monitor the failure factor during operation, and prevent similar problems from occurring. Or can be quickly dealt with when it occurs.

<Modification>
The present invention is not limited to the above-described embodiments, and includes various modifications. For example, the terminal 105 that performs failure notification / input may be composed of a plurality of terminals. In the embodiment of FIG. 1, the job management manager 102, job execution agents (103B to 103D), the failure handling system 104, and the like are incorporated in separate information processing apparatuses. It may be incorporated into the device.

  Further, the failure correspondence table 1101 may be provided with a field for storing the referenced frequency so that the host machines 101A to 101D in which failures frequently occur are output to the terminal 105. In addition, referring to the value of the field that stores the frequency, a method of dealing with a record that has been referred to more frequently may be preferentially presented.

  Furthermore, a field for storing “importance” may be provided in the failure handling table 1101 and input when dealing with a failure. It may be configured such that when the failure occurs, the “importance” is also displayed on the terminal 105, so that the failure handling person can easily consider the priority of the response.

  The above-described embodiment has been described in detail for easy understanding of the present invention, and is not necessarily limited to the one having all the configurations described. In addition, it is possible to add, delete, and replace other configurations for a part of the configuration of each embodiment. For example, in the point of presenting a coping method based on a past fault handling history, the fault handling table 1101 stores at least information on the coping method, and the fault handling unit 402 sends at least the coping method to the terminal 105. Just notify. The configuration including all the embodiments described above is a more preferable embodiment of the present invention, and it is possible to delete the part of the configuration described as the embodiment and configure the present invention.

  Also, those skilled in the art will appreciate that there are numerous combinations of hardware, software, and firmware that are suitable for practicing the present invention. For example, the program code for realizing the functions described in the present embodiment can be implemented by a wide range of programs or script languages such as assembler, C / C ++, perl, Shell, PHP, Java (registered trademark).

101A: Host machine 101B: Host machine 101C: Host machine 101D: Host machine 101E: Host machine 102: Job management manager 103B: Job execution agent 104: Failure response system 105: Terminal 106: Network 201: Job schedule definition DB
202: Job execution control unit 203: Schedule calculation unit 204: Job definition reading unit 205: Job execution processing unit 206: Job definition DB
207: Execution result information DB
208: Operation information DB
209: Job schedule definition file 210: Job definition file 211: Job definition update unit 212: Operation status monitoring unit 301: Job execution unit 302: Operation status monitoring unit 303: Operation information DB
401: Failure monitoring unit 402: Failure handling unit 403: Failure prior detection unit 404: Failure information input unit 405: Failure history DB
406: Failure handling DB

Claims (6)

A failure management system for a job management system that causes at least one information processing apparatus to execute a job,
Input / output means;
Job execution result information indicating an execution result of the job, operation information indicating an operation status of the at least one information processing apparatus, failure history information indicating information on a failure that has occurred in the at least one information processing apparatus, Storage means for storing failure handling information indicating information relating to a countermeasure taken for a failure occurring in at least one information processing apparatus;
Job execution control means for causing the at least one information processing apparatus to execute the job, and storing the execution result of the job in the storage means as the job execution result information;
An operating status monitoring unit that monitors an operating status of the at least one information processing apparatus, and stores the monitored operating status information in the storage unit as the operating information;
A fault monitoring unit that determines a fault that has occurred in the at least one information processing apparatus based on the job execution result information, and stores the fault information in the storage unit as the fault history information;
Failure handling means for storing in the storage means information relating to the countermeasure taken for the fault as the fault handling information;
With
The failure handling unit obtains information that matches the failure information of the at least one information processing apparatus determined to be a failure by the failure monitoring unit from the failure handling information. A fault response system characterized by being displayed on an entry output means. The failure handling system according to claim 1,
The storage means stores, as the failure handling information, information on a coping method implemented for the failure and information on the cause of the failure,
The failure response system, wherein the failure response means causes the input / output means to display information on the coping method and information on the cause of the failure. In the failure handling system according to claim 1 or 2,
A failure prior detection means for detecting in advance a failure that has occurred in the at least one information processing apparatus;
The storage means further stores determination condition information for detecting the failure in advance as the failure handling information,
The failure prior detection means is
Determining whether information on the operating status of the at least one information processing apparatus monitored by the operating status monitoring unit satisfies the determination condition information;
When the determination condition information is satisfied, the failure handling system displays the failure handling information on the input / output unit. In the failure handling system according to claim 3,
The failure handling means receives updated information of the failure handling information displayed on the input / output means, and stores the updated information as the failure handling information in the storage means system. In the failure response system according to any one of claims 1 to 4,
The failure handling system displays the operation information corresponding to when the failure occurs together with the acquired information on the input / output unit. A program for causing a computer including a calculation unit, a storage unit, and an input / output unit to execute failure handling processing of a job management system that causes at least one information processing apparatus to execute a job,
In the calculation means,
A job execution control process for causing the at least one information processing apparatus to execute the job, and storing the execution result of the job in the storage unit as job execution result information;
An operational status monitoring process for monitoring the operational status of the at least one information processing apparatus and storing the monitored operational status information in the storage means as operational information;
A fault monitoring process for determining a fault that has occurred in the at least one information processing apparatus based on the job execution result information, and storing the fault information as fault history information in the storage unit;
A failure handling process for storing information relating to a countermeasure taken for the failure in the storage unit as failure handling information;
The information corresponding to the failure information of the at least one information processing apparatus determined to be a failure by the failure monitoring process is acquired from the failure handling information, and the acquired information is displayed on the input / output unit. Display processing,
A program for running

Images