JP2024027816A - Monitoring method and system - Google Patents

Abstract

[Problem] To securely execute troubleshooting of a customer system. A monitoring system includes a system and a monitoring server that monitors the system. When the monitoring server detects that a failure has occurred in the system, it registers failure response information in the storage unit. A system tool acquires the correspondence information registered in the storage unit, and executes processing on the system according to the correspondence information. [Selection diagram] Figure 1

Description

The present invention relates to a monitoring method and a monitoring system.

Conventionally, there are monitoring systems that monitor customer systems and respond to any failures that occur in the customer systems.

FIG. 13 is a diagram showing an example of a conventional monitoring system. As shown in FIG. 13, this monitoring system includes a customer system 5, an automation processing section 6, a monitoring server 7, and an ITSM (IT Service Management) server 8. A firewall 9 is arranged between the monitoring server 7 and ITSM server 8 and the automation processing unit 6 to prevent unauthorized access.

The customer system 5 is a system used by a customer, and is composed of a plurality of electronic devices. When the automation processing unit 6 receives a workaround execution command from the external monitoring server 7 through inbound communication, it executes a job corresponding to the corresponding workaround on the customer system. Although not shown, the monitoring system may further include other customer systems in addition to the customer system 5.

The monitoring server 7 is a SaaS (Software as a Service) type monitoring server, and monitors the customer system 5 and other customer systems (not shown). Here, the monitoring server 7 will be explained using the customer system 5.

When the monitoring server 7 receives a notification of the occurrence of a failure from the customer system 5, it detects the occurrence of a failure in the customer system 5, and displays information on the occurrence of the failure on a display screen or the like. When the operator of the monitoring server 7 confirms the information on the occurrence of a failure on a display screen or the like, he selects a workaround corresponding to the failure details, and sends an execution command for the selected workaround to the automation processing unit 6.

The ITSM server 8 is a SaaS type ITSM server, and stores history information such as failure details that have occurred in the customer system 5 and other customer systems (not shown), workarounds selected for the failure contents, and the like. The operator of the monitoring server 7 may refer to history information stored in the ITSM server 8 and select a workaround corresponding to the content of a new failure that has occurred in the customer system 5.

Japanese Patent Application Publication No. 2014-164457 Japanese Patent Application Publication No. 2014-32598

The failure response mechanism of the conventional monitoring system described above assumes inbound communication, and data sent from the monitoring server 7 basically passes through the firewall 9 and reaches the automation processing unit 6. Therefore, for example, it is possible for a malicious third party to use the monitoring server 7 to embed a virus or perform malicious operations on the data sent to the automation processing unit 6. There were issues with security measures.

Therefore, it is required to securely handle failures in customer systems.

In one aspect, an object of the present invention is to provide a monitoring method and a monitoring system that can securely perform failure handling of a customer system.

In the first proposal, the monitoring system includes a system and a monitoring server that monitors the system. When the monitoring server detects that a failure has occurred in the system, it registers failure response information in the storage unit. A system tool acquires the correspondence information registered in the storage unit, and executes processing on the system according to the correspondence information.

It is possible to securely respond to customer system failures.

FIG. 1 is a diagram showing an example of a monitoring system according to this embodiment. FIG. 2 is a diagram showing an example of the data structure of the failure DB. FIG. 3 is a functional block diagram showing the configuration of the automated processing device according to this embodiment. FIG. 4 is a diagram showing an example of the data structure of the processing table. FIG. 5 is a functional block diagram showing the configuration of the monitoring server. FIG. 6 is a functional block diagram showing the configuration of the ITSM server. FIG. 7 is a diagram showing an example of the data structure of the workaround management table. FIG. 8 is a diagram showing an example of the data structure of the system level management table. FIG. 9 is a flowchart showing the processing procedure of the automated processing device according to this embodiment. FIG. 10 is a flowchart showing the processing procedure of the monitoring server and the ITSM server. FIG. 11 is a diagram illustrating an example of the hardware configuration of a computer that implements the same functions as the monitoring server of the embodiment. FIG. 12 is a diagram illustrating an example of the hardware configuration of a computer that implements the same functions as the ITSM server of the embodiment. FIG. 13 is a diagram showing an example of a conventional monitoring system.

DESCRIPTION OF THE PREFERRED EMBODIMENTS Examples of the monitoring method and monitoring system disclosed in the present application will be described in detail below based on the drawings. Note that the present invention is not limited to this example.

FIG. 1 is a diagram showing an example of a monitoring system according to this embodiment. As shown in FIG. 1, this monitoring system includes customer systems 10a, 10b, and 10c, automated processing devices 20a, 20b, and 20c, a monitoring server 100, and an ITSM server 200. In this embodiment, the monitoring server 100 and the ITSM server 200 are described as separate servers, but the monitoring server 100 and the ITSM server 200 can also be implemented as a single server.

Customer systems 10a-10c are connected to automated processing devices 20a-20c, respectively. The automated processing devices 20a to 20c are each connected to a network 50 via firewalls 30a, 30b, and 30c for preventing unauthorized access from the outside. Monitoring server 100 and ITSM server 200 are connected to network 50.

The customer systems 10a to 10c are systems used by customers and are composed of a plurality of electronic devices. In the following description, customer systems 10a to 10c will be collectively referred to as "customer system 10" unless otherwise specified. The customer system 10 transmits failure information to the monitoring server 100 when a failure occurs within the own customer system 10 .

For example, the fault information includes a fault code that uniquely identifies the details of the fault, and a system identification number that uniquely identifies the customer system 10. It is assumed that the system identification number of the customer system 10a is "sys1," the system identification number of the customer system 10b is "sys2," and the system identification number of the customer system 10c is "sys3."

The monitoring server 100 monitors the customer system 10. When the monitoring server 100 receives fault information from the customer system 10, it displays the fault information on the display screen. Additionally, the monitoring server 100 transmits an incident issuance request in which failure information is set to the ITSM server 200.

Upon receiving the incident issue request, the ITSM server 200 issues an incident number and registers information regarding the fault information in the fault DB 241 .

FIG. 2 is a diagram showing an example of the data structure of the failure DB. As shown in FIG. 2, this failure DB 241 has failure tables ta1, ta2, and ta3. The failure table ta1 holds information regarding failure information of the customer system 10a. The failure table ta2 holds information regarding failure information of the customer system 10b. The failure table ta3 holds information regarding failure information of the customer system 10c. The failure DB 241 may further include failure tables of other customer systems.

The failure table ta1 will be explained. The system identification number "sys1" of the customer system 10a is set in the failure table ta1. Further, the incident number, failure code, workaround, and response flag are set in the failure table ta1.

The incident number is a number issued by the ITSM server 200. The fault code is information that uniquely identifies the fault set in the fault information. The workaround indicates how to deal with the failure identified by the failure code. For example, workarounds include checking the service status of a Windows server and checking long-running jobs. Other workarounds will be omitted.

The response flag is a flag indicating whether or not the customer system has responded to the failure. When the failure has been dealt with, "ON" is set in the handling flag. If the failure is not handled, "OFF" is set in the handling flag.

The failure table ta2 will be explained. The system identification number "sys2" of the customer system 10b is set in the failure table ta2. Further, the incident number, failure code, workaround, and response flag are set in the failure table ta2.

The failure table ta3 will be explained. The system identification number "sys3" of the customer system 10c is set in the failure table ta3. Furthermore, the incident number, failure code, workaround, and response flag are set in the failure table ta3.

In the following description, records identified by incident numbers in the failure tables ta1, ta2, and ta3 will be referred to as "incidents." For example, an incident identified by the incident number "inc_1" corresponds to a record with a failure code "error1100", a workaround "check service status of Windows server", and a response flag "OFF". In the following description, an incident whose handling flag is "OFF" will be appropriately referred to as an unhandled incident.

Returning to the explanation of FIG. The automation processing devices 20a to 20c access the fault DB 241 of the ITSM server 200 at predetermined intervals through outbound communication, and refer to the fault table corresponding to their own customer system 10. For example, the automated processing device 20a refers to the failure table ta1 corresponding to the customer system 10a. The automated processing device 20b refers to the failure table ta2 corresponding to the customer system 10b. The automated processing device 20c refers to the failure table ta3 corresponding to the customer system 10c.

The automation processing device 20a identifies unhandled incidents whose handling flag is "OFF" among the incidents in the failure table ta1, and sends a job corresponding to the workaround set to the identified incident to the customer system 10a. and execute it. In the example shown in FIG. 2, the automated processing device 20a executes a workaround job of "confirm service status of Windows server" and a job of "confirm long-time running job" on the customer system 10a. The automation processing device 20a notifies the ITSM server 200 of the processing results of "confirmation of Windows server service status" and "confirmation of long running job".

When the ITSM server 200 receives information that the workaround "Windows server service status confirmation" and "long running job confirmation" have been handled as a processing result, the ITSM server 200 executes the workaround "Windows server service status confirmation" in the failure table ta1. The response flags corresponding to "Confirm service status" and "Confirm long running job" are updated from "OFF" to "ON".

On the other hand, if the ITSM server 200 receives information indicating that the workaround "confirmation of service status of Windows server" or "confirmation of long running job" has failed as a processing result, the ITSM server 200 monitors the error information. Send to server 100. The error information includes a system identification number, an incident number corresponding to a failed workaround, and the like.

The automation processing device 20b identifies unhandled incidents among the incidents in the failure table ta2, and executes a job corresponding to the workaround set for the identified incident on the customer system 10b. The automated processing device 20b notifies the ITSM server 200 of the job processing results. Other explanations are the same as those regarding the automated processing device 20a.

The automation processing device 20c identifies unhandled records among the incidents in the failure table ta3, and executes a job corresponding to the workaround set for the identified incident on the customer system 10c. The automated processing device 20c notifies the ITSM server 200 of the job processing results. Other explanations are the same as those regarding the automated processing device 20a.

In the following description, unless the automated processing devices 20a to 20c are particularly distinguished, the automated processing devices 20a to 20c will be collectively referred to as the "automated processing device 20." The automated processing device 20 is an example of a tool of the customer system 10. The automated processing device 20 may be set within the customer system 10, or the customer system 10 may have the function of the automated processing device 20.

As described above, in the monitoring system according to the present embodiment, when the monitoring server 100 receives fault information of the customer system 10, it issues an incident issuance request to the ITSM server 200, and the ITSM server 200 issues a request to the ITSM server 200 regarding the fault information. The information is registered in the fault DB 241. Further, the automation processing device 20 accesses the failure DB 241 through outbound communication, obtains a workaround, and executes a job corresponding to the workaround on the customer system 10. In this way, since the workaround is obtained from the automation processing device 20 side through outbound communication, troubleshooting of the customer system 10 can be executed more securely than in the case of inbound communication.

Next, a configuration example of the automated processing device 20 described in FIG. 1 will be described. FIG. 3 is a functional block diagram showing the configuration of the automated processing device according to this embodiment. As shown in FIG. 3, this automated processing device 20a includes a communication section 21, a storage section 24, and a control section 25.

The communication unit 21 sends and receives information to and from the monitoring server 100 and the ITSM server 200 via the network 50. The communication unit 21 also sends and receives information to and from the customer system 10 . The communication unit 21 is realized by a NIC (Network Interface Card) or the like.

The storage unit 24 has a processing table 24a. For example, the storage unit 24 is a storage device such as a memory.

The processing table 24a is a table in which jobs corresponding to workaround are set. FIG. 4 is a diagram showing an example of the data structure of the processing table. As shown in FIG. 4, this processing table 24a associates workarounds with jobs. The description regarding the workaround is similar to the description regarding the workaround above. A job is a group of multiple programs that are executed continuously. Further, a job corresponds to a part that defines the execution order of a plurality of code parts.

Returning to the explanation of FIG. 3. The control unit 25 includes an acquisition unit 25a and an execution unit 25b. The control unit 25 is, for example, a CPU (Central Processing Unit) or an MPU (Micro Processing Unit).

The acquisition unit 25a accesses the failure table ta1 of the failure DB 241 of the ITSM server 200 at predetermined intervals. When accessing the ITSM server 200, the acquisition unit 25a notifies the system identification number of the customer system on which the job is to be executed. The acquisition unit 25a acquires workarounds for unhandled incidents among the incidents in the failure table ta1. The acquisition unit 25a may also acquire the incident number. The acquisition unit 25a outputs the acquired workaround to the execution unit 25b.

The execution unit 25b compares the workaround acquired from the acquisition unit 25a with the processing table 24a, and identifies a job corresponding to the workaround. The execution unit 25b executes the specified job on the customer system 10a. The execution unit 25b transmits the processing result to the ITSM server 200. The processing result includes an incident number and information as to whether or not the job corresponding to the workaround was successfully executed.

Here, if execution of the job fails, the execution unit 25b may retry execution of the job a predetermined number of times. If the execution of the job is not successful even after retrying the job a predetermined number of times, the execution unit 25b sets information to the effect that execution of the job corresponding to the workaround has failed in the processing result, and sends the job to the ITSM server 200. Send to.

The functional block diagrams of the automated processing devices 20b and 20c correspond to the functional block diagram of the automated processing device 20a shown in FIG. 3, and therefore their description will be omitted.

Next, a configuration example of the monitoring server 100 described in FIG. 1 will be described. FIG. 5 is a functional block diagram showing the configuration of the monitoring server. As shown in FIG. 5, this monitoring server 100 includes a communication section 110, an input section 120, a display section 130, a storage section 140, and a control section 150.

The communication unit 110 sends and receives information to and from the ITSM server 200, the automation processing device 20, and the customer system 10 via the network 50. The communication unit 110 is realized by a NIC or the like.

The input unit 120 is an input device that inputs various information to the monitoring server 100. The input unit 120 corresponds to a keyboard, a mouse, a touch panel, etc.

The display unit 130 is a display device that displays information output from the control unit 150. The display unit 130 corresponds to a liquid crystal display, an organic EL (Electro Luminescence) display, a touch panel, or the like. For example, the display unit 130 displays customers.

The storage unit 140 holds various types of information for the control unit 150 to execute processing. The storage unit 140 is a storage device such as a memory.

The control unit 150 includes an abnormality detection unit 151, a request unit 152, and a display control unit 153. The control unit 150 is, for example, a CPU, an MPU, or the like.

The abnormality detection unit 151 monitors the customer systems 10a to 10c and detects whether a failure has occurred. For example, when receiving failure information from the customer system 10, the abnormality detection unit 151 detects that a failure has occurred in the customer system 10 corresponding to the system identification number set in the failure information. The abnormality detection unit 151 outputs the received failure information to the requesting unit 152 and the display control unit 153.

The abnormality detection unit 151 may transmit data to the customer system 10 and detect an abnormality in the customer system 10 when there is no response from the destination customer system 10. In this case, the abnormality detection unit 151 generates failure information in which a failure code indicating no response and the system identification number of the customer system 10 in which the abnormality was detected is set, and the generated failure information is transmitted to the requesting unit 152 and the display control unit. 153.

When the requesting unit 152 acquires fault information from the abnormality detecting unit 151, it transmits an incident issuance request in which the fault information is set to the ITSM server 200.

The display control unit 153 causes the display unit 130 to display various information. For example, the display control unit 153 causes the display unit 130 to display failure information. When receiving error information from the ITSM server 200, the display control unit 153 causes the display unit 130 to display the error information.

Next, a configuration example of the ITSM server 200 described in FIG. 1 will be described. FIG. 6 is a functional block diagram showing the configuration of the ITSM server. As shown in FIG. 6, the ITSM server 200 includes a communication section 210, an input section 220, a display section 230, a storage section 240, and a control section 250.

The communication unit 210 transmits and receives information to and from the monitoring server 100, the automated processing device 20, and the customer system 10 via the network 50. The communication unit 110 is realized by a NIC or the like.

The input unit 220 is an input device that inputs various information to the ITSM server 200. The input unit 220 corresponds to a keyboard, mouse, touch panel, etc.

The display unit 230 is a display device that displays information output from the control unit 150. The display unit 230 corresponds to a liquid crystal display, an organic EL display, a touch panel, or the like. For example, the display unit 130 displays customers.

The storage unit 240 holds a failure DB 241, a workaround management table 242, and a system level management table 243. The storage unit 240 is a storage device such as a memory.

The failure DB 241 holds information regarding failure information. The data structure of the failure DB 241 corresponds to the data structure explained in FIG.

Workaround management table 242 defines workarounds for dealing with failures identified by failure codes. FIG. 7 is a diagram showing an example of the data structure of the workaround management table. As shown in FIG. 7, this workaround management table 242 associates failure codes with workarounds. A fault code is information that uniquely identifies a fault. Workaround is the name of a workaround for dealing with a failure. For example, the workaround (workaround name) corresponding to the failure code "error1000" is "system restart."

The system level management table 243 holds system level information of the customer system 10. FIG. 8 is a diagram showing an example of the data structure of the system level management table. As shown in FIG. 8, the system level management table 243 associates system identification numbers with system levels. The system identification number is a number that uniquely identifies the customer system 10.

The system level is a level that indicates the importance that failures in customer systems have on society. The larger the system level, the greater the importance that a customer system failure has on society. For example, the system level of the customer system 10 is one of (1), (2), and (3). The customer system at the system level (1) is a "system that has almost no social impact." The customer system at the system level (2) is a "system with limited social influence." The customer system at the system level (3) is a "system that has an extremely large social impact."

For example, the system level of the customer system 10a identified by the system identification number "sys1" is "system level (1)." Therefore, even if a failure occurs, the customer system 10a is a system that has almost no social impact.

Returning to the explanation of FIG. 6. The control unit 250 includes a receiving unit 251, a registration unit 252, and an access accepting unit 253. The control unit 250 is, for example, a CPU, an MPU, or the like.

When receiving an incident issuance request from the monitoring server 100, the receiving unit 251 outputs the failure information set in the incident issuance request to the registration unit 252.

The registration unit 252 registers information regarding the incident in the failure DB 241 based on the failure information. For example, the registration unit 252 generates a unique incident number when acquiring failure information. The registration unit 252 compares the failure code set in the failure information with the workaround management table 242 to identify the workaround corresponding to the failure code.

The registration unit 252 selects a failure table in which to register an incident based on the system identification number set in the failure information. If the system identification number is "sys1", the registration unit 252 selects the failure table ta1. If the system identification number is "sys2", the registration unit 252 selects the failure table ta2. If the system identification number is "sys3", the registration unit 252 selects the failure table ta3.

The registration unit 252 registers the incident (incident number, failure code of failure information, workaround, and handling flag <OFF>) in the selected failure table.

The access reception unit 253 receives access to the failure DB 241 from the automation processing device 20. At this time, the access reception unit 253 allows access to the failure table corresponding to the system identification number notified from the automated processing device 20. For example, the acquisition unit 25a of the automated processing device 20a acquires a workaround for an unhandled incident from the failure table ta1.

The access reception unit 253 also receives processing results for workarounds from the automation processing device 20. For example, the processing result includes an incident number and information as to whether or not the job corresponding to the workaround was successfully executed.

If the processing result includes information indicating that the job was successfully executed, the access receiving unit 253 updates the response flag corresponding to the incident number included in the processing result to "ON".

On the other hand, if the processing result includes information indicating that job execution has failed, the access reception unit 253 transmits error information to the monitoring server 100. The error information includes a system identification number, an incident number corresponding to a failed workaround, and the like.

Next, an example of the processing procedure of the automated processing device 20a shown in FIG. 1 will be described. FIG. 9 is a flowchart showing the processing procedure of the automated processing device according to this embodiment. As shown in FIG. 9, if the predetermined period of time has not elapsed (step S101, No), the acquisition unit 25a of the automated processing device 20 moves to step S101 again.

If a certain period of time has elapsed (Step S101, Yes), the acquisition unit 25a accesses the failure DB 241 of the ITSM server 200 and determines whether there is an unhandled incident (Step S102). If there is no unhandled incident (step S103, No), the acquisition unit 25a moves to step S108.

On the other hand, if there is an unhandled incident (step S103, Yes), the acquisition unit 25a acquires a workaround (step S104). The execution unit 25b of the automated processing device 20a selects a job according to the workaround based on the processing table 24a (step S105).

The execution unit 25b executes the job on the customer system 10a (step S106). The execution unit 25b transmits the job processing result to the ITSM server 200 (step S107).

If the automated processing device 20a continues the processing (step S108, Yes), the process moves to step S101. If the automated processing device 20a does not continue the processing (step S108, No), the automated processing device 20a ends the processing.

Next, the processing procedures of the monitoring server 100 and the ITSM server 200 shown in FIG. 1 will be explained. FIG. 10 is a flowchart showing the processing procedure of the monitoring server and the ITSM server. If the monitoring server 100 does not detect failure information (step S201, No), the process moves to step S201 again.

On the other hand, if the monitoring server 100 detects fault information (step S201, Yes), it transmits an incident issuance request in which the fault information is set to the ITSM server 200 (step S202).

The ITSM server 200 receives the incident issue request (step S203). The ITSM server 200 generates an incident number (step S204).

The ITSM server 200 identifies a workaround corresponding to the failure information based on the workaround management table 242 (step S205). The ITSM server 200 registers incident information in the failure DB 241 (step S206).

Next, the effects of the monitoring system according to this embodiment will be explained. In the monitoring system, when the monitoring server 100 receives fault information of the customer system 10, it issues an incident issuance request to the ITSM server 200, and the ITSM server 200 registers information regarding the fault information in the fault DB 241. Further, the automation processing device 20 accesses the failure DB 241 through outbound communication, obtains a workaround, and executes a job corresponding to the workaround on the customer system 10. In this way, since the workaround is obtained from the automation processing device 20 side through outbound communication, troubleshooting of the customer system 10 can be executed more securely than in the case of inbound communication.

The automation processing device 20 executes a job corresponding to the workaround on the customer system 10 and notifies the ITSM server 200 of the execution result. This allows the ITSM server 200 to hold information on whether or not the failure has been addressed.

The content of the processing of the monitoring system described above is an example. Below, other processes 1 to 3 of the monitoring system will be explained.

First, other processing 1 of the monitoring system will be explained. In the above description, the automated processing device 20 acquires workarounds for unhandled incidents from incidents in a determined failure table among the plurality of failure tables included in the failure DB 241. That is, the automation processing device 20a acquires a workaround from the failure table ta1, the automation processing device 20b acquires a workaround from the failure table ta2, and the automation processing device 20c acquires a workaround from the failure table ta3. However, it is not limited to this.

The automation processing device 20 may obtain a workaround from a failure table related to another customer system that is at the same system level as the customer system that is the target of the job execution, and execute the job corresponding to the workaround. .

For example, the system level of the customer system 10a and the system level of the customer system 10b are assumed to be the same. The system level of the customer system 10 is registered in the system level management table 243 of the ITSM server 200.

When the automation processing device 20a accesses the failure DB 241 of the ITSM server 200, the ITSM server 200 identifies the customer system 10b having the same system level as the customer system 10a based on the system level management table 243. The ITSM server 200 allows access to the fault table ta1 corresponding to the system identification number of the customer system 10a and the fault table ta2 corresponding to the system identification number of the customer system 10b, and the automated processing device 20a allows access to the fault table ta1, which corresponds to the system identification number of the customer system 10b. Workarounds for unhandled incidents among the incidents included in the failure table ta2 are acquired, and a job corresponding to the acquired workarounds is executed in the customer system 10a.

When the system level of the customer system 10a and the customer system 10b is the same, even if a failure has not occurred in the customer system 10a, it is possible to respond to a failure that has occurred in the customer system 10b on the customer system 10a. It may be valid in some cases. Therefore, by executing the above process, it is possible to efficiently deal with failures in the customer system 10. Here, we have explained the case where the system levels are the same, but in addition to the condition that the system levels are the same, if the system level is higher than a predetermined system level (for example, when system level (3) or higher), the above You may also perform the following processing.

Next, other processing 2 of the monitoring system will be explained. The automation processing device 20 executes a job corresponding to the workaround on the customer system 10 and notifies the ITSM server 200 of the execution result. Here, when the ITSM server 200 fails to execute a job corresponding to the workaround, it transmits error information to the monitoring server 100. When the operator of the monitoring server 100 confirms the error information, the operator of the monitoring server 100 may manually execute a predetermined job from the monitoring server 100 to the corresponding customer system.

Next, other processing 3 of the monitoring system will be explained. When the ITSM server 200 receives an incident issue request from the monitoring server 100, it issues an incident number and registers information related to the fault information in the fault DB 241, but if the workaround corresponding to the fault information is at a predetermined level or higher. In the case of a difficult workaround, information on the workaround may be notified to the monitoring server 100.

Next, an example of the hardware configuration of a computer that implements the same functions as the monitoring server 100 and the ITSM server 200 shown in the above embodiment will be described. FIG. 11 is a diagram illustrating an example of the hardware configuration of a computer that implements the same functions as the monitoring server of the embodiment.

As shown in FIG. 11, the computer 300 includes a CPU 301 that executes various calculation processes, an input device 302 that receives data input from a user, and a display 303. The computer 300 also includes a communication device 304 and an interface device 305 that exchange data with the customer system 10, the automated processing device 20, the ITSM server 200, etc. via a wired or wireless network. The computer 300 also includes a RAM 306 that temporarily stores various information and a hard disk device 307. Each device 301 to 307 is then connected to a bus 308.

The hard disk device 307 has an abnormality detection program 307a, a request program 307b, and a display control program 307c. Further, the CPU 301 reads each program 307a to 307c and expands it into the RAM 306.

The anomaly detection program 307a functions as an anomaly detection process 306a. The request program 307b functions as a request process 306b. The display control program 307c functions as a display control process 306c.

The processing of the abnormality detection process 306a corresponds to the processing of the abnormality detection unit 151. The processing of the request process 306b corresponds to the processing of the requesting unit 152. The processing of the display control process 306c corresponds to the processing of the display control unit 153.

Note that each of the programs 307a to 307c does not necessarily have to be stored in the hard disk drive 307 from the beginning. For example, each program is stored in a "portable physical medium" such as a flexible disk (FD), CD-ROM, DVD, magneto-optical disk, or IC card that is inserted into the computer 300. Then, the computer 300 may read and execute each program 307a to 307c.

Next, the explanation will move on to FIG. 12. FIG. 12 is a diagram illustrating an example of the hardware configuration of a computer that implements the same functions as the ITSM server of the embodiment.

As shown in FIG. 12, the computer 400 includes a CPU 401 that executes various calculation processes, an input device 402 that receives data input from a user, and a display 403. Further, the computer 400 includes a communication device 404 and an interface device 405 that exchange data with the customer system 10, the automated processing device 20, the monitoring server 100, etc. via a wired or wireless network. The computer 400 also includes a RAM 406 that temporarily stores various information and a hard disk device 407. Each device 401 to 407 is then connected to a bus 408.

The hard disk device 407 has a reception program 407a, a registration program 407b, and an access reception program 407c. Further, the CPU 401 reads each program 407a to 407c and expands it into the RAM 406.

The receiving program 407a functions as a receiving process 406a. Registration program 407b functions as registration process 406b. The access reception program 407c functions as an access reception process 406c.

The processing of the receiving process 406a corresponds to the processing of the receiving section 251. The processing of the registration process 406b corresponds to the processing of the registration unit 252. The processing of the access reception process 406c corresponds to the processing of the access reception unit 253.

Note that each of the programs 407a to 407c does not necessarily need to be stored in the hard disk drive 407 from the beginning. For example, each program is stored in a "portable physical medium" such as a flexible disk (FD), CD-ROM, DVD, magneto-optical disk, or IC card that is inserted into the computer 400. Then, the computer 400 may read and execute each program 407a to 407c.

10a, 10b, 10c Customer system 20a, 20b, 20c Automated processing device 30a, 30b, 30c Firewall
50 Network 100 Monitoring Server 200 ITSM Server

Claims (5)

A method for monitoring a monitoring system including a system and a monitoring server that monitors the system, the method comprising:
When the monitoring server detects that a failure has occurred in the system, the monitoring server registers response information for the failure in a storage unit,
A monitoring method characterized in that a tool of the system acquires the correspondence information registered in the storage unit and executes processing on the system according to the correspondence information. 2. The monitoring method according to claim 1, wherein the tool of the system further executes a process of notifying the monitoring server of the result of the process according to the correspondence information. The monitoring system has a plurality of systems,
The monitoring server monitors the plurality of systems, and when detecting that a failure has occurred in any one of the plurality of systems, registers correspondence information for the failure in a storage unit. The monitoring method according to claim 1, wherein: Among the plurality of systems, the tool of the first system acquires the correspondence information registered in the storage unit, and the acquired correspondence information is failure correspondence information of the tool of the second system, And, if the level of the second system (level according to social importance) is the same as the level of the first system, processing according to the failure response information of the tool of the second system. 4. The monitoring method according to claim 3, further comprising performing the following on the first system. A monitoring system comprising a system and a monitoring server that monitors the system,
When the monitoring server detects that a failure has occurred in the system, the monitoring server registers response information for the failure in a storage unit,
A monitoring system characterized in that a tool of the system acquires the correspondence information registered in the storage unit and executes processing on the system according to the correspondence information.

Images