JPH1196043A - Center monitoring system for distributed system - Google Patents

Abstract

PROBLEM TO BE SOLVED: To enable an operator to easily grasp the state of a distributed system. SOLUTION: When a fault occurs in a certain distributed system, the occurrence of the fault is informed of by information accompanying the occurrence and the information is converted into a message by a center monitoring server (S204). A message stored in a message queue is extracted by an alert manager (S208) and stored in a message table for storing contents to be displayed (S210) and displayed on a monitoring console (S212). When the center monitoring server is informed of the restoration of the fault, the message is converted into an instruction for deleting the corresponding message (S204) and the converted message is stored in the message queue (S204). The alert manager extracting the deletion instruction from the message queue deletes the corresponding message (S210).

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a system for monitoring a center of a distributed system, and more particularly to a display of a fault message when monitoring the status of a large-scale distributed system at a center.

[0002]

2. Description of the Related Art Monitoring of the operating status of a distributed system, particularly information on a fault, in a center monitoring system has been conventionally performed. This monitoring is performed by the distributed systems, by notifying the center of the occurrence of each situation (every event) to the center and displaying the event as a message on the console at the center to the operator. On the other hand, it is possible to grasp the status of each distributed system.

[0003]

[Problems to be Solved by the Invention] By the way, in recent years, the tendency of distributed systems to increase in size has been increasing.
1000 distributed systems are becoming more common. In such a large-scale distributed system, the number of messages displayed on the console of the center monitoring system increases when monitoring is performed collectively at the center. It is becoming difficult for an operator to read a large number of messages displayed on the console and to grasp the status of the distributed system.

[0004] Further, when a message indicating that the fault has been recovered comes after a message has been displayed after the fault has occurred and the message for the fault has been displayed, it is necessary for the operator to delete the previous message indicating the occurrence of the fault. If the operator forgets to erase, the failure message will remain on the console forever,
This will confuse the operator's understanding of the situation.

An object of the present invention is to enable an operator to easily grasp the state of a distributed system in a center monitoring system of the distributed system.

[0006]

In order to achieve the above-mentioned object, the present invention provides a center monitoring system in a distributed system, which responds to a failure message or an automatic recovery information from each distributed system by using a failure message or Convert to a delete command, display the failure message on the monitoring console, and with the delete command by the recovery information,
It is characterized in that a corresponding failure message is deleted.

[0007] With this configuration, the automatically recovered fault message can be automatically deleted from the monitoring console.

Further, some of the fault messages generated based on the fault information are not displayed on the monitoring console, so that messages which are not necessary for the operation of the system may not be displayed.

The delete command can be configured to delete the corresponding fault message when the condition is satisfied, and there is no need for one-to-one correspondence between the recovery information and the fault information.

[0010] Messages corresponding to faults subject to automatic recovery and other messages can be displayed separately, so that the operator can easily grasp the status of the system.

A recording medium storing a program for causing a computer to generate the above functions is also within the scope of the present invention.

[0012]

Embodiments of the present invention will be described in detail with reference to the drawings.

FIG. 1 shows a configuration example of a distributed system to which the present invention is applied. The system 108 at each branch is
It is connected to a center monitoring server 102 at the center via a network. System 1 at each branch
08 transmits the event to the center monitoring server 102 via the network 106 as event information when a failure occurs. Upon receiving the event information, the center monitoring server 102 converts the event information into a message and displays the message on the center monitoring console 104.

The center monitoring server 10 for this fault information
2 will be described with reference to FIG. In FIG. 2, when a failure occurs in each system 108, the occurrence is notified by event information in accordance with the occurrence. The event information received by the center monitoring server 102 is converted into a message corresponding to the event information (S20
4) A message output request is issued and stored in the message queue (S206). The message stored in the message queue is retrieved and determined by the alert manager that controls the monitoring information on the center monitoring server (S208), and is put into a message table that stores the content to be displayed (S210). Then, a message is displayed on the monitoring console (S2
12).

Now, in the present invention, when the system automatically recovers from the failure, the corresponding message on the monitoring console is automatically deleted. In FIG. 2, the processing indicated by the dotted line indicates the processing of the event information for notifying the restoration of the failure.

When the center monitoring server 102 receives an event notifying the restoration of a failure, it is converted into an instruction to delete a corresponding message (S204) and stored in a message queue (S204). The alert manager that has taken out the deletion instruction from the message queue deletes the corresponding message from the message table (S210). This is reflected on the monitoring console (S212).

Referring to FIG. 3, the center monitoring server 10
In FIG. 2, a description will be given of a state where fault event information is displayed in a message in a distinguished manner. The center monitoring server 102 that has received the event information converts the received event information into a message using the message registration table 304. At this time, only “information that hinders operation” is stored in the message table as a display target.
“Information that does not affect operation” is simply a log
It is only stored in the file. This is information that does not need to be grasped by the operator because "information that does not affect the operation" is not displayed on the center monitoring console. As described above, since information that the operator does not need to grasp is not displayed on the console, the information displayed on the monitoring console is reduced, and the operator can easily grasp the status of the system.

[0018] The "information that hinders operation" can be further divided into "failures that can be automatically recovered by the system itself" and "failures that require manual response by an operator or the like".
It is put into the message table separately. On the monitoring console, "Automatic update screen" and "Error display screen" are displayed separately. The “failure that can be automatically recovered by the system itself” is information that the operator needs to know, but since the operator does not need to actively work, it is better to display it separately to understand the operator's system status. Can do better. Therefore, it is displayed on another screen (window). The display may be distinguished (such as changing color) on the same screen instead of another screen.

FIG. 4 illustrates the processing functions in the center monitoring server. Based on this, the processing in the center monitoring server will be described in detail.

When the center monitoring system 102 receives a failure event or a recovery event from a distributed system, an event receiving process 402 in the center monitoring system converts the received event into a message or a command using the message registration table 404. Convert. The event of the failure recovery is converted into a delete command. The converted message or command is stored in the message queue 40.
6 and the alert manager 40
8 is processed. At this time, “information that does not affect the operation” that does not need to be displayed is not passed to the message queue 406. It is stored in a log file (not shown).

The alert manager 408 receives a processing request from the event receiving process,
A message or the like is extracted from the queue 406 and stored in the message table 416. At this time, if the message is a message corresponding to a failure that can be automatically recovered, the part 4 corresponding to the automatic update of the message table 416
18 and any other failure message is stored in the error indication portion 420 of the message table.

The messages in message table 416 are displayed by dialog manager 414 on screen 42
6 is displayed. At this time, the message corresponding to the automatically recoverable failure and other messages are displayed separately. This display shows the monitoring system utility 42
4 can also be activated.

For a message having an urgency, a buzzer 432 is activated by a buzzer manager 430 via a message queue 428. The stop of the buzzer is performed by the operator on the dialog screen 426.

The operation of the alert manager 408 will be described in detail with reference to the flowchart of FIG. 5 and FIG. The alert manager 408 inputs a message or the like from the message queue 406 (S50).
2) and when the input is a message (S50)
4 and the message to be applied (automatic update message) (YES in S506), the message is stored in the automatic update message table 418 (S50).
8). If the message is any other message (N in S506)
O) is stored in the error display message table 420. Upon receiving the message write completion notification from the message table (S512), the screen manager 414 issues a screen update instruction to reflect the message table update on the screen 426.

As described above, the automatic update message and the other messages are distinguished and displayed on another screen (window), for example, so that the operator can concentrate on the trouble that the operator needs to work manually. it can.

When the alert manager 408 inputs a command (command in S504), the condition is determined using the determination table 410 (S518).
If the conditions are met (YES in S518), the corresponding message in the message table is deleted (S52).
2). This condition is, for example, a case where a certain failure message can be deleted only after all of a plurality of events are received. After deletion, upon completion of the update (S51
2) The display on the screen is changed (S514).

If the conditions do not match, the information to be deleted is temporarily stored, and the processing for this command ends. The control information table 422 is used as a storage location for this information.
May be.

As described above, the alert manager 40
8, the message for the failure for which the automatic recovery processing has been performed in each of the distributed systems can be automatically deleted from the display of the monitoring console 102. As described above, since the fault message is deleted from the monitoring console, the operator can easily grasp the system status.

The fault message displayed on the monitoring console is deleted by the center monitoring system at the end of one day. This is because all obstacles are basically resolved on the day they occur. Also, if you shut down the system and restart it,
Most obstacles are often resolved. This is also the reason for deleting the fault message after one day.

FIG. 6 shows an example of display on the monitoring console. In FIG. 6, the fault message includes a date 622, a time 624, a source system ID 626, a message type 628, a check 630 as to whether the operator has recognized the message, and a message content 632.
When the button 606 is clicked, the display is updated to the latest display. Button 608 is for the operator to stop the warning buzzer. Clicking button 610 prints the display screen. When the button 612 is clicked, a recognition display 630 of the selected message is displayed.
It can be performed. By clicking the button 614, the selected message can be deleted. By clicking the button 616, this screen (window) can be closed. When the column 602 of the automatic update suppression is checked, the next issue update is not performed. If the check box 604 for buzzer suppression is checked, the buzzer does not sound. This screen display is an example, and does not exclude other functions and display forms.

Further, the above-described portion of the program executing the function may be stored in a recording medium and read out by a computer system to be implemented. The recording medium includes a floppy disk, a CD-ROM, a magnetic tape, a ROM cassette, and the like.

[0032]

As described above, according to the present invention, in response to a failure report from a distributed system to a monitoring center, the number of failure messages displayed on the monitoring console of the monitoring center is reduced. However, it becomes easy to grasp the status of the system.

[Brief description of the drawings]

FIG. 1 is a block diagram illustrating a configuration example of a distributed system according to the present invention.

FIG. 2 is a schematic flowchart of processing in a center monitoring server.

FIG. 3 is a diagram illustrating a state in which a failure is displayed in a message while distinguishing the failure.

FIG. 4 is a functional block diagram of processing in a center monitoring server.

FIG. 5 is a flowchart showing processing of the alert manager.

FIG. 6 is a diagram showing an example of a display on a monitoring console.

[Explanation of symbols]

 102 center monitoring server 104 center monitoring console 106 network 108 branch server system

Claims (5)

[Claims] 1. A center monitoring system in a distributed system, wherein information on a failure or automatic recovery from each distributed system is converted into a failure message or a deletion command corresponding to the information, and the failure message is displayed on a monitoring console. A center monitoring system, wherein a corresponding failure message is deleted by the deletion command based on recovery information. 2. The center monitoring system according to claim 1, wherein the failure message generated based on the failure information includes:
A center monitoring system, wherein some of the information is not displayed on the monitoring console. 3. The center monitoring system according to claim 1, wherein the deletion command deletes a corresponding failure message when a condition is satisfied. 4. The center monitoring system according to claim 1, wherein a message corresponding to the failure to be automatically recovered and another message are displayed separately. 5. A recording medium storing a program for causing a computer to generate the function of the center monitoring system according to claim 1.