JP6229537B2 - Management program and management device - Google Patents

Description

  The present invention relates to a management program and a management apparatus.

  A person in charge of monitoring and managing a plurality of servers performs an operation of confirming a message transmitted from the monitoring server that monitors the plurality of servers. The message transmitted from the monitoring server includes a message regarding an error occurring in the monitoring target server, a message notifying that the processing load on the server has increased, and the like.

  Since each server periodically performs batch processing or restart, the monitoring server may periodically notify a message associated with batch processing or restart. Such a periodically notified message is often a message that does not need to be confirmed.

  Conventionally, in the field of electronic mail, a method for detecting an unnecessary electronic mail message based on a probabilistic analysis of a reference resource is known (for example, see Patent Document 1).

Special table 2008-547067 gazette

  When monitoring is performed 24 hours, the server is often monitored while a plurality of persons in charge change. Especially in the night time zone, the same person in charge rarely monitors the same time zone every day. Therefore, it is difficult for the person in charge to determine whether or not the message from the monitoring server is a regularly generated message, so the person in charge must manually set non-notification of messages that do not require notification. Is not easy.

  In one aspect, an object of the present invention is to provide a management program and a management apparatus capable of not notifying a message that is not required to be notified among messages generated in a device connected to a network. .

  In one aspect, the management program is a management program for managing a message generated in a device connected to a network, and a plurality of message information including at least message identification information and a time when the message was generated Referring to the stored storage unit, a message periodically generated a predetermined number of times or more with common identification information is specified, the identification information is common with the identification information of the specified message, and the specified message is periodically When a message generated at a timing that coincides with the generated timing is received, the management program performs control so that the received message is not notified, and causes the computer to execute processing.

  In one aspect, the management device is a management device for managing a message generated in a device connected to the network, and a plurality of message information including at least message identification information and a time when the message was generated. The stored storage unit, a specifying unit that refers to the storage unit and identifies a message that is regularly generated a predetermined number of times or more with common identification information, and identification of the message whose identification information is specified by the specifying unit A control unit that performs control not to notify the received message when receiving a message that is common to information and that is generated at a timing that matches the timing at which the message specified by the specifying unit is periodically generated; It has.

  It is possible to prevent notification of messages that are not required to be notified from among messages generated in a device connected to the network.

It is a figure showing roughly the composition of the server monitoring system concerning one embodiment. It is a hardware block diagram of a monitoring server. It is a functional block diagram of CPU of a monitoring server. It is a flowchart which shows the process of a monitoring part and a transmission part. It is a flowchart which shows the specific process of step S12 of FIG. 6A and 6B are diagrams illustrating an example of a message. It is a figure which shows the data structure of a monitoring format information table. It is a figure which shows the data structure of acquisition message DB. It is a figure which shows the data structure of a non notification setting master. It is a figure which shows the data structure of notification message DB. It is a flowchart which shows the process of a non notification setting part. It is a flowchart which shows the specific process of step S32 of FIG. It is a figure for demonstrating the process of step S30 of FIG. It is a figure for demonstrating the process of FIG.12 S50. FIG. 15A and FIG. 15B are diagrams for explaining the processing in step S54 in FIG. It is a figure which shows the data structure of a regularity determination threshold value table. It is a figure for demonstrating the effect of one Embodiment.

  Hereinafter, an embodiment of a server monitoring system will be described in detail with reference to FIGS.

  FIG. 1 schematically shows the configuration of a server monitoring system 100 according to an embodiment. The server monitoring system 100 is a system for monitoring the monitoring target server 10 included in the in-hospital system 40 provided in each of a plurality of hospitals, for example.

  As shown in FIG. 1, the server monitoring system 100 includes an in-hospital system 40, a monitoring log DB 60, and a monitoring staff terminal 70. The in-hospital system 40, the monitoring log DB 60, and the monitoring staff terminal 70 are connected to a network 80 such as the Internet.

  The in-hospital system 40 includes one or a plurality of monitoring target servers 10 as devices to be monitored and a monitoring server 20 as a management device. The monitoring target server 10 and the monitoring server 20 are connected to a network 30 such as a LAN (Local Area Network).

  The monitoring target server 10 is a server that processes and manages electronic medical record data and the like handled in a hospital. The data managed by the monitoring target server 10 includes data input from a doctor terminal (not shown) connected to the network 30, and each data can be viewed from the doctor terminal.

  The monitoring server 20 monitors the status of the monitoring target server 10 and generates and outputs error information (also referred to as a message) when an error or the like is output from the monitoring target server 10. The message output from the monitoring target server 10 is generated when a certain process runs on the monitoring target server 10 or when the disk usage rate of the monitoring target server 10 exceeds a predetermined threshold. Included messages.

  FIG. 2 schematically shows the hardware configuration of the monitoring server 20. As shown in FIG. 2, the monitoring server 20 includes a CPU (Central Processing Unit) 90, a ROM (Read Only Memory) 92, a RAM (Random Access Memory) 94, a storage unit (here, an HDD (Hard Disk Drive)) 96, A network interface 97 and a portable storage medium drive 99 are provided. Each component of the monitoring server 20 is connected to the bus 98. In the monitoring server 20, the CPU 90 executes a program (including a management program) stored in the ROM 92 or the HDD 96 or a program (including a management program) read from the portable storage medium 91 by the portable storage medium drive 99. Thereby, the function of each part of FIG. 3 is implement | achieved.

  FIG. 3 is a functional block diagram of the CPU 90 of the monitoring server 20. As illustrated in FIG. 3, the CPU 90 realizes functions of a monitoring unit 22 as a control unit, a transmission unit 24, and a non notification setting unit 26 as a specifying unit by executing a program. 3 also shows a monitoring format information table 32, a regularity determination threshold table 34, an acquisition message DB 36, a non notification setting master 38, and a notification message DB 42 as a storage unit stored in the HDD 96 or the like. .

  The monitoring unit 22 communicates with the monitoring target server 10 via the network 30 and monitors the state of the monitoring target server 10. Specifically, when the message generated in the monitoring target server 10 is transmitted, the monitoring unit 22 receives the message and stores it in the acquired message DB 36. Further, the monitoring unit 22 stores the received message in the notification message DB 42 by distinguishing between a message that should be notified to a person in charge of monitoring and a message that need not be notified. The monitoring unit 22 uses the monitoring format information table 32 and the non-notification setting master 38 in the above processing, and the data structure and the like of these tables and the master will be described later.

  The transmission unit 24 outputs the message stored in the notification message DB 42 to the monitoring log DB 60 at a predetermined time interval (for example, every 5 minutes).

  The non notification setting unit 26 analyzes the message stored in the notification message DB 42 and updates the non notification setting master 38.

  Returning to FIG. 1, the monitoring log DB 60 accumulates messages transmitted from the transmission unit 24 of the monitoring server 20.

  The monitoring person in charge terminal 70 is a terminal used by a person in charge of monitoring, and has a function of reading and displaying messages stored in the monitoring log DB 60 at predetermined time intervals. As the monitoring staff terminal 70, a PC (Personal Computer), a portable terminal, a tablet terminal, or the like can be used.

(Processing of the monitoring unit 22 and the transmission unit 24)
Next, the processing of the monitoring unit 22 and the transmission unit 24 of the monitoring server 20 will be described in detail with reference to other drawings as appropriate along the flowcharts of FIGS.

  In the process of FIG. 4, first, in step S <b> 10, the monitoring unit 22 executes a monitoring process for the monitoring target server 10. Specifically, when error information (message) generated in the monitoring target server 10 is output, the monitoring unit 22 receives input of the message. The message includes a message indicating that a predetermined process has been operated, a message indicating that the disk usage rate has exceeded a predetermined threshold, and the like. For example, it is assumed that a message as shown in FIG. 6A or FIG. 6B is output from the monitoring target server 10 installed in the hospital whose facility ID is A0001. The messages shown in FIGS. 6A and 6B include “facility ID”, “monitoring IP address”, “monitoring date / time”, “day of the week”, “monitoring item”, “error category”, “message content”. Is included. The “facility ID” item stores the identifier of the hospital where the in-hospital system 40 is installed, and the “monitoring target IP address” item stores the IP address of the monitoring target server 10. The items “monitoring date and time” and “day of the week” store the date, time, and day of the week when the message was generated in the monitoring target server 10, and the item “monitoring item” indicates what kind of error the error is related to. In the “error category” item, error category information (such as Error) is stored. Further, in the “message content” item, error information, that is, if the monitoring item is “process operation”, information indicating which process has been operated is stored, and the monitoring item is “disk usage rate”. For example, information indicating which disk is used and how much is stored.

  Next, in step S <b> 12, the monitoring unit 22 executes processing for storing the message in the notification message DB 42. In step S12, the process according to the flowchart of FIG. 5 is executed.

  In the process of FIG. 5, the monitoring unit 22 reads the monitoring format information table 32 in step S20. Here, the monitoring format information table 32 is a table that defines which data should be referred to by the monitoring unit 22 among the “message contents” included in the information of FIGS. 6A and 6B. The monitoring format information table 32 has a data structure as shown in FIG. 7, for example.

  As shown in FIG. 7, the monitoring format information table 32 has fields of “monitoring item”, “data No.”, “key”, and “data name”. In the “monitoring item” field, the same information as the “monitoring item” item of the message in FIGS. 6A and 6B is stored. In “Data No.”, a number indicating the number of data from the left of a plurality of data divided by “,” in the “message contents” of FIGS. 6A and 6B is stored. Is done. In the “key” field, “ON” is stored when the data to be referred to by the monitoring unit 22, and “OFF” is stored when the data does not need to be referred to by the monitoring unit 22. The name of data is stored in the “data name” field.

  According to the monitoring format information table 32 of FIG. 7, for example, when the monitoring item is “process operation” and the message is “xxx, yyy”, the first data “xxx” from the left is the process name. It can be seen that the second data “yyy” from the left is the process name data. It can also be seen that the process name data “xxx” is data that the monitoring unit 22 should refer to.

  Next, in step S22, the monitoring unit 22 extracts a key item of the message. Here, the key item of the message means data to be referred to by the monitoring unit 22 in the messages of FIGS. 6A and 6B. In the case of the message in FIG. 6A, since the monitoring item is “process active” and the message content is “ProcessA, process A”, the key item of the message is “ProcessA” from the monitoring format information table 32 of FIG. Is extracted. On the other hand, in the case of the message shown in FIG. 6B, the monitoring item is “disk usage rate” and the message content is “C :, 92.3%”. C: "is extracted.

  Next, in step S24, the monitoring unit 22 stores the message and the key item in the acquisition message DB 36 of FIG. As shown in FIG. 8, the acquisition message DB 36 includes a field for storing each item of the messages in FIGS. 6A and 6B and a “key item” field. When the message acquired in step S10 is the message in FIG. 6B, the monitoring unit 22 sets each item of the message in FIG. 6B as shown in the first line from the bottom in FIG. Information and the key item information extracted in step S22 are stored.

  Next, in step S26, the monitoring unit 22 reads a message newly added to the acquisition message DB 36 (a line newly added in FIG. 8), and executes a non-notification process for each message. In step S26, the monitoring unit 22 refers to the non notification setting master 38 shown in FIG. 9, and stores the result of the non notification processing in the notification message DB 42 shown in FIG. Here, the non notification setting master 38 is a table that defines a message that should be non notification. As shown in FIG. 9, the non notification setting master 38 includes fields of “facility ID”, “monitoring IP address”, “monitoring item”, “error classification”, “message condition”, and “non notification condition”. Have. In the fields of “facility ID”, “monitoring target IP address”, “monitoring item”, and “error classification”, “facility ID”, “monitoring target IP address” in FIG. 6A and FIG. Information similar to each item of “monitor item” and “error category” is stored. In the “message condition” and “non-notification condition” fields, what is the key item of the message, and at what timing is the condition for non-notification is stored. For example, in the case of the first line from the top of FIG. 9, an error of the key item “ProcessA” is generated at the monitoring target server 10 of the monitoring target IP address “192.168.0.10” of the facility ID “A0001” at time 1:00 on Tuesday. In this case, it is defined that the error information is set to non notification. In the case of the third line from the top of FIG. 9, the error of the key item “C:” occurs at the monitoring target server 10 of the monitoring target IP address “192.168.0.20” of the facility ID “A0002” at 2:00 on Friday. It is defined that the error information is set to non notification when it is generated. A method of adding data to the non notification setting master 38 will be described later.

  FIG. 10 shows the data structure of the notification message DB 42. As shown in FIG. 10, the notification message DB 42 has a field of “non-notification flag” in addition to the same field as the acquisition message DB 36. In the “non notification flag” field, “ON” or “OFF” is stored. A message in which “ON” is stored means that it is not necessary to notify the person in charge, and a message in which “OFF” is stored is a message to be notified to the person in charge. It means that there is.

  For example, in FIG. 10, the message on the third line from the bottom satisfies the condition on the first line from the top of the non notification setting master 38 in FIG. 9, so the non notification flag is “ON”. Further, since the message on the second line from the bottom of FIG. 10 satisfies the condition on the fourth line from the top of the non notification setting master 38 of FIG. 9, the non notification flag is “ON”. On the other hand, since the message on the first line from the bottom of FIG. 10 does not satisfy the condition of any line of the non notification setting master 38 of FIG. 9, the non notification flag is “OFF”. When all the processes in FIG. 5 are completed as described above, the process proceeds to step S14 in FIG.

  Returning to FIG. 4, in step S <b> 14, the transmission unit 24 transmits and stores the new message stored in the notification message DB 42 to the monitoring log DB 60. Note that the transmission unit 24 may transmit and store only the message with the non-notification flag “OFF” to the monitoring log DB 60. In this case, the transmission unit 24 may not transmit the information stored in the “non notification flag” field to the monitoring log DB 60.

  After step S14 is performed, the process returns to step S10 and the above-described processes are repeated.

  The monitoring person in charge terminal 70 notifies the error information to the person in charge by reading a new message from the monitoring log DB 60 and displaying a message with the non-notification flag “OFF” at predetermined time intervals. . As a result, messages that need not be confirmed by the person in charge can be prevented from being notified, so that the person in charge only needs to confirm the message that needs to be confirmed, and the work efficiency of the person in charge is improved.

  In the present embodiment, the monitoring unit 22 uses the processing in FIGS. 4 and 5 to share the message items stored in the non notification setting master 38 with the key items in the non notification conditions corresponding to the message conditions. It can be said that control is performed not to notify the received message when a message generated at a timing that matches the timing defined in FIG.

(Processing of the non notification setting unit 26)
Next, with respect to the update method of the non-notification setting master 38 by the non-notification setting unit 26, that is, the method of adding data to the non-notification setting master 38, refer to other drawings as appropriate according to the flowcharts of FIGS. However, this will be described in detail. 11 and 12 is executed every predetermined time (for example, every week).

  In the process of FIG. 11, first, in step S30, the non-notification setting unit 26 selects “facility ID” and “monitoring target IP address” from the messages whose non-notification flag is “OFF” in the notification message DB. And a message having the same “key item” is extracted. FIG. 13 shows, as an example, a result of extracting a message with facility ID = A0001, monitoring target IP address = 192.168.0.10, and key item = ProcessA. For convenience of explanation, the notification message DB 42 of FIG. 10 does not correspond to FIG.

  Next, in step S32, the non-notification setting unit 26 executes processing for determining a rule from the monitoring date and time. Specifically, the non-notification setting unit 26 executes processing according to the flowchart of FIG. 12 in step S32.

  In the process of FIG. 12, first, in step S50, the non-notification setting unit 26 extracts the time interval of the monitoring date and time. In the case of FIG. 13, as shown in FIG. 14, 96 hours and 72 hours are alternately extracted as the time interval.

  Next, in step S52, the non notification setting unit 26 determines whether or not the same time interval continues for a continuous occurrence determination threshold (see FIG. 16) or more. In the case of FIG. 14, since 96 hours and 72 hours are alternately extracted and are not continuous, the determination in step S52 is negative and the process proceeds to step S54. If the determination in step S52 is affirmative, the process proceeds to step S58.

  When the determination in step S52 is negative and the process proceeds to step S54, the non notification setting unit 26 extracts the time interval of the monitoring date and time for each day of the week. For example, when the time interval of the message on Tuesday is extracted from FIG. 13, the time interval as shown in FIG. 15A is extracted. For example, when the time interval of the message on Friday is extracted from FIG. 13, the time interval as shown in FIG. 15B is extracted.

  Next, in step S56, the non notification setting unit 26 determines whether or not the same time interval continues for a continuous occurrence determination threshold value or more. In the case of FIG. 15A and FIG. 15B, the same time interval is continuous, and the continuous number of times is the continuous occurrence determination threshold defined in the regularity determination threshold table 34 shown in FIG. Since it is equal to or greater than (3 times in the case of process operation), the determination in step S56 is affirmed, and the process proceeds to step S58. Note that the continuous occurrence determination threshold in the regularity determination threshold table 34 of FIG. 16 may be determined by an administrator or the like, or may be determined in advance for each monitoring item. Alternatively, the continuous occurrence determination threshold value may be a common value regardless of the monitoring item.

  In step S58, the non notification setting unit 26 acquires message non notification setting information. Specifically, the non notification setting unit 26 sets the process name = “ProcessA”, the day of the week = “Tuesday”, and the time = “10:00” based on the extraction condition of the time interval in FIG. Acquired as notification setting information. Further, the non notification setting unit 26 acquires process name = “ProcessA”, day of the week = “Friday”, and time = “10:00” as message non notification setting information based on the extraction condition of FIG. . Thereafter, the process proceeds to step S34 in FIG.

  On the other hand, if the determination in step S56 is negative, that is, if the time intervals extracted for each day of the week are not continuous at the same time interval, the process proceeds to step S60. If transfering it to step S60, the non notification setting part 26 will extract the time contained in the monitoring date for every day.

  Next, in step S62, the non-notification setting unit 26 determines whether or not the same time continues for a continuous occurrence determination threshold or more. If the determination in step S62 is affirmative, the non-notification setting unit 26 proceeds to step S58, performs step S58 in the same manner as described above, and then proceeds to step S34 in FIG. On the other hand, if the determination in step S62 is negative, the entire process in FIG. 12 is terminated, and the process proceeds to step S34 in FIG.

  Returning to FIG. 11, when the process proceeds to step S <b> 34, the non-notification setting unit 26 determines whether or not non-notification setting information has been acquired in the process of FIG. 12, that is, whether or not step S <b> 58 has been performed. If the determination in step S34 is negative, the process proceeds to step S38. If the determination in step S34 is positive, the process proceeds to step S36.

  If transfering it to step S36, the non notification setting part 26 will store message non notification setting information in the non notification setting master 38, and will transfer to step S38. If the same message non notification setting information has already been stored in the non notification setting master 38, the process of step S36 is not executed.

  In step S38, the non notification setting unit 26 determines whether or not the monitoring results of all the key items included in the notification message DB 42 have been extracted. If the determination in step S38 is negative, the process returns to step S30, and the non-notification setting unit 26 performs the processes in steps S30 to S38 for different key items. On the other hand, if the determination in step S38 is affirmative, the non-notification setting unit 26 ends all the processes in FIG. Note that the data in the notification message DB 42 corresponding to the contents registered in the non-notification setting master 38 by the non-notification setting unit 26 may be excluded from the processing target when performing the process of FIG. In the above description, the non notification setting unit 26 extracts a message from the notification message DB 42 in step S30. However, the present invention is not limited to this, and a message may be extracted from the acquisition message DB 36.

  As described above, the non-notification setting unit 26 executes the processes shown in FIGS. 11 and 12 so that the non-notification setting master 38 is updated as needed. This makes it possible to appropriately perform non-notification setting for messages that do not require notification in the processes of FIGS.

  The non-notification setting unit 26 executes the processes of FIGS. 11 and 12 to refer to the notification message DB 42 in which a plurality of messages including at least the key item and the time at which the message is generated are stored. It can be said that the key item is periodically processed to identify a message generated above the continuous occurrence determination threshold.

  As described above in detail, according to the present embodiment, when a message generated in the monitoring target server 10 connected to the networks 30 and 80 is managed, the identification information (key item) and the time when the message was generated Refer to the notification message DB 42 in which a plurality of messages including at least (monitoring date and time, day of the week) are stored, and identify messages that are regularly generated by the common identification information (key item) above the continuous occurrence determination threshold (S32). When the identification information (key item) is the same as the identification information (key item) identified in step S32 and a message generated at a timing that matches the timing at which the identified message is periodically generated is received, Control is performed not to notify the received message (S26). As a result, the same message (error information) that is regularly notified can be prevented from being notified to the person in charge of monitoring. Therefore, the person in charge only needs to confirm the message that needs to be confirmed, so that the work efficiency of the person in charge can be improved. Here, in a situation where the same person in charge can confirm a periodically generated message, it is considered that the person in charge can manually set the non notification of the message. However, when the person in charge to be monitored changes, as shown in the rightmost column of FIG. 17, in a situation where a different person in charge confirms a message that is periodically generated, the message is periodically generated. It is difficult to grasp whether or not As described above, the monitoring server 20 according to the present embodiment is particularly useful in a situation where it is difficult to grasp a periodically generated message and it is difficult to manually set a message non-notification.

  In the present embodiment, in step S26, a message having the same identification information (key item) generated on the same day of the week is extracted from the notification message DB 42, and continuous occurrence determination is performed every predetermined time among the extracted messages. Identify messages generated above the threshold. Thereby, since a message periodically notified at a certain time on a certain day of the week can be specified, it is possible to appropriately specify a message that should not be notified. In particular, as illustrated in FIG. 14, even when a message that should not be notified cannot be specified by simply extracting a time interval, as described with reference to FIGS. 15A and 15B. In addition, it is possible to specify a message that should not be notified.

  In step S26, a message having the same identification information (key item) generated on the same date is extracted from the notification message DB 42. Among the extracted messages, a message generated at a predetermined time equal to or greater than the continuous occurrence determination threshold. Is specified (S60, S62). As a result, since a message periodically notified at a certain time of each month can be specified, it is possible to appropriately specify a message that should not be notified. In particular, as shown in FIG. 14, even if a message that should not be notified cannot be specified by simply extracting a time interval, it is possible to specify a message that should not be notified.

  In the above embodiment, the case where the processes of FIGS. 4 and 5 and the processes of FIGS. 11 and 12 are executed separately has been described. However, the present invention is not limited to this, and the flow of the processes of FIGS. Thus, the processing of FIGS. 11 and 12 may be executed.

  In the above embodiment, the case where the monitoring server 20 is included in the in-hospital system 40 has been described. However, the present invention is not limited to this. For example, the monitoring server 20 may be provided on the network 80 and may monitor the monitoring target servers 10 in the plurality of hospital systems 40. Further, for example, instead of the monitoring log DB 60, a data server having a database for storing data and capable of executing a predetermined process may be employed. In this case, the data server may execute the process (FIGS. 4, 5, 11, and 12) of the monitoring server 20 described in the above embodiment.

  In addition, although the said embodiment demonstrated the case where the monitoring server 20 was used in the hospital system 40 installed in a hospital, it is not restricted to this. For example, the monitoring server 20 may be used in another system installed in a company or school.

  The above processing functions can be realized by a computer. In that case, a program describing the processing contents of the functions that the processing apparatus should have is provided. By executing the program on a computer, the above processing functions are realized on the computer. The program describing the processing contents can be recorded on a computer-readable recording medium (except for a carrier wave).

  When the program is distributed, for example, it is sold in the form of a portable recording medium such as a DVD (Digital Versatile Disc) or a CD-ROM (Compact Disc Read Only Memory) on which the program is recorded. It is also possible to store the program in a storage device of a server computer and transfer the program from the server computer to another computer via a network.

  The computer that executes the program stores, for example, the program recorded on the portable recording medium or the program transferred from the server computer in its own storage device. Then, the computer reads the program from its own storage device and executes processing according to the program. The computer can also read the program directly from the portable recording medium and execute processing according to the program. Further, each time the program is transferred from the server computer, the computer can sequentially execute processing according to the received program.

  The above-described embodiment is an example of a preferred embodiment of the present invention. However, the present invention is not limited to this, and various modifications can be made without departing from the scope of the present invention.

In addition, the following additional remarks are disclosed regarding description of the above embodiment.
(Supplementary note 1) A management program for managing messages generated in a device connected to a network,
With reference to a storage unit in which a plurality of message information including at least the identification information of the message and the time when the message was generated is stored, the message that is regularly generated a predetermined number of times or more with the common identification information is specified,
Control is performed not to notify the received message when the received message is the same as the identification information of the specified message and the generated message matches the timing at which the specified message is periodically generated. Do,
A management program that causes a computer to execute processing.
(Additional remark 2) The said process to identify extracts the message with the same identification information produced | generated on the same day of the week from the said memory | storage part, The message produced | generated more than predetermined times for every predetermined time among the extracted messages The management program according to attachment 1, wherein the management program is specified.
(Additional remark 3) The said process to identify extracts the message with the same identification information produced | generated on the same day from the said memory | storage part, and identifies the message produced | generated at the predetermined time more than predetermined times among the extracted messages. The management program according to supplementary note 1, wherein:
(Supplementary Note 4) A management device for managing messages generated in a device connected to a network,
A storage unit storing a plurality of message information including at least the identification information of the message and the time when the message was generated;
A specific unit that refers to the storage unit and identifies a message that is periodically generated a predetermined number of times or more with common identification information;
When the identification information is common to the identification information of the message specified by the specifying unit and the message generated at a timing that matches the timing at which the message specified by the specifying unit is periodically generated is received A control unit that performs control not to notify the message.
(Additional remark 5) The said specific | specification part extracts the message with the same identification information produced | generated on the same day of the week from the said memory | storage part, and specifies the message produced | generated more than predetermined times for every predetermined time among the extracted messages. The management apparatus according to appendix 4, wherein
(Additional remark 6) The said specific part extracts the message with the same identification information produced | generated on the same day from the said memory | storage part, and specifies the message produced | generated at predetermined time more than predetermined times among the extracted messages. The management apparatus according to appendix 4, wherein

10 Monitored server (device)
20 Monitoring server (management device)
22 Monitoring unit (control unit)
26 Non notification setting part (specific part)
30 Network 42 Notification message DB (storage unit)

Claims (4)

A management program for managing messages generated in a device connected to a network,
With reference to a storage unit in which a plurality of message information including at least the identification information of the message and the time when the message was generated is stored, the message that is regularly generated a predetermined number of times or more with the common identification information is specified,
Control is performed not to notify the received message when the received message is the same as the identification information of the specified message and the generated message matches the timing at which the specified message is periodically generated. Do,
A management program that causes a computer to execute processing.   The specifying process includes extracting a message having the same identification information generated on the same day of the week from the storage unit, and specifying a message generated a predetermined number of times or more for each predetermined time among the extracted messages. The management program according to claim 1, wherein:   The specifying process extracts a message having the same identification information generated on the same date from the storage unit, and specifies a message generated at a predetermined time more than a predetermined number of times among the extracted messages. The management program according to claim 1. A management device for managing messages generated in a device connected to a network,
A storage unit storing a plurality of message information including at least the identification information of the message and the time when the message was generated;
A specific unit that refers to the storage unit and identifies a message that is periodically generated a predetermined number of times or more with common identification information;
When the identification information is common to the identification information of the message specified by the specifying unit and the message generated at a timing that matches the timing at which the message specified by the specifying unit is periodically generated is received A control unit that performs control not to notify the message.

Images