JP4183602B2 - Fault monitoring method and program - Google Patents

Description

  The present invention relates to a technique for fault monitoring.

  As a method of monitoring a failure of a device connected to the network, generally, a method of displaying a list of monitored devices on a screen, checking the status of each device in real time or periodically, and updating the monitoring screen is available. It is used. An apparatus in which a failure is detected may be displayed so that the user can specify it by changing the color on the screen or adding a predetermined mark.

  For example, when an operator who monitors the network confirms that a failure has occurred on the monitoring screen, the operator who reports the failure has reported to the network administrator, for example, and investigated the cause of the failure and requested a recovery. At that time, for example, the displayed monitoring screen is output to an image file using a commercially available program or the like. The output image file is also used as, for example, an attached material of a report when the network administrator reports the cause of the failure and the countermeasure taken to the supervisor or the like. Note that automatically saving the monitoring screen as an image file, for example, regularly is not usually performed because the amount of data becomes enormous. That is, the monitoring screen is overwritten one after another without being saved.

On the other hand, with regard to the contents displayed on the monitoring screen, for example, there is a technique for making it possible to easily identify a failure occurrence location (see, for example, Patent Document 1). That is, a failure monitoring system having a monitoring center that collects failure information of transmission devices in a transmission network in which a plurality of transmission devices are connected by a line, and the monitoring center generates a failure based on an estimated failure information pattern Collected from the transmission device, the suspicion determination table that determines the part that is considered to be a part, the part that is suspected as a faulty part and the part that is considered normal, a color display unit that displays the transmission network including the transmission device, and Based on the failure information pattern, refer to the suspicion determination table to determine the part that is considered to be the failure occurrence part, the part that is suspected as the failure occurrence part and the part that is considered normal, and that corresponds to the determination result And a control processing unit that displays each part of the transmission network and the line on the color display unit with different display colors.
JP-A-10-242967

  However, according to such a conventional technique, the following problems remain. First, when an operator or the like manually outputs a monitoring screen to an image file, it takes time for output and may forget to output it inadvertently. In addition, a new failure may be detected during the output operation, and the monitoring screen may be updated, resulting in a loss of output timing. In addition, for example, when a network administrator responds to an inquiry from an end user, it is necessary to refer to a monitoring screen that shows the situation (where and what problem occurred) at the time of the failure. If the screen has been updated, the past failure situation cannot be grasped.

  For example, the network administrator can directly refer to the failure data in order to confirm in detail the state of the network at the time when the failure occurred. It is more time-consuming and time-consuming to check each record including when and what kind of abnormality occurred and the actual network load at that time. .

  On the other hand, when a failure of a device connected to the network is monitored, another device located downstream cannot communicate with the monitoring device due to a failure of the device located upstream on the network when viewed from the monitoring device. May be considered an obstacle. In such a case, it is desirable to deal with a failure first with respect to a device located upstream. However, according to the technique described above, the relevance of such a failure is not clearly indicated. It is difficult for the network administrator to figure out where to take action. That is, there is a problem in that it is difficult to grasp a cluster or a group of failures caused by the same cause, and it takes time and effort to investigate the cause.

  Therefore, an object of the present invention is to provide a novel technique for enabling efficient management of failure monitoring screen data.

  Another object of the present invention is to provide a novel technique for immediately grasping the relationship between faults.

  The method according to the present invention is a method for monitoring a failure of a device connected to a predetermined network, including data relating to a device in which a failure is detected, a failure occurrence date and time, and a failure content corresponding to a monitoring item, and View data is generated by using the failure data stored in the failure data file storage unit and the view definition data including the data related to the screen display contents and stored in the view definition file storage unit. View data generation step to be stored in the storage unit, a view data generation step executed at a predetermined interval to update the view data, and screen components included in the view data before and after the view data update If a different value is indicated, screen history data is generated using data related to the change in the value of the screen component, And a screen history data generating step for storing the history file storage unit.

  In this way, only when there is a change in the screen display content (view data), such as when a new failure occurs, the update information (screen history data) is stored only for the display element that has changed. As a result, it is possible to save data relating to the screen with a small storage capacity compared to saving an image file.

  And a related device specifying step for specifying a device group in which a failure is detected for the same monitoring item or monitoring item group within a predetermined period using the screen history data stored in the screen history file storage unit. It may further include a related view data generation step of generating view data for showing to the user in a manner capable of specifying data relating to the failure of the device group, and storing the view data in the view data storage unit.

  As a result, users such as operators and network managers can grasp at a glance the device groups that are considered to have failed due to the same cause. It should be noted that the processing efficiency can be improved by using the screen history data having a smaller data amount than the failure data. In addition, a device group does not necessarily include a plurality of devices, and a device group may be configured by one device. Similarly, for the monitoring item group, the monitoring item group may be configured by one type of monitoring item.

  Further, the related view data generation step includes data relating to the execution of the failure handling, and based on the failure handling data stored in the failure handling file storage unit, among the device groups specified in the related device specifying step, Identifying a device group that has been dealt with as a root cause, and view data for presenting the user with data relating to the failure of the device group that has been identified as the root cause and has been dealt with in a manner that can be identified Generating and storing in the view data storage unit.

  A failure in the network is apparently caused by, for example, a network failure between a monitoring device and another device installed downstream due to a failure of a device installed upstream from the monitoring device. There are also obstacles. In such a case, by identifying the device group that actually handled the failure as root cause (the root cause of the failure), other device groups that are considered to have failed due to the same cause are apparently It is possible to indicate to the user that there is a high possibility of the failure.

  Further, the related view data generation step includes the data of the device group specified in the related device specifying step based on the configuration information including data related to the attributes of each device in the predetermined network and stored in the configuration information file storage unit. Among them, in a mode capable of specifying a device group including a device having the smallest number of hops as a route cause, and data relating to a failure of the device group identified as the route cause and including the device having the smallest number of hops. Generating view data for showing to the user and storing the view data in the view data storage unit.

  As described above, since there are apparent failures in the failure in the network, the device group including the device in which such a failure has occurred and the number of hops from the monitoring device is minimum is set as the root cause. By specifying, it is possible to indicate to the user that other device groups that are considered to have failed due to the same cause are likely to be apparently failed. Further, for example, the network administrator can deal with a trouble without waste by first dealing with the trouble for the device group identified as the root cause.

  It is also possible to create a program for causing a computer to execute the method according to the present invention, and the program is a storage medium such as a flexible disk, a CD-ROM, a magneto-optical disk, a semiconductor memory, and a hard disk. Alternatively, it is stored in a storage device. Moreover, it may be distributed as a digital signal via a network. Note that data being processed is temporarily stored in a storage device such as a computer memory.

  According to the present invention, it is possible to efficiently manage the failure monitoring screen data and immediately grasp the relevance of the failure, and perform appropriate failure monitoring.

  A system configuration diagram according to an embodiment of the present invention is shown in FIG. For example, the network 1 that is a corporate network includes one or more operation monitoring devices 5, one or more user terminals 3 that are personal computers, and a network device such as a router or a hub (HUB). The management device 7 and the managed device 13 are connected wirelessly or by wire. A managed device 9 and a managed device 11 are connected to the managed device 7. Although not shown, other managed devices may be connected to either the network 1 or the managed devices 7 to 13. Note that these managed devices are not necessarily independent devices, and may be network interfaces or the like.

  The operation monitoring apparatus 5 includes a monitoring definition file storage unit 501, a monitoring unit 503, a configuration information file storage unit 505, a collected data / file storage unit 507, a failure data / file storage unit 509, a failure handling unit 511, and a failure handling file storage. A unit 513, a latest operation monitoring view creation unit 515, a view definition file storage unit 517, a view data storage unit 519, a screen history file storage unit 521, and an operation monitoring view reproduction unit 523.

  The monitoring unit 503 executes monitoring processing of the managed devices 7 to 13 with reference to data stored in the monitoring definition file storage unit 501 and data stored in the configuration information file storage unit 505, and relates to processing results. Data is stored in the collected data file storage unit 507 and the failure data file storage unit 509. Details of the monitoring process will be described in the description of the processing flow. The failure handling unit 511 executes failure handling processing with reference to the data stored in the failure data / file storage unit 509 and the data stored in the view definition file storage unit 517, and handles the data related to the processing result as a failure handling. Store in the file storage unit 513. Details of the failure handling processing will be described in the description of the processing flow.

  The latest operation monitoring view creation unit 515 includes data stored in the failure data / file storage unit 509, data stored in the failure handling file storage unit 513, data stored in the view definition file storage unit 517, and view View data generation and update processing is executed with reference to data stored in the data storage unit 519 and data stored in the screen history file storage unit 521, and data related to the processing result is displayed in the view data storage unit 519 and the screen history file storage unit 521. Details of the view data generation and update processing will be described in the description of the processing flow.

  The operation monitoring view reproduction unit 523 includes data stored in the configuration information file storage unit 505, data stored in the failure handling file storage unit 513, data stored in the view data storage unit 519, and a view definition file. The monitor view display reproduction process is executed with reference to the data stored in the storage unit 517 and the data stored in the screen history file storage unit 521, and data relating to the processing result is stored in the view data storage unit 519. . Details of the monitoring view display reproduction processing will be described in the description of the processing flow.

  The monitoring definition file storage unit 501 stores data defining monitoring contents and conditions. Examples of the monitoring contents include a check on whether communication is possible and a check on the amount of communication data. The conditions include a threshold value used for checking the communication data amount, a monitoring interval, the number of retries in the communication availability confirmation, and the like. The collected data file storage unit 507 stores log data of monitoring processing. Other storage units will be described later with reference to the drawings.

  Although not shown, the operation monitoring device 5 has a web server function, and the user terminal 3 has a web browser function. That is, the user terminal 3 can access the operation monitoring device 5 via the network 1 and receive and display Web page data from the operation monitoring device 5. In some cases, a dedicated server program and client program are used, or the operation monitoring apparatus 5 is incorporated in the user terminal 3.

  FIG. 2 shows an example of the table configuration of the configuration information file storage unit 505 and stored data. 2 includes a node name column 200, an IP address column 202, a subnet address column 204, a hop count column 206, a community name (public) column 208, and a community name (private) column 210. include. The hop count column 206 stores the hop count from the operation monitoring apparatus 5 to each apparatus (node). The community name (public) column 208 and the community name (private) column 210 store character strings that function as passwords in monitoring processing using SNMP (Simple Network Management Protocol). As described above, the configuration information file storage unit 505 stores data related to the network configuration of the device to be monitored.

  FIG. 3 shows an example of the table configuration of the failure data file storage unit 509 and stored data. The example of FIG. 3 includes a date / time column 300, a managed device column 302, a monitoring item column 304, a type column 306, and a detail column 308. In the column of the monitoring item 304, an item indicating the monitoring content (communication data amount check or the like) set in the monitoring definition file storage unit 501 is stored. For example, “PolicyA” is a monitoring item name for checking whether communication is possible. A record is added to the failure data file storage unit 509 when a failure is detected by the monitoring process.

  FIG. 4 shows an example of data stored in the view definition file storage unit 517. The example of FIG. 4 includes an operation monitoring view name setting unit 400, an operation monitoring view update interval setting unit 402, a managed device group setting unit 404, and a monitoring item group setting unit 406. In the operation monitoring view update interval setting unit 402, an interval for regenerating (updating) view data for displaying a screen viewed by the user is set. In the example of FIG. 4, for example, the setting is made so that view data is regenerated every 60 seconds. Note that the refresh interval of the screen viewed by the user is not specified, and for example, the screen displayed on the Web browser is updated separately. In the managed device group setting unit 404, a device group name and a device name belonging to the device group are set. In the monitoring item group setting unit 406, the monitoring item group name and the monitoring item name in the monitoring item group are set. In the example of FIG. 4, for example, if “PolicyA” is a monitoring item name for checking whether communication is possible, the monitoring item in “PolicyGroup1” is checking whether communication is possible. One or more other monitoring items may be associated with “PolicyGroup1”. View data is generated according to such a definition.

  FIG. 5 shows an example of the table configuration of the failure handling file storage unit 513 and stored data. 5 includes a data update date / time column 550, a managed device group column 552, a monitoring item group column 554, a failure count column 556, a failure occurrence date / time column 558, and a failure handling date / time column 560. include. In the example of FIG. 5, data relating to the occurrence and handling of failures is stored for each managed device group and monitoring item group. A failure that has not yet been addressed may be registered. In that case, a value is registered in the failure handling date and time column 560 so that it is possible to determine that no value is registered or that no handling is performed.

  FIG. 6 shows an example of the table configuration of the screen history file storage unit 521 and stored data. In the example of FIG. 6, the data update date / time column 600, the front / rear column 602, the managed device group column 604, the monitoring item group column 606, the health status column 608, the number of failures column 610, and the failure occurrence date / time A column 612 and a column 614 for failure handling date and time are included. When the view data is changed, the screen history file storage unit 521 stores a pair of data before and after the update. In the front and rear columns 602, data representing either “before” or “after” indicating whether the record includes data before update or data after update is stored.

  The failure number column 610 stores the total number and breakdown of failures. The numerical value on the left side of the parentheses is the total number of cases, the numerical value on the left side in parentheses indicates the number of serious failures, and the numerical value on the right side in parentheses indicates the number of warning failures. For example, the data “10 (10/0)” on the second line in FIG. 6 indicates that the total number of failures is 10 and 10 (all) of them are important failures.

  The health status column 608 stores a code (for example, 0, 1 or 2) indicating the presence / absence and importance of a failure. For example, if the value in the column 610 of the number of failures is “10 (10/0)”, since there are 10 important failures, a code “1” indicating that an important failure has occurred is stored. In the example of FIG. 6, a column of the health state 608 is provided to make it easy to understand the state of the failure. However, as described above, the state of the failure can be determined by the value of the column 610 of the number of failures. For this reason, the health state 608 column may not be provided.

  FIG. 7 shows an example of data stored in the view data storage unit 519. The example of FIG. 7 includes an operation monitoring view name row 700, an operation monitoring view update date / time row 702, a data heading row 704, and actual data 706. In the example of FIG. 7, the row 704 of the data heading is separated by commas, and each row of the actual data 706 is also separated by commas corresponding to the headings. You may make it store in another format, such as separating with a blank. A failure monitoring screen based on such view data is displayed on the display device of the user terminal 3, for example. The view data is generated or updated to display the failure monitoring screen, and is not accumulated data. In the present embodiment, for example, at least two types of view data are held per view definition data. One is the latest view data, and the other is the current view data used for the current screen display. For example, when the user displays a failure situation at a specific point in the past on the screen, view data including the failure state at the specific point in the past is held as current view data. For example, when the user displays the latest failure status on the screen, the latest view data and the current view data are the same data. The operation monitoring view update date and time row 702 stores the date and time indicating when the view data is the data indicating the failure status.

  Next, processing contents of the system shown in FIG. 1 will be described with reference to FIGS. FIG. 8 shows a process flow of the monitoring process. Note that the processing entity of this monitoring process is the monitoring unit 503 of the operation monitoring apparatus 5, and the description of the processing entity is omitted in the following description.

  First, the monitoring definition data stored in the monitoring definition file storage unit 501 and the configuration information stored in the configuration information file storage unit 505 are read and temporarily stored in a storage device such as a work memory area (FIG. 8: step). S1). Then, based on the data read in step S1, a health check (confirmation of the presence or absence of a failure) is performed on the monitoring items defined for at least one of the managed devices 7 to 13 (step S3). When the health check is executed, collected data is generated as an execution log and stored in the collected data file storage unit 507 (step S5). The health check processing method may be a conventional method using a general communication protocol, and is not the gist of the present invention, so a detailed description is omitted here.

  Then, it is determined whether a failure has been detected by the health check (step S7). When it is determined that no failure has been detected (step S7: No route), the process proceeds to step S11 described later. On the other hand, if it is determined that a failure has been detected (step S7: Yes route), failure data is generated and stored in the failure data file storage unit 509 (step S9). Then, based on the monitoring interval included in the monitoring definition data read in step S1, it is determined whether the monitoring time has come (step S11). When it is determined that the monitoring time is not reached (step S11: No route), the process of step S11 is repeated at a predetermined interval until the monitoring time is reached. On the other hand, if it is determined that the monitoring time has come (step S11: Yes route), the process returns to step S3 and the health check is performed again.

  In this way, the monitoring process is performed. As a result of the monitoring process, failure data is accumulated in the failure data / file storage unit 509.

  FIG. 9 shows a processing flow of view data generation and update processing. Note that the processing subject of the view data generation and update processing is the latest operation monitoring view creation unit 515 of the operation monitoring device 5, and description of the processing subject is omitted in the following description. First, the view definition data stored in the view definition file storage unit 517 is read and temporarily stored in a storage device such as a work memory area (FIG. 9: Step S21).

  Then, based on the value of the operation monitoring view update interval setting unit 402 (FIG. 4) included in the view definition data, it is determined whether the update time has come (step S23). When new (first time) view data is generated, this determination may be skipped and the process may proceed to step S25. When it is determined that the update time is not reached (step S23: No route), the process of step S23 is repeated at a predetermined interval until the update time is reached. On the other hand, when it is determined that the update time is reached (step S23: Yes route), the failure data from the previous view data update time to the current time is read from the failure data file storage unit 509, and the work memory area and the like are read. Store in the storage device (step S25). The previous view data update time is included in the row 702 (FIG. 7) of the operation monitoring view update date and time of the latest view data stored in the view data storage unit 519. When newly generating view data, all fault data up to the current time is read. If there is no corresponding failure data, except when newly generating view data, the process returns to step S25. Further, one item is identified from the read failure data (step S27).

  Then, the failure handling file storage unit 513 is searched, and the failure handling data corresponding to the failure data identified in step S27 is confirmed (step S29). Since the failure data is registered for each managed device and monitoring item, the corresponding managed device group and monitoring item group are specified based on the view definition data. Then, the failure handling data corresponding to the failure data is specified based on the managed device group, the monitoring item group, and the failure occurrence date and time. The failure occurrence date / time may be within a predetermined range (for example, 1 minute) even if the failure occurrence date / time does not completely match. The column 560 (value in FIG. 5) of FIG.

  Then, based on the presence / absence of corresponding failure handling data or the value in the column 560 (FIG. 5) of the failure handling date / time, it is determined whether the failure has been handled (step S31). When it is determined that it has been dealt with (step S31: Yes route), the processing proceeds to step S35 described later. On the other hand, if it is determined that the countermeasure has not been taken (step S31: No route), the number of faults is added (incremented by 1) for each managed device group and monitoring item group, and stored in a storage device such as a work memory area. (Step S33).

  Then, it is determined whether the failure data identified in step S27 is the last data among the failure data read in step S25 (step S35). When it is determined that it is not the last data (step S35: No route), the process returns to the process of step S27, and one piece of next failure data is specified. On the other hand, when it is determined that the data is the last data (step S35: Yes route), for example, the previous view data (before update) is read from the view data storage unit 519 and added in the previous view data and step S33. Based on the number of failures, it is determined whether there is a display element (a set of a managed device group and a monitoring item group) having a different value between the previous view data and the current view data (step S37). For example, when the number of failures for a managed device group and a monitoring item group increases compared to the previous time, it is determined that there are display elements having different values. When new view data is generated, it is determined that the values are different for all display elements.

  When it is determined that there is no display element having a different value (step S37: No route), the process returns to step S23. On the other hand, if it is determined that there is a display element with a different value (step S37: Yes route), screen history data is generated based on the values before and after the update of the display element, and stored in the screen history file storage unit 521 (step S37). S39). As shown in FIG. 6, two records are generated for one display element. Then, new view data is generated or updated based on the view definition data read in step S21 and the value of the new display element, and stored in the view data storage unit 519 (step S41). After the new generation or update of view data, the process returns to step S23.

  In this way, the latest view data is generated or updated based on the view definition data and the failure data. Further, when the view data is updated, screen history data is generated. When the view data generation and update processing is once ended and then resumed, the latest view data and view definition file stored in the view data storage unit 519 are stored in the processing of step S21. The view definition data stored in the part 517 is read. Note that the latest view data does not reflect a failure or the like that occurs between the end of the view data generation and update processing and the restart, and therefore, for example, step S23 is skipped, and in step S25, Failure data from the update time of the latest view data to the current time is read from the failure data file storage unit 509 and stored in a storage device such as a work memory area. Then, the latest view data can be generated by executing the processing after step S27.

  If the latest view data is not retained because the view data generation and update processing has been temporarily ended, the view data is stored in the view definition file storage unit 517 in the process of step S21. View definition data and the screen history data stored in the screen history file storage unit 521, and using the read view definition data and the screen history data, Data may be generated and stored in the view / data storage unit 519. As a result, the amount of data to be handled can be reduced and view data can be generated efficiently compared to the case where view data is generated using all fault data up to now.

  Specifically, first, all screen history data is read and stored in a work memory area or the like. Of the screen history data, the data with the oldest generation date / time contains all the contents of the view data generated for the first time (the values of all display elements are different from those before the update (generation)). Based on the history data and the view definition data, the view data when it is generated for the first time is generated (reproduced). Then, based on the view data, the view data is updated by the screen history data by applying the screen history data in the order of generation date and time. When all the screen history data is updated, the view data at the time when the view data generation and update processing is once completed is generated (reproduced). Note that the view data generated here does not reflect a failure or the like that occurs between the end of the view data generation and update processing and the restart, and therefore, for example, step S23 is skipped, In S25, failure data from the generation time of the latest screen history data (applied last in the above process) to the current time is read from the failure data file storage unit 509 and stored in a storage device such as a work memory area. . Then, the latest view data can be generated by executing the processing after step S27.

  Next, the monitoring view display reproduction process will be described with reference to FIGS. Note that the communication between the user terminal 3 and the operation monitoring apparatus 5 in the following description is assumed to be realized by the Web browser function of the user terminal 3 and the Web server function of the operation monitoring apparatus 5, but a dedicated server・ Programs and client programs may be used.

  First, the user terminal 3 receives a display instruction of the latest view from a user such as an operator or a network administrator via, for example, a Web browser screen (FIG. 10: Step S51). The user terminal 3 that has received the display instruction of the latest view transmits a request for the latest view page data to the operation monitoring apparatus 5 (step S53). It is assumed that login processing and the like are performed in advance, and the user terminal 3 is in a state where it can access the operation monitoring apparatus 5. For example, the operation monitoring view reproduction unit 523 of the operation monitoring apparatus 5 having a Web server function receives a request for the latest view page data from the user terminal 3 (step S55). Then, the operation monitoring view reproduction unit 523 reads the latest view data from the view data storage unit 519, generates the latest view page data based on the read view data, and transmits the data to the user terminal 3 (step). S57). The Web browser of the user terminal 3 receives the latest view page data from the operation monitoring device 5 and displays it on the display device (step S59).

  FIG. 11 shows an example of the latest view page. In the example of FIG. 11, a view name display unit 1100, a last update date / time display unit 1110, a monitoring data list display unit 1120, a previous screen button 1140, a next screen button 1150, a date / time designation display button 1160, a related failure display button 1170, and a save. A button 1180 and an end button 1190 are included. The monitoring data list display unit 1120 includes a managed device group column 1122, a monitoring item group 1 column 1124, a monitoring item group 2 column 1126, and a monitoring item group 3 column 1128. Note that the number of monitoring item groups is not limited to three, and may be more or less than this.

  Further, the managed device group column 1122 shows groups A to C which are names of managed device groups. Similar to the monitoring item group, the number of managed device groups is not limited to three, and may be more or less than this. The monitoring data list display unit 1120 displays failure-related data in tabular form for each monitoring item group and managed device group.

  The example of FIG. 11 is an example of a page generated based on the view data shown in FIG. For example, the contents of the first row of the actual data 706 (FIG. 7) are shown in the column of the first row (row of managed device group A) in the column 1124 of the monitoring item group 1. The display of “10 (10/0)” indicates that the total number of failures is 10, and 10 of them (all) are important failures. The display “2003/07/11 11:03” indicates the latest failure occurrence date and time, and the display “2003/07/11 11:00” indicates the latest failure handling date and time. It should be noted that the latest failure occurrence date and time is newer than the latest failure handling date and time, which indicates that a new failure has not yet been dealt with. A column including such data is highlighted (in this case, a vertical stripe line is added) so that the user can recognize at a glance. In addition, the highlighted field can be selected and clicked, and when clicked by the user, the process proceeds to failure handling processing described later. In the example of FIG. 11, there are three columns that are highlighted.

  The latest view page data includes a code for the Web browser to periodically refresh the screen and a predetermined update interval. Each button provided at the bottom of the latest view page will be described later in the description of the processing flow. Returning to the description of FIG. 10, the Web browser of the user terminal 3 determines whether it is time to update the latest view page (FIG. 10: step S61). If it is determined that the update time has come (step S61: Yes route), the processing returns to step S53, and the request for the latest view page data is transmitted to the operation monitoring apparatus 5 again. On the other hand, when it is determined that the update time is not reached (step S61: No route), the Web browser of the user terminal 3 accepts a selection input from the user for the latest view page (FIG. 11), and selects the selection input data. It transmits to the operation monitoring apparatus 5 (step S63). The operation monitoring view reproduction unit 523 of the operation monitoring device 5 receives the selected input data from the user terminal 3 and temporarily stores it in a storage device such as a work memory area (step S65).

  Then, the operation monitoring view reproduction unit 523 of the operation monitoring apparatus 5 determines whether the user's selection input is “end” (step S67). If the end button 1190 is clicked on the latest view page (FIG. 11), the user's selection input is “end”. When it is determined that it is “end” (step S67: Yes route), the operation monitoring view reproduction unit 523 performs an end process (step S69). For example, end page data is generated and transmitted to the user terminal 3. On the other hand, when it is determined that it is not “end” (step S67: No route), the operation monitoring view reproduction unit 523 determines whether the user's selection input is “fault handling” (step S71).

  As described above, if the column with vertical stripes is clicked in the latest view page (FIG. 11), the user's selection input is “fault handling”. When it is determined that the problem is “fault handling” (step S71: Yes route), the fault handling unit 511 of the operation monitoring apparatus 5 performs a fault handling process (step S73). Details of the failure handling processing will be described later. On the other hand, when it is determined that it is not “fault handling” (step S71: No route), the operation monitoring view reproduction unit 523 determines whether the user's selection input is “screen save” (step S75).

  If the save button 1180 is clicked on the latest view page (FIG. 11), the user's selection input is “screen save”. When it is determined that it is “screen saving” (step S75: Yes route), the operation monitoring view reproduction unit 523 performs a screen data saving process (step S77). For example, page data for downloading HTML data or the like of the page currently displayed on the user terminal 3 is transmitted to the user terminal 3. On the other hand, when it is determined that it is not “screen saving” (step S75: No route), the processing shifts to the processing in FIG.

  FIG. 12 shows an example of the screen data download page. FIG. 12 includes a storage destination designation field 1200, a reference button 1210, an OK button 1220, and a cancel button 1230. The user can download the screen data (HTML data) by inputting the directory for storing the screen data in the storage destination designation field 1200 or designating it using the reference button 1210 and clicking the OK button 1220. When the cancel button 1230 is clicked, the original page is displayed. Note that the user terminal 3 may perform the screen saving process independently, such as when a dedicated server program and client program are used, or when the screen saving function of the Web browser is used.

  FIG. 13 shows a process transferred through terminals A and B. The operation monitoring view reproduction unit 523 of the operation monitoring device 5 determines whether the user's selection input is “date designation” (FIG. 13: step S81). If the date and time designation display button 1160 is clicked on the latest view page (FIG. 11), the user's selection input is “date and time designation”. If it is determined that it is not “date and time designation” (step S81: No route), the process proceeds to the process of FIG. On the other hand, when it is determined that it is “date and time designation” (step S81: Yes route), the operation monitoring view reproduction unit 523 generates date and time designation page data and transmits it to the user terminal 3 (step S83). The Web browser of the user terminal 3 receives the date / time designation page data from the operation monitoring device 5 and displays it on the display device (step S85).

  FIG. 14 shows an example of the date / time designation page. The example of FIG. 14 includes a date and time input unit 1400, an OK button 1410, and a cancel button 1420. The user can instruct viewing of the view page at the input date and time by inputting the date and time in the date and time input unit 1400 and clicking the OK button 1410. When the cancel button 1430 is clicked, the original page is displayed.

  Returning to the description of FIG. 13, the Web browser of the user terminal 3 accepts input of date / time data from the user to the date / time specification page (FIG. 14), and transmits the input date / time (specified date / time) data to the operation monitoring apparatus 5. (Step S87). The operation monitoring view reproduction unit 523 of the operation monitoring device 5 receives the specified date / time data from the user terminal 3 and temporarily stores it in a storage device such as a work memory area (step S89). At this time, the operation monitoring view reproduction unit 523 corresponds to the view data (current view data) constituting the view page data currently displayed on the Web browser of the user terminal 3 and the view data. Date / time (current view date / time) data is specified and stored in a storage device such as a work memory area. The current view date and time is a date and time indicating when the current view data is the data for displaying the state, and the row 702 of the operation monitoring view update date and time of the current view data (FIG. 7). Is the value of

  Then, the operation monitoring view reproduction unit 523 compares the specified date with the current view date (step S91). Then, the operation monitoring view reproduction unit 523 determines whether the specified date / time is in the past than the current view date / time (step S93). When it is determined that the specified date / time is earlier than the current view date / time (step S <b> 93: Yes route), the operation monitoring view reproduction unit 523 determines from the screen history data stored in the screen history file storage unit 521. Screen history data including pre-update data of the current view data is specified (step S95). Here, the specified screen history data is data in which the value in the data update date / time column 600 (FIG. 6) is equal to the current view date / time and the value in the preceding / next column 602 (FIG. 6) is “Previous”. is there. If there is no corresponding data, the process proceeds to step S111 described later.

  Then, the operation monitoring view reproduction unit 523 updates the view data based on the specified screen history data (step S97). That is, the view data is returned to the previous (past) state. Here, in the current view date and time, the update date and time of the screen history data including the update date and time immediately before the screen history data specified in step S95 (value in the data update date and time column 600 (FIG. 6)) is set. .

  Then, the operation monitoring view reproduction unit 523 compares the updated current view date and time with the designated date and time (step S99). Then, the operation monitoring view reproduction unit 523 determines whether the specified date / time is in the past than the current view date / time (step S101). When it is determined that the specified date / time is earlier than the current view date / time (step S101: Yes route), the process returns to step S95. On the other hand, if it is determined that the current view date is earlier than the specified date (step S101: No route), the process proceeds to step S111 described later.

  On the other hand, if it is determined in step S93 that the current view date / time is earlier than the specified date / time (No route), the operation monitoring view reproduction unit 523 is stored in the screen history file storage unit 521. The screen history data including the updated data of the current view data is specified from the screen history data being displayed (step S103). Here, the screen history data to be identified is that the value in the data update date / time column 600 (FIG. 6) is the next date / time after the current view date / time, and the value in the preceding / next column 602 (FIG. 6) is “after”. This is the data. If there is no corresponding data, the process proceeds to step S111 described later.

  Then, the operation monitoring view reproduction unit 523 compares the update date / time of the specified screen history data (the value of the data update date / time column 600 (FIG. 6)) with the specified date / time (step S105). Then, the operation monitoring view reproduction unit 523 determines whether the specified date is earlier than the update date of the specified screen history data (Step S107). When it is determined that the update date / time of the specified screen history data is earlier than the specified date / time (step S107: No route), the view data is updated based on the specified screen history data (step S109). . That is, the view data is advanced to the next (future) state. Here, in the current view date and time, the update date and time of the screen history data specified in step S103 (value in the data update date and time column 600 (FIG. 6)) is set. Then, the process returns to step S103.

  On the other hand, when it is determined that the specified date / time is earlier than the update date / time of the specified screen history data (step S107: Yes route), view page data is generated based on the current view data, It transmits to the user terminal 3 (step S111). At this time, the current view data stored in the view data storage unit 519 is updated to the current view data. The Web browser of the user terminal 3 receives the view page data from the operation monitoring device 5 and displays it on the display device (step S113). And a process returns to the process of step S63 (FIG. 10) via the terminal D. FIG.

  In this way, view page data for a specific date and time is generated by updating the view data one by one in the past or future direction using the screen history data. Note that the view page data to be finally generated is generated based on the screen history data including the update date and time that is earlier than the specified date and time and is closest to the specified date and time.

  FIG. 15 shows the processing that has been transferred via the terminal C. The operation monitoring view reproduction unit 523 of the operation monitoring device 5 determines whether the user's selection input is “previous screen” (FIG. 15: step S121). If the previous screen button 1140 is clicked on the latest view page (FIG. 11), the user's selection input is “previous screen”. If it is determined that the previous screen is displayed (step S121: Yes route), the operation monitoring view reproduction unit 523 updates the current view data from the screen history data stored in the screen history file storage unit 521. Screen history data including the previous data is specified (step S123). Here, the specified screen history data is data in which the value in the data update date / time column 600 (FIG. 6) is equal to the current view date / time and the value in the preceding / next column 602 (FIG. 6) is “Previous”. is there. Then, the process proceeds to step S129 described later. If there is no corresponding data in the process of step S123, the process proceeds to the process of step S131 described later.

  On the other hand, when it is determined that it is not the “previous screen” (step S121: No route), the operation monitoring view reproduction unit 523 determines whether the user's selection input is the “next screen” (step S125). If the next screen button 1150 is clicked on the latest view page (FIG. 11), the user's selection input is “next screen”. If it is determined that the screen is not the “next screen” (step S125: No route), the process proceeds to the process of FIG. On the other hand, when it is determined that it is the “next screen” (step S125: Yes route), the operation monitoring view reproduction unit 523 obtains the current view data from the screen history data stored in the screen history file storage unit 521. The screen history data including the updated data is specified (step S127). Here, the screen history data to be identified is that the value in the data update date / time column 600 (FIG. 6) is the next date / time after the current view date / time, and the value in the preceding / next column 602 (FIG. 6) is “after”. This is the data. If there is no corresponding data, the process proceeds to step S131 described later.

  Then, the operation monitoring view reproduction unit 523 updates the view data based on the specified screen history data (step S129). That is, the view data is returned to the previous (past) state or the view data is advanced to the next (future) state. When the view data is returned to the previous state, the screen including the update date and time immediately before the screen history data specified in step S123 (the value in the data update date and time column 600 (FIG. 6)). Set the update date / time of history data to the current view date / time. When the view data is advanced to the next state, the update date / time of the screen history data specified in step S127 (the value in the data update date / time column 600 (FIG. 6)) is set as the current view date / time. . Further, the operation monitoring view reproduction unit 523 generates view page data based on the current view data, and transmits the view page data to the user terminal 3 (step S131). The Web browser of the user terminal 3 receives the view page data from the operation monitoring device 5 and displays it on the display device (step S133). And a process returns to the process of step S63 (FIG. 10) via the terminal D. FIG.

  In this way, view page data corresponding to the previous screen or the next screen is generated by updating the view data in one step in the past or future direction using the screen history data.

  FIG. 16 shows a schematic diagram of view data update (screen transition) in the processing described with reference to FIGS. FIG. 16 includes a screen element transition 1600, a view data transition 1610, a screen history data transition 1620, and a display view transition 1630.

  First, the screen element transition 1600 shows how the screen element (the value of the screen display element) changes due to detection of a failure or the like when time passes from the left to the right in the figure. In the example of FIG. 16, for example, A, B, C, and D are listed as screen elements. The status of each screen element when the monitoring process is performed is shown in the columns of monitoring 1 to 7. In the column of the monitor 1, A1, B1, C1, and D1 are shown, and this represents, for example, an initial state of each screen element. Moreover, the difference of the numerical value attached | subjected to the right of the alphabet showing a screen element has shown that a state differs. For example, in the column of monitor 2, the state of the screen element A is indicated as A2, and the state is different from the column of monitor 1 that was A1. That is, it is shown that the screen element A has changed between the first monitoring time and the second monitoring time.

  The view data transition 1610 shows how the view data is updated at a predetermined update interval. In the example of FIG. 16, a screen element whose state is different (changed) from the previous time is underlined, and no data is saved (updated) when there is no screen element whose state is different from the previous time. For example, at the time of date 1 when the first update is made, view data is newly generated, and therefore all screen elements are underlined. At the time of date 2, the state of the screen element included in the view data at the time of date 1 is compared with the state of the screen element at the time of monitoring 2, and the screen element A changes from A 1 to A 2. Therefore, the view data is updated. Similarly, the view data is repeatedly updated, and the view data at date 5 is the latest view data.

  The screen history data transition 1620 shows a state in which, before the view data is updated, the value before updating and the value after updating for the screen element whose state has changed are stored as screen history data. The characters “before” and “after” represent before and after updating, respectively. In addition, the numerical values attached to the right of the characters “before” and “after” indicate the date and time when the screen history data was generated, and correspond to the numerical values attached to the right of the date and time of the view data. is doing. First, the first (leftmost) data corresponds to the new generation of view data (date 1), and no view data existed before the update. The data to be included is not included. Further, all screen elements are included as data corresponding to “after 1”. The second data (second from the left) records that the state of the screen element A has been updated from A1 to A2 in the date / time 2 view data update. Similarly, for the third to fifth data, values before and after the update are recorded for the screen elements that have changed.

  In the display view transition 1630, for example, the view data (current view data) constituting the screen currently displayed on the user terminal 3 is updated, and the screen transition is shown. For example, the latest view data, which is the current current view data, includes screen elements A2, B2, C3, and D3 and their states, as shown on the right side of the display view transition 1630. Also, the view update date and time (the value of the operation monitoring view update date and time row 702 (FIG. 7)) included in the current view data is date and time 5. Here, for example, if a “previous screen” instruction is received from the user, first, data corresponding to “previous 5” of the screen history data (screen history data of “previous” at the same date and time 5 as the view update date and time) Is identified. In the example of FIG. 16, they are C2 and D2. Therefore, the state of the screen element C is updated to C2, and the state of the screen element D is updated to D2. At this time, it is not necessary to consider that the original was C3 and D3. As a result of the update, the current view data becomes A2, B2, C2, and D2. In addition, when transitioning to the previous (past) state, since the update date and time immediately before the specified screen history data (previous 5) is set as the view update date, the view update date is the date and time 5 To date 4

  Also, for example, when the current view data is A2, B1, C1, and D1 and the view update date and time is date 2 (the state shown second from the left of the display view transition 1630), the user indicates If the “screen” instruction is received, first, data corresponding to “after 3” of the screen history data (screen history data “after” at the date and time after the date and time 2 that is the view update date and time) is specified. In the example of FIG. 16, they are B2 and C2. Therefore, the state of the screen element B is updated to B2, and the state of the screen element C is updated to C2. At this time, it is not necessary to consider that the original was B1 and C1. As a result of the update, the current view data becomes A2, B2, C2, and D1. In addition, when transitioning to the next (future) state, since the update date / time of the specified screen history data (after 3) is set as the view update date, the view update date is changed from date / time 2 to date / time 3. Updated.

  In this way, the current view data is updated. When the date and time is designated by the user, the target view data is generated by repeating one of the above processes (returning to the past or proceeding to the future) one or more times. Thereby, the user can display on the screen the failure status at the date and time he / she wants to see.

  FIG. 17 shows the processing that has been transferred via the terminal E. The operation monitoring view reproduction unit 523 of the operation monitoring device 5 generates related failure designation page data and transmits it to the user terminal 3 (step S141 in FIG. 17). The Web browser of the user terminal 3 receives the related failure designation page data from the operation monitoring device 5 and displays it on the display device (step S143).

  FIG. 18 shows an example of the related failure designation page. The example of FIG. 18 includes a monitoring item group selection unit 1800, a route cause detection designation unit 1810, an OK button 1820, and a cancel button 1830. The monitoring item group selection unit 1800 allows the user to select a monitoring item group for which a related failure is to be displayed. In the example of FIG. 18, the monitoring item group 1 is selected. The route / cause detection designation unit 1810 can designate whether or not to detect route / cause. In the example of FIG. 18, it is designated to perform (to detect root cause). The user clicks an OK button 1820 to instruct related fault display according to the conditions specified by the monitoring item group selection unit 1800 and the route / cause detection / designation unit 1810. When a cancel button 1820 is clicked, the original page is displayed.

  Returning to the description of FIG. 17, the Web browser of the user terminal 3 accepts a selection input from the user for the related failure designation page (FIG. 18), and transmits the selection input data to the operation monitoring apparatus 5 (FIG. 17: Step S145). . The operation monitoring view reproduction unit 523 of the operation monitoring device 5 receives the selected input data from the user terminal 3 and temporarily stores it in a storage device such as a work memory area (step S147). Then, the operation monitoring view reproduction unit 523 specifies screen history data generated within a predetermined interval from the date and time of the current view data (current view date and time) from the screen history file storage unit 521, and uses the screen history data as the screen history data. Based on this, a managed device group having a failure in the designated monitoring item group is extracted (step S149).

  Further, the operation monitoring view reproduction unit 523 determines whether or not route / cause detection is designated based on the selection input data received in step S147 (step S151). If it is determined that route / cause detection is not designated (step S151: No route), the process proceeds to step S161 described later. On the other hand, if it is determined that route / cause detection has been specified (step S151: Yes route), the failure handling data corresponding to the screen history data identified in step S149 is retrieved from the failure handling file storage unit 513. (Step S153). The search conditions are a managed device group, a monitoring item group, and a failure occurrence date and time. This excludes data for which failure handling has not yet been performed.

  Then, the operation monitoring view reproduction unit 523 determines whether there is corresponding failure handling data (step S155). When it is determined that the corresponding failure handling data exists (step S155: Yes route), the operation monitoring view reproduction unit 523 specifies a managed device group included in the searched failure handling data (step S157). And it transfers to the process of step S161 mentioned later. On the other hand, when it is determined that the corresponding failure handling data does not exist (step S155: No route), the operation monitoring view reproduction unit 523 stores the managed device group and configuration information file storage unit 505 extracted in step S149. Based on the stored configuration information and the view definition data stored in the view definition file storage unit 517, the number of hops (the value in the hop number column 206 (see FIG. 2) Specify a managed device group including devices with a small number (step S159).

  Then, the operation monitoring view reproduction unit 523 updates (highlights, etc.) the view page data based on the managed device group specified in step S149 and in step S157 or step S159, and transmits it to the user terminal 3. (Step S161). The Web browser of the user terminal 3 receives the updated view page (related failure display view page) data from the operation monitoring device 5 and displays it on the display device (step S163). And a process returns to the process of step S63 (FIG. 10) via the terminal D. FIG.

  FIG. 19 shows an example of the related failure display view page. The example of FIG. 19 includes a monitoring data list display unit 1900. The monitoring data list display unit 1900 includes a monitoring item group 1 column 1910. The screen configuration is the same as that of the latest view page shown in FIG. The first column (row of managed device group A) in column 1910 of monitoring item group 1 is highlighted (addition of a lattice pattern), and the managed device group A is root cause. Is shown. In addition, the third column (row of managed device group C) in the column 1910 of the monitoring item group 1 is also highlighted (added with a vertical line pattern), which is related to the failure of the managed device group A. It is shown that a certain failure also occurred in the managed device group C.

  In this way, the related failure and route cause display processing is performed. In the process of step S149 (FIG. 17), the managed device group is identified based on the managed device in which a failure is detected for the same monitored item among the monitored items included in the designated monitored item group. It may be. In this case, processing is performed with reference to not only the screen history data but also the failure data stored in the failure data / file storage unit 509 and the view definition data stored in the view / definition file storage unit 517.

  Next, the failure handling process (FIG. 10: step S73) will be described with reference to FIGS. First, the failure handling unit 511 of the operation monitoring device 5 reads the failure data corresponding to the location designated by the user (the column clicked on the latest view page (FIG. 11)) from the failure data file storage unit 509, The data is temporarily stored in a storage device such as a work memory area (FIG. 20: Step S171). Since the monitoring data list display unit 1120 of the latest view page (FIG. 11) shows data for each managed device group and monitored item group, it is included in the managed device group based on the view definition data. The monitoring items included in the device and monitoring item group to be monitored are identified. Then, the failure data is identified and read based on the managed device, the monitoring item, and the failure occurrence date and time.

  Then, the operation monitoring view reproduction unit 523 generates failure handling page data based on the read failure data and transmits it to the user terminal 3 (step S173). The Web browser of the user terminal 3 receives the failure handling page data from the operation monitoring device 5 and displays it on the display device (step S175).

  FIG. 21 shows an example of the failure handling page. The example of FIG. 21 includes a failure data display column 2100, a check box unit 2110, an OK button 2120, and a cancel button 2130. Each check box included in the check box unit 2100 corresponds to each line included in the failure data display column 2100, and the user can select a check box in a row indicating a handled failure. By checking the box and clicking the OK button 2120, an instruction to register that the countermeasure has been taken is issued. When a cancel button 2130 is clicked, the original page is displayed. In the example of FIG. 21, five lines of failure data are shown, but the number of display lines may be any number. For example, a scroll bar or a button for screen transition may be provided.

  Returning to the description of FIG. 20, the Web browser of the user terminal 3 accepts a selection input from the user for the failure handling page (FIG. 21), and transmits the selection input data to the operation monitoring apparatus 5 (FIG. 20: Step S177). The operation monitoring view reproduction unit 523 of the operation monitoring device 5 receives the selected input data from the user terminal 3 and temporarily stores it in a storage device such as a work memory area (step S179). Then, the failure handling unit 511 generates failure handling data based on the view definition data and the received selection input data, and stores it in the failure handling file storage unit 513 (step S181). Then, the process returns to the original process.

  In this way, the fact that the failure has been dealt with is registered as failure handling data. Note that after this failure handling processing, view data generation / update processing may be performed to update the view data to the latest one.

  As described above, the processing in the system configuration shown in FIG. 1 is performed.

  Although one embodiment of the present invention has been described above, the present invention is not limited to this. For example, the table configurations and file configurations shown in FIGS. 2 to 7 are examples, and other configurations may be adopted as long as similar data is stored, and items may be changed as necessary. You may add or delete. Note that a managed device group does not necessarily include a plurality of devices, and may be configured by a single managed device. Similarly, the monitoring item group may be composed of one type of monitoring item. Moreover, although the example in which the screen history data stored in the screen history file storage unit 521 includes pre-update data and post-update data has been shown, the difference between the date and the number of failures is calculated and stored. May be.

  Also, the functional block configuration of the operation monitoring apparatus 5 shown in FIG. 1 is an example, and may differ from the actual program / module configuration. Each device may be configured by a plurality of servers and computers. In addition, the screen examples shown in FIGS. 11, 12, 14, 18, 19, and 21 are examples, and the same data may be expressed in different modes. Furthermore, the processing flows shown in FIG. 8, FIG. 9, FIG. 10, FIG. 13, FIG. 15, FIG. 17 and FIG. 20 are also examples, and the processing order may be changed within a range where similar processing results can be obtained. However, steps may be added or deleted as necessary. The schematic diagram of view data update (screen transition) shown in FIG. 16 is also an example, and the screen elements, update timing, and update contents are not limited to the case shown in FIG.

(Appendix 1)
A method for monitoring a failure of a device connected to a predetermined network,
A view definition file that includes data relating to the device in which the failure is detected, the date and time of occurrence of the failure, and the failure content corresponding to the monitoring item, and the failure data stored in the failure data file storage unit, and data relating to the screen display content A view data generation step of generating view data using the view definition data stored in the storage unit and storing the view data in the view data storage unit;
Executing the view data generation step at a predetermined interval to update the view data;
When the screen component included in the view data shows different values before and after the update of the view data, screen history data is generated using data related to a change in the value of the screen component, and a screen history file storage unit A failure monitoring method executed by a computer, including a screen history data generation step stored in the computer.

(Appendix 2)
Using the screen history data stored in the screen history file storage unit, a related device specifying step for specifying a device group in which a failure is detected for the same monitoring item or monitoring item group within a predetermined period;
A related view data generation step of generating view data for indicating to a user in a manner capable of specifying data relating to the failure of the specified device group, and storing the generated view data in the view data storage unit;
The failure monitoring method according to appendix 1, further comprising:

(Appendix 3)
The related view data generation step includes:
Based on the failure handling data stored in the failure handling file storage unit including data relating to the implementation of the failure handling, among the device groups identified in the related device identification step, the device group that has been treated for the failure is routed. Identifying as a cause,
Generating view data for indicating to a user in a manner capable of specifying data relating to a failure of a device group that has been identified as a root cause and has been treated for the failure, and storing the generated view data in the view data storage unit;
The fault monitoring method according to appendix 2, including

(Appendix 4)
The related view data generation step includes:
A device having the smallest number of hops among the device groups identified in the related device identification step based on configuration information that includes data relating to attributes of each device in the predetermined network and stored in a configuration information file storage unit Identifying a device group containing as root causes;
Generating view data for indicating to a user in a manner capable of specifying data relating to a failure of a device group including a device having the smallest number of hops identified as route causes, and storing the generated view data in the view data storage unit When,
The fault monitoring method according to appendix 2, including

(Appendix 5)
The view data generation step includes:
Based on the failure data and the failure handling data, totaling the number of failures that have been detected from the previous update time to the current time and are not yet handled for each device group and monitoring item group;
Generating view data using the total number of failures and storing the view data in the view data storage unit;
The failure monitoring method according to any one of appendices 1 to 4, including:

(Appendix 6)
If the previous screen display request is received, the step of identifying the screen history data corresponding to the view data of the current screen and stored in the screen history file storage unit;
Generating view data of the previous screen using the identified screen history data and the view data of the current screen, and storing the view data in the view data storage unit;
The fault monitoring method according to any one of appendices 1 to 5, further including:

(Appendix 7)
The screen history data includes a component update date and time that is a date and time when a change in the value of the screen component is detected,
When receiving a request for a subsequent screen display, identifying screen history data corresponding to the view data of the current screen and stored in the screen history file storage unit;
Using the screen history data including the next component update date and time after the component update date and time included in the identified screen history data and the view data of the current screen to generate the view data of the rear screen, Storing in the view data storage unit;
The fault monitoring method according to any one of appendices 1 to 6, further comprising:

(Appendix 8)
The screen history data includes a component update date and time that is a date and time when a change in the value of the screen component is detected,
When a screen display request for a specific date and time is received, at least screen view data on the current screen and screen history data including a component update date and time that is earlier than the specific date and time and closest to the specific date and time Using the specific date and time to generate view data and storing it in the view data storage unit;
The fault monitoring method according to any one of appendices 1 to 7, further including:

(Appendix 9)
The view data generation step includes:
Identifying a device group and a monitoring item group that have not yet been subjected to the failure handling based on the failure handling data that includes data relating to the implementation of the failure handling and that is stored in the failure handling file storage unit; and
Generating view data for showing data to the user in a manner capable of specifying data relating to the failure of the specified device group and monitoring item group, and storing the generated view data in the view data storage unit;
The failure monitoring method according to any one of appendices 1 to 8, including:

(Appendix 10)
A failure monitoring program for monitoring a failure of a device connected to a predetermined network,
A view definition file that includes data relating to the device in which the failure is detected, the date and time of occurrence of the failure, and the failure content corresponding to the monitoring item, and the failure data stored in the failure data file storage unit, and data relating to the screen display content A view data generation step of generating view data using the view definition data stored in the storage unit and storing the view data in the view data storage unit;
Executing the view data generation step at a predetermined interval to update the view data;
When the screen component included in the view data shows different values before and after the update of the view data, screen history data is generated using data relating to a change in the value of the screen component, and a screen history file storage unit A fault monitoring program that causes a computer to execute the steps stored in.

(Appendix 11)
A failure monitoring device that monitors a failure of a device connected to a predetermined network,
A view definition file that includes data relating to the device in which the failure is detected, the date and time of occurrence of the failure, and the failure content corresponding to the monitoring item, and the failure data stored in the failure data file storage unit, and data relating to the screen display content View data generation means for generating view data using the view definition data stored in the storage unit and storing the view data in the view data storage unit;
Means for generating the view data by the view data generating means at a predetermined interval and updating the view data;
When the screen component included in the view data shows different values before and after the update of the view data, screen history data is generated using data related to a change in the value of the screen component, and a screen history file storage unit A fault monitoring device having means for storing the fault.

1 is a system configuration diagram according to an embodiment of the present invention. It is a figure which shows an example of a structure information file table. It is a figure which shows an example of a failure data file table. It is a figure which shows an example of a view definition file. It is a figure which shows an example of a failure handling file table. It is a figure which shows an example of a screen history file table. It is a figure which shows an example of view data. It is a figure which shows the processing flow of a monitoring process. It is a figure which shows the processing flow of view data production | generation and an update process. It is a figure which shows the processing flow (the 1) in one embodiment of this invention. It is a figure which shows an example of the newest view page. It is a figure which shows an example of the page for screen data download. It is a figure which shows the processing flow (the 2) in one embodiment of this invention. It is a figure which shows an example of a date specification page. It is a figure which shows the processing flow (the 3) in one embodiment of this invention. It is a schematic diagram of update of view data. It is a figure which shows the processing flow (the 4) in one embodiment of this invention. It is a figure which shows an example of a related fault designation | designated page. It is a figure which shows an example of a related fault display view page. It is a figure which shows the processing flow of a failure handling process. It is a figure which shows an example of a failure handling page.

Explanation of symbols

DESCRIPTION OF SYMBOLS 1 Network 3 User terminal 5 Operation monitoring device 7, 9, 11, 13 Managed apparatus 501 Monitoring definition file storage part 503 Monitoring part 505 Configuration information file storage part 507 Collected data file storage part 509 Fault data file storage part 511 Fault Handling unit 513 Failure handling file storage unit 515 Latest operation monitoring view creation unit 517 View definition file storage unit 519 View data storage unit 521 Screen history file storage unit 523 Operation monitoring view reproduction unit

Claims (5)

A method for monitoring a failure of a device connected to a predetermined network,
A view definition file that includes data relating to the device in which the failure is detected, the date and time of occurrence of the failure, and the failure content corresponding to the monitoring item, and the failure data stored in the failure data file storage unit, and data relating to the screen display content A view data generation step of generating view data using the view definition data stored in the storage unit and storing the view data in the view data storage unit;
Executing the view data generation step at a predetermined interval to update the view data;
When the screen component included in the view data shows different values before and after the update of the view data, screen history data is generated using data related to a change in the value of the screen component, and a screen history file storage unit A failure monitoring method executed by a computer, including a screen history data generation step stored in the computer. Using the screen history data stored in the screen history file storage unit, a related device specifying step for specifying a device group in which a failure is detected for the same monitoring item or monitoring item group within a predetermined period;
A related view data generation step of generating view data for indicating to a user in a manner capable of specifying data relating to the failure of the specified device group, and storing the generated view data in the view data storage unit;
The fault monitoring method according to claim 1, further comprising: The related view data generation step includes:
Based on the failure handling data stored in the failure handling file storage unit including data relating to the implementation of the failure handling, among the device groups identified in the related device identification step, the device group that has been treated for the failure is routed. Identifying as a cause,
Generating view data for indicating to a user in a manner capable of specifying data relating to a failure of a device group that has been identified as a root cause and has been treated for the failure, and storing the generated view data in the view data storage unit;
The fault monitoring method according to claim 2 including: The related view data generation step includes:
A device having the smallest number of hops among the device groups identified in the related device identification step based on configuration information including data relating to attributes of each device in the predetermined network and stored in a configuration information file storage unit Identifying a device group containing as root causes;
Generating view data for indicating to a user in a manner capable of specifying data relating to a failure of a device group including a device having the smallest number of hops identified as route causes, and storing the generated view data in the view data storage unit When,
The fault monitoring method according to claim 2 including: A failure monitoring program for monitoring a failure of a device connected to a predetermined network,
A view definition file that includes data relating to the device in which the failure is detected, the date and time of occurrence of the failure, and the failure content corresponding to the monitoring item, and the failure data stored in the failure data file storage unit, and data relating to the screen display content A view data generation step of generating view data using the view definition data stored in the storage unit and storing the view data in the view data storage unit;
Executing the view data generation step at a predetermined interval to update the view data;
When the screen component included in the view data shows different values before and after the update of the view data, screen history data is generated using data related to a change in the value of the screen component, and a screen history file storage unit A fault monitoring program that causes a computer to execute the steps stored in.

Images