JP2006293467A - Fault monitoring system - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a fault monitoring system capable of accuratly and quickly dealing with occurred fault and preventing its reoccurrence, and capable of minimizing the effect of the fault on an operation system. <P>SOLUTION: When the occurrence of fault is detected by a notification distribution processing part 1, the fault contents are transmitted through a communication control part 7 to a predetermined notification destination by a mail transmission processing part 6, and the fault contents and the notification destination are stored so as to be associated with each other in a notification information DB 11 by a notification information storage processing part 3, and the result of countermeasure to the notified fault is received and stored in a notification status management DB 9 by a countermeasure result report registration processing part 4, and the regular transmission of a follow mail is operated until the countermeasures are completed by a status check/follow mail transmission processing part 5. <P>COPYRIGHT: (C)2007,JPO&INPIT

Description

  The present invention relates to a failure monitoring technique in a system composed of a plurality of devices such as a telephone line and a computer network, and more particularly to a monitoring technique that is effective for identifying the cause of a failure that has occurred and preventing the recurrence of the failure.

  In a network such as a telephone line, a LAN, or an intranet, a monitoring device connected to the network is automatically generated when a failure occurs in each device connected to the network for the purpose of stable operation. A failure monitoring system that collects information related to a failure and notifies a predetermined notification destination is implemented.

  For example, Patent Document 1 discloses a technology related to an automatic failure notification device that can control the notification of failure information according to the failure level and occurrence frequency.

  However, although this technology detects and notifies notification events (failures), it does not check whether the processing and countermeasures for the notification events are actually implemented, and recovery when a failure occurs. May be delayed.

Japanese Patent Laid-Open No. 06-168160

  The problems to be solved are that the conventional technology can detect and notify the occurrence of a failure, but cannot confirm whether the failure information has arrived at the notification destination. It is not possible to monitor whether and how the measures / measures for the above were actually executed.

  The object of the present invention is to solve these problems of the prior art, enable a reliable and quick response to a failure that has occurred, prevent a recurrence of a failure that has occurred once, and use a network. It is possible to minimize the impact of failures on business systems.

  In order to achieve the above object, in the present invention, not only the occurrence of a failure is notified, but the treatment content executed as a countermeasure against the notified failure is registered for each failure, and displayed on a display device or the like, for example. In addition, if no countermeasure is taken for the notified failure and the failure has not been resolved, information on the failure is periodically notified to a predetermined notification destination and followed. At that time, it is monitored, for example, in three stages to determine how far the measure against the failure has been completed. There are three stages of monitoring and follow-up: (1) Direct measures for reported failures, (2) Investigation of effects on business systems caused by the failures and countermeasures, (3) Prevention of recurrence for future identical failures There is a solution. In this way, it is possible to confirm whether or not failure information has been notified to the notification destination, and it is efficient to take measures against the notified failure, its impact on the business and measures, and prevent future recurrence. Can follow.

  According to the present invention, it is possible not only to detect and notify the occurrence of a failure, but also to check whether the failure information has surely arrived at the notification destination and to actually execute the measures and countermeasures for the notified failure. It is possible to monitor the failure and how it was done, and to prevent the failure of notification of failure information. It is possible to prevent the recurrence of the problem and minimize the influence of the failure on the business system using the network.

  The best mode for carrying out the present invention will be described below with reference to the drawings. 1 is a block diagram showing a configuration example of a failure monitoring system according to the present invention, FIG. 2 is a flowchart showing an example of processing operation of a report ID acquisition processing unit in FIG. 1, and FIG. 3 is report information in FIG. FIG. 4 is a flowchart showing an example of the processing operation of the countermeasure result report registration processing unit in FIG. 1, and FIG. 5 is a processing operation of the status check / follow mail transmission processing unit in FIG. FIG. 6 is an explanatory diagram showing an example of registered contents of the report ID information DB in FIG. 1, FIG. 7 is an explanatory diagram showing an example of registered contents of the report information DB in FIG. 1, and FIG. FIG. 9 is an explanatory diagram showing an example of registered contents of the report countermeasure completion DB in FIG. 1.

  In FIG. 1, 1 is a report distribution processing unit, 6 is a mail transmission processing unit, 7 is a communication control unit (NCU), and 8 is a countermeasure mail reception processing unit, which are known techniques.

  On the other hand, the notification countermeasure management processing unit 13 in FIG. 1 provides a function that is particularly characteristic of the present invention. The notification countermeasure management processing unit 13 includes the notification ID acquisition processing unit 2, the notification information storage processing unit. 3, a countermeasure result report processing unit 4, a status check / follow mail transmission processing unit 5, and a database (DB) 14, which are a report status management DB 9, a report ID information DB 10, a report information DB 11, Consists of report countermeasure completion DB12.

  The message distribution processing unit 1, the mail transmission processing unit 6, and the countermeasure mail reception processing unit 8 including each processing unit constituting the report countermeasure management processing unit 13 include a CPU (Central Processing Unit) and a main storage device (main storage device). Memory), display device, input device, external storage device, processing function unit composed of a computer equipped with a peripheral device, etc., recorded on a storage medium such as a CD-ROM via an optical disk drive device as a peripheral device The program and data are installed in the external storage device, and then read from the external storage device into the main memory and processed by the CPU.

  The report countermeasure management processing unit 13 assigns a unique ID number to the event to be reported (failure to be notified) by the report ID acquisition processing unit 2, and the report information storage processing unit 3 reports and reports the event (failure) and notification Stores the destination information, stores the countermeasure result for the report event (failure) by the countermeasure result report registration processing section 4, and periodically sends a follow mail until the countermeasure is completed by the status check / follow mail transmission processing section 5. The report ID information DB 10 stores the report ID information, the report information DB 11 stores the report information (failure contents), the report countermeasure completion DB 12 stores the countermeasure content information, and the report status management DB 9 stores each fault (report Stores information on the degree of progress of countermeasure status against (event).

  With such a configuration, in the fault monitoring system of this example, for example, when the occurrence of a fault is detected in a network such as a telephone line, a LAN, or an intranet, the content of the detected fault is notified to a predetermined notification destination. The failure time notification time is acquired and registered in association with the failure content, and the action content executed for each registered failure content is acquired and registered in association with each failure content. For a failure that has not been treated, notification is periodically repeated to the notification destination, and the treatment content for each failure registered in this way is read and output to, for example, a display device or the like.

  That is, when the occurrence of a failure is detected in the notification distribution processing unit 1, the content of the failure (report information) is transmitted by the mail transmission processing unit 6 to a predetermined notification destination via the communication control unit 7, and a countermeasure against the notification is made. In the management processing unit 13, a unique ID number is assigned to the event (failure) to be reported by the report ID acquisition processing unit 2 described above, and the report event (failure) and notification destination by the report information storage processing unit 3 are assigned. Information storage, countermeasure result report registration processing unit 4 stores countermeasure results for reporting events (failures), and status check / follow email transmission processing unit 5 sends periodic follow emails until countermeasures are completed. . The countermeasure result for each notification event (failure) stored by the countermeasure result report registration processing unit 4 is displayed on a display device (not shown).

  Hereinafter, the process of assigning a unique ID number to the event (failure) to be reported by the report ID acquisition processing unit 2 using FIG. 2 and FIG. 6, and storing the report information using FIG. 3 and FIG. The storing process of the notification event (failure) and the notification destination information by the processing unit 3, the storing process of the countermeasure result for the reporting event (failure) by the countermeasure result report registration processing unit 4 using FIG. 4 and FIG. With reference to FIG. 5 and FIG. 7 to FIG. 9, periodic follow mail transmission processing until the countermeasure is completed by the status check / follow mail transmission processing unit 5 will be described.

  As shown in FIG. 2, the report ID acquisition processing unit 2 makes an ID acquisition request to the report ID information DB 10 when an event occurs (notification of the occurrence of a failure from the report distribution processing unit 1) (step 201). An unassigned ID is acquired from the notification ID information DB 10 (step 202).

  Then, the flag already assigned to the acquired ID and the current time are set in the notification ID information DB 10 (step 203).

  As shown in the report ID information DB 10a of FIG. 6, the report ID information DB 10 stores a table composed of an item number, an ID number, an allocation date and time, and an allocation column item. The item number includes a 6-digit 000001. The item number consisting of is registered continuously in ascending order, and the ID number is a number uniquely assigned for each reporting event (failure) (here, 10-digit alphanumeric characters). The date and time when the ID number was registered is registered, and a flag indicating whether the ID number has already been assigned and registered (0: not assigned, 1: assigned) is registered in the assignment.

  As shown in FIG. 3, the notification information storage processing unit 3 receives the ID number from the notification ID acquisition processing unit 2 (step 301), the ID number, the notification date and time of occurrence of a failure from the notification distribution processing unit 1, and the mail The mail transmission destination notified of the failure content by the transmission processing unit 6 and the notification content (failure content) are stored in the notification information DB 11 (step 302).

  As shown in the report information DB 11a of FIG. 7, the report information DB 11 stores a table composed of column items of ID number, report date and time, mail destination, and report contents. Similar to the ID number managed in the ID information DB 10a, a number (10-digit alphanumeric characters) uniquely assigned to each notification event (failure) is registered, and the date and time when the notification event occurred is registered in the notification date and time. In the mail transmission destination, the mail transmission destination for the notification event (the mail address transmitted by the mail transmission processing unit 6) is registered, and in the notification content, the mail content (failure content) transmitted by the mail transmission processing unit 6 is registered. Is registered.

  As shown in FIG. 4, the countermeasure result report registration processing unit 4 receives the countermeasure completion mail from the report destination (step 401), and checks (confirms) the status of the received mail (step 402). That is, the countermeasure completion status is confirmed from the title of the received mail. Here, “0” is the direct countermeasure for the event that has occurred, “1” is the impact investigation on the business system and the countermeasure is “1”, and future recurrence prevention measures to prevent the reoccurrence of the same reporting event (failure). Is “2”. Further, for each status, “0” is set for no countermeasure and “1” is set for the countermeasure.

  Thereafter, the countermeasure content for the notification status is confirmed (step 403), and the countermeasure completion status and the countermeasure content for the status confirmed in step 402 and step 403 are registered in the notification status management DB 9 (step 404).

  The failure manager of the report destination adds “: num” after the report ID of the subject when returning the countermeasure completion mail. This “num” is determined as the report status. Therefore, when a countermeasure mail is returned, any number of “0”, “1”, or “2” must be added after the report ID of the subject.

  As shown in the notification status management DB 9a of FIG. 8, the countermeasure result report registration processing unit 4 causes the notification status management DB 9 to store the ID number, countermeasure status 0, previous mail transmission date and time (0), countermeasure status 1, and previous mail transmission. A table including column items of date and time (1), countermeasure status 2 and previous mail transmission date and time (2) is stored, and the ID number is the same as the ID number managed in the report ID information DB 10a of FIG. A unique number (10-digit alphanumeric characters) assigned to each notification event (failure) is registered, and the countermeasure status 0 is “0” (not supported) or “1” (direct response status). : Countermeasured) is registered, and the previous mail transmission date and time (0) is registered with the previous transmission date and time of follow-up mail for direct countermeasures. “0” (: Not supported) or “1” (: Countermeasured) is registered as the status of the system impact investigation and countermeasures, and the last email transmission date and time (1) The previous transmission date and time of the follow mail is registered, and “0” (: Not supported) or “1” (: Countermeasured) is registered as the status of measures to prevent recurrence of the same report event (failure). In the previous mail transmission date and time (2), the previous transmission date and time of the follow mail for the recurrence prevention measures for the same report event (failure) is registered.

  FIG. 5 shows a processing procedure of the status check / follow mail transmission processing unit 5. The status check / follow mail transmission processing unit 5 is started with a timer every hour asynchronously with other processing units. .

  Then, the status check / follow-up email transmission processing unit 5 first searches the ID status management DB 9a shown in FIG. 8 for an ID number for which the countermeasure status is “0” and is not yet countermeasured, that is, without a completion flag ( If there is no ID with no completion flag (step 501), the process is terminated. If there is, the status number of the ID without the completion flag is determined (step 503).

  In the case of the status number “0”, using the ID number as a key, an e-mail address (e-mail destination) is acquired from the e-mail information DB 11a shown in FIG. 7 (step 504), and e-mail is sent to the e-mail recipient of the e-mail address. (Step 515).

  In the case of status number “1”, referring to the notification status management DB 9a of FIG. 8, the previous mail transmission date and time is acquired, the elapsed time is calculated (step 505), and the elapsed time exceeds 24 hours. It is determined whether or not there is (step 506). If it does not exceed, the process ends. If it exceeds, the mail address (mail transmission destination) is acquired from the report information DB 11a of FIG. 7 using the ID number as a key (step 507), and the report target of the mail address is obtained. A mail is transmitted to the person (step 508). Then, using the ID number as a key, the current time is set in the previous mail transmission date / time field in the notification status management DB 9a of FIG. 8 (step 509).

  In the case of the status number “2”, referring to the notification status management DB 9a shown in FIG. 8, the previous mail transmission date and time is acquired, the elapsed days are calculated (step 510), and the elapsed days exceed 7 days. It is determined whether or not (step 511). If it does not exceed, the process ends. If it exceeds, the mail address (mail transmission destination) is acquired from the report information DB 11a of FIG. 7 using the ID number as a key (step 512), and the report target of the mail address is obtained. A mail is transmitted to the person (step 513). Then, using the ID number as a key, the current date and time are set as the previous mail transmission date and time of the notification status management DB 9a of FIG. 8 (step 514).

  The status check / follow mail transmission processing unit 5 registers the contents of the countermeasure result mail sent from the notification destination in accordance with such follow processing as shown in the report countermeasure completion DB 12a of FIG.

  The report countermeasure completion DB 12a shown in FIG. 9 includes column items of ID number, status 0 countermeasure completion date, status 0 countermeasure content, status 1 countermeasure completion date, status 1 countermeasure content, status 2 countermeasure completion date, and status 2 countermeasure content. The ID number is registered with a number (10-digit alphanumeric characters) uniquely assigned to each notification event, similar to the ID number managed in the notification ID information DB 10a of FIG. The status 0 countermeasure completion date is registered with the date and time of completion of the direct countermeasure for the failure, the status 0 countermeasure content is registered with the content of the direct countermeasure against the failure, and the status 1 countermeasure completion date is The completion date and time of the investigation of the impact on the business system due to the failure and the countermeasure against it are registered. The contents of the investigation into the operational system and countermeasures against it are registered, and the completion date and time of the recurrence prevention countermeasure for the fault is registered on the status 2 countermeasure completion date, and the recurrence prevention countermeasure for the fault is registered in the status 2 countermeasure contents Is registered.

  As described above with reference to FIGS. 1 to 9, in the failure monitoring system of this example, when the occurrence of a failure is detected in the notification distribution processing unit 1, the failure content is transmitted to the communication control unit by the mail transmission processing unit 6. 7 is sent to a predetermined notification destination, and the notification information storage processing unit 3 associates the failure contents with the notification destination and stores them in the notification information DB 11, and the countermeasure result report registration processing unit 4 notifies them. The result of countermeasure against the failure is received and stored in the notification status management DB 9, and further, the status check / follow mail transmission processing unit 5 periodically transmits a follow mail until the countermeasure is completed. Then, the countermeasure result is output through a display device.

  This makes it possible to detect the problem of the prior art, that is, to detect and notify the occurrence of a failure, but not to confirm whether the failure information has reached the notification destination, and to deal with the notified failure.・ It is possible to solve the problem that it is not possible to monitor whether the countermeasure has actually been taken and how it has been implemented. It is possible to prevent the recurrence of the problem and to minimize the influence of the failure on the business system using the network.

  In this way, in this example, not only can the occurrence of a failure be detected and notified, but it can be confirmed whether the failure information has reached the notification destination, and the measures and countermeasures for the notified failure are actually implemented. It is possible to monitor whether and how it was executed, and it is possible to prevent the failure of notification of failure information and to respond reliably and promptly to the failure that occurred, It becomes possible to prevent the recurrence of the failure and to minimize the influence of the failure on the business system using the network.

  In addition, this invention is not limited to the example demonstrated using FIGS. 1-9, In the range which does not deviate from the summary, various changes are possible. For example, mail reception processing by the countermeasure result report registration processing unit 4 may be performed by the countermeasure mail reception processing unit 6.

  In this example, a failure in a network such as a telephone line, a LAN, or an intranet is targeted, but the present invention can also be applied to failure monitoring other than the network configuration.

  The computer configuration of the system of this example may be a computer configuration without a keyboard or optical disk drive. In this example, an optical disk is used as a recording medium. However, an FD (Flexible Disk) or the like may be used as a recording medium. As for the program installation, the program may be downloaded and installed via a network via a communication device.

It is a block diagram which shows the structural example of the failure monitoring system concerning this invention. It is a flowchart which shows the processing operation example of the report ID acquisition process part in FIG. It is a flowchart which shows the process operation example of the report information storage process part in FIG. It is a flowchart which shows the processing operation example of the countermeasure result report registration process part in FIG. It is a flowchart which shows the processing operation example of the status check and follow mail transmission process part in FIG. It is explanatory drawing which shows the example of registration content of report ID information DB in FIG. It is explanatory drawing which shows the example of registration content of report information DB in FIG. It is explanatory drawing which shows the example of registration content of report status management DB in FIG. It is explanatory drawing which shows the example of registration content of report countermeasure completion DB in FIG.

Explanation of symbols

  1: Report distribution processing unit 2: Report ID acquisition processing unit 3: Report information storage processing unit 4: Countermeasure result report registration processing unit 5: Status check / flow mail transmission processing unit 6: Mail transmission processing unit 7: Communication control unit, 8: Countermeasure mail reception processing unit, 9, 9a: Report status management DB, 10, 10a: Report ID information DB, 11, 11a: Report information DB, 12, 12a: Report countermeasure completion DB, 13 : Report countermeasure management processing unit, 14: Database (DB).

Claims (5)

A system for monitoring faults with a programmed computer,
A fault detection means for detecting the occurrence of a fault;
Notification means for notifying a predetermined notification destination of the content of the failure detected by the failure detection means;
Storage processing means for registering the failure content notified by the notification means in a storage device;
A result registration means for acquiring the action content executed for each failure content registered by the storage processing means and registering it in the storage device in association with each failure content;
A failure monitoring system comprising: a result output unit that reads out and outputs a treatment content for each failure registered in the storage device by the result registration unit. A system for monitoring faults occurring in network components by a programmed computer,
A fault detection means for detecting the occurrence of a fault;
Notification means for notifying a predetermined notification destination of the content of the failure detected by the failure detection means;
Storage processing means for registering the failure content notified by the notification means in a storage device;
A result registration means for acquiring the action content executed for each failure content registered by the storage processing means and registering it in the storage device in association with each failure content;
A failure monitoring system comprising: a result output unit that reads out and outputs a treatment content for each failure registered in the storage device by the result registration unit. The fault monitoring system according to claim 1 or 2,
The registered contents of the storage device by the result registering unit are searched at predetermined time intervals, and if there is an unmeasured failure for which a measure for the failure notified by the notifying unit is not registered, the notification destination A failure monitoring system comprising a follower for performing re-notification. The fault monitoring system according to claim 3,
As a measure for the above-mentioned failure, a first direct treatment for the notified failure, an investigation of the influence on the business system caused by the notified failure, a second process for the same, and a first prevention of the recurrence of the notified failure Including 3 treatments,
The failure monitoring system, wherein the following means searches for and notifies an unmeasured failure at each time determined individually for each of the first to third processes. (program)
The program for functioning a computer as each means in the failure monitoring system in any one of Claims 1-4.

Images