Surveillance system and method

Abstract

To provide a monitoring system that can obtain the metrics that users need as a priority.SOLUTION: When a specified user carries out a failure investigation for a specified failure, a manager host extracts an operation history for a specified period of time since the failure in classification of metrics that corresponds to classification of metrics having represented the specified failure occurred from the operation history of the specified user stored in a storage unit, and counts the extracted operation history for each classification of metrics, determines the priority of metrics to be obtained by the agent host based on the number of operation histories of classification of metrics that corresponds to the above-mentioned classification of metrics, and requests the metrics from the agent host according to the determined priority. The agent host sends the metrics to the manager host in response to the request from the manager host, and the manager host sends the metrics sent from the agent host to the user terminal of the specified user.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] The present invention relates generally to techniques for monitoring faults. [Background technology]

[0002] In recent years, as systems have become larger in scale, users such as system administrators and application developers are collecting and analyzing more and more data when monitoring systems, more specifically, metrics such as memory usage and data transfer speed.

[0003] For example, when a system failure occurs, users use metrics to deal with the failure. In that case, limiting the metrics to be acquired can reduce the amount of data to be analyzed, allowing users to deal with the failure quickly.

[0004] In this regard, a system has been disclosed that can reduce the waste of resources in the time-series database of the monitoring platform and reduce the cost of monitoring by the operations manager (see Patent Document 1). According to this system, for each monitoring target, a change proposal for setting information including time information is generated based on the current setting information of the time-series database, the operation history of the time-series data, and information on the amount of time-series data, so that the amount of time-series data stored in the time-series database can be reduced. [Prior art documents] [Patent documents]

[0005] [Patent Document 1] Patent No. 6029951 Summary of the Invention [Problem to be solved by the invention]

[0006] When restricting the metrics acquired for troubleshooting, the metrics required by each user are different, and the technology described in Patent Document 1 makes it impossible to determine the criteria on which the metrics should be selected. As a result, it is impossible to effectively reduce the amount of data.

[0007] The present invention has been made in consideration of the above points, and aims to propose a monitoring system etc. that can give priority to acquiring metrics that are necessary for the user. [Means for solving the problem]

[0008] In order to solve this problem, the present invention comprises an agent host that acquires metrics of a monitored object, a manager host that manages the metrics acquired by the agent host, and a memory unit that stores operation history indicating that the metrics acquired by the agent host have been sent by the manager host to a user terminal for fault investigation, and when a fault investigation is conducted by a specified user for a specified fault, the manager host extracts operation history for a specified period since the occurrence of a fault of a metric classification that matches the metric classification indicating the specified fault from the operation history of the specified user stored in the memory unit, counts the extracted operation history for each metric classification, determines a priority of the metrics acquired by the agent host based on the number of operation history of the metric classification that matches the metric classification, and requests metrics from the agent host in accordance with the determined priority, the agent host transmits the metrics to the manager host in response to the request from the manager host, and the manager host transmits the metrics transmitted from the agent host to the user terminal of the specified user.

[0009] According to the above configuration, for example, metrics based on operation history that reflects past experience are preferentially acquired, and the amount of data is reduced, so that a response to a failure can be made sooner. Effect of the Invention

[0010] According to the present invention, a monitoring system with high maintainability can be realized. Problems, configurations, and effects other than those described above will become apparent from the following description of the embodiments. [Brief description of the drawings]

[0011] [Figure 1] FIG. 1 illustrates an example of a monitoring system according to a first embodiment. [Diagram 2] FIG. 2 illustrates an example of a functional configuration of a manager host according to the first embodiment; [Diagram 3] FIG. 2 illustrates an example of a functional configuration of an agent host according to the first embodiment. [Figure 4] FIG. 2 illustrates an example of the hardware configuration of a manager host and an agent host according to the first embodiment. [Diagram 5] FIG. 4 is a diagram showing an example of an operation history according to the first embodiment. [Figure 6] FIG. 4 is a diagram illustrating an example of fault information according to the first exemplary embodiment. [Figure 7] FIG. 4 is a diagram showing an example of priority information according to the first embodiment. [Figure 8] FIG. 4 is a diagram illustrating an example of metrics information according to the first exemplary embodiment. [Figure 9] FIG. 2 is a diagram illustrating an example of metrics transmission information according to the first embodiment. [Figure 10] FIG. 11 is a diagram illustrating an example of metrics temporary storage information according to the first exemplary embodiment. [Figure 11] FIG. 11 is a diagram showing an example of a sequence related to a manager according to the first embodiment. [Figure 12] FIG. 11 is a diagram showing an example of a sequence related to a manager according to the first embodiment. [Figure 13] FIG. 4 is a diagram illustrating an example of a process executed by a priority evaluation unit according to the first embodiment; [Figure 14] FIG. 11 is a diagram illustrating an example of an operation history acquisition process (with the same name) according to the first embodiment. [Figure 15] FIG. 11 is a diagram illustrating an example of an operation history acquisition process (same type and same system) according to the first embodiment. [Figure 16] FIG. 4 is a diagram illustrating an example of a priority setting process according to the first embodiment. [Figure 17] FIG. 4 is a diagram illustrating an example of a process executed by an information collecting unit according to the first embodiment; [Figure 18] FIG. 11 is a diagram illustrating an example of a metrics transmission information generation process according to the first embodiment. [Figure 19] FIG. 4 is a diagram showing an example of a sequence related to an agent according to the first embodiment. [Figure 20] FIG. 2 is a diagram illustrating an example of processing executed by a metrics transmission information processing unit according to the first embodiment; DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0012] (I) First embodiment An embodiment of the present invention will be described in detail below, however, the present invention is not limited to the embodiment.

[0013] The monitoring system of this embodiment is a system including a manager and an agent. Each of the manager and the agent is provided in a specific host (physical machine or virtual machine). In the monitoring system, the agent collects data of the monitored object, and the manager manages the data of the monitored object collected by the agent. The monitored object may be the physical resource (CPU (Central Processing Unit), memory, etc.) of the host in which the agent is provided (agent host), or may be the virtual resource (virtual CPU, virtual memory, etc.) of the agent host.

[0014] When a failure occurs in a monitoring target of an agent host, in the monitoring system, the manager records the operation history of the metrics referenced by the user. The user is a person who accesses the monitoring system to monitor the system. For example, the user is a system administrator, an application developer, etc. The metrics are an example of data of the monitoring target, and are, for example, performance data indicating the performance of the monitoring target and status data indicating the status of the monitoring target. The performance data may be data including one piece of numerical data indicating the performance of the monitoring target, or may be data including numerical data collected in a time series indicating the performance of the monitoring target. The data indicating the status of the monitoring target may be data including one piece of numerical data indicating the status of the monitoring target, or may be data including numerical data collected in a time series indicating the status of the monitoring target. For example, the metrics are the number of logins, the amount of requested data, etc. when the monitoring target is an application, the memory usage rate, the free memory capacity, etc. when the monitoring target is a memory, and the amount of transmitted data, the amount of received data, etc. when the monitoring target is a network.

[0015] In addition, when a user responds to a failure, in the monitoring system, the manager counts the operation history of the metrics that the user referenced during past failures for each metric classification, determines the priority of the metrics to be acquired by the agent based on the number of operation histories of metric classifications that match the classification of the metric in question, and acquires the metrics according to the determined priority.

[0016] The classification of metrics may be a combination of the component type and the metric system, or may be the metric name. The component type is the type of the monitored object, such as CPU or memory. The metric system is the performance or state of the monitored object, such as performance or capacity. For example, when the component type is memory, the metric name may be the total memory usage, swap memory usage, used memory amount, memory pages (in, out, fault), etc.

[0017] Here, when the effect of a failure spreads throughout the system over time and the metric of interest changes over time, there is a problem in that the metric of interest cannot be immediately confirmed.

[0018] In this regard, the present monitoring system determines the priority of metrics based on the time that has elapsed since the occurrence of a failure. With this configuration, metrics of interest can be obtained in advance based on the elapsed time, so that users can immediately check the metrics of their interest.

[0019] Furthermore, if metrics are acquired uniformly (for example, for each component type or for each metric system), it may not be possible to effectively reduce the amount of data.

[0020] In this regard, in the present monitoring system, for example, the metrics can be subdivided according to a combination of the component type and the metric system, and the subdivided metrics can be acquired. With this configuration, for example, the metrics acquired for fault investigation can be subdivided according to a combination of the monitored object type and the metric system, so that the amount of acquired data can be effectively reduced.

[0021] The designations "first," "second," "third," and the like in this specification are given to identify components and do not necessarily limit the number or order. Furthermore, numbers for identifying components are used in each context, and a number used in one context does not necessarily indicate the same configuration in another context. Furthermore, a component identified by a certain number is not prevented from also having the function of a component identified by another number.

[0022] Next, an embodiment of the present invention will be described based on the drawings. The following description and drawings are examples for explaining the present invention, and are omitted and simplified as appropriate for clarity of explanation. The present invention can be implemented in various other forms. Unless otherwise specified, each component may be singular or plural.

[0023] In the following description, the same elements in the drawings are given the same numbers, and descriptions are omitted as appropriate. When describing elements of the same type without distinction, the common portion (part excluding the branch number) of the reference code including the branch number is used, and when describing elements of the same type while distinguishing between them, the reference code including the branch number may be used. For example, when describing a metrics transmission table without distinction, it may be written as "metrics transmission table 900," and when describing individual metrics transmission tables while distinguishing between them, it may be written as "metrics transmission table 900-1," "metrics transmission table 900-2," and so on.

[0024] In FIG. 1, 100 generally indicates a surveillance system according to a first embodiment.

[0025] The monitoring system 100 includes a manager host 110 and one or more systems 130 each having one or more agent hosts 120. The manager host 110 is a physical machine or a virtual machine, and includes a manager 111. The agent host 120 is a physical machine or a virtual machine, and includes an agent 121. Note that in this embodiment, a case will be described as an example in which the manager host 110 and the agent host 120 are both physical machines.

[0026] In the monitoring system 100, an agent 121 collects data of a monitoring target to obtain metrics, and a manager 111 manages the metrics obtained by the agent 121. In the monitoring system 100, for example, the manager 111 outputs a confirmation screen 150 on which the metrics specified by the user 140 can be confirmed.

[0027] The user 140 is a system administrator, an infrastructure administrator, an application developer, etc. The confirmation screen 150 is displayed on a user terminal 141 of the user 140. The user terminal 141 is a personal computer, a tablet terminal, a smartphone, etc. The confirmation screen 150 is provided with a display area 151 that displays metrics, and a selection area 152 for selecting the metrics to be displayed in the display area 151. On the confirmation screen 150, the metrics selected in the selection area 152 are displayed in the display area 151 as a graph.

[0028] Here, in the selection area 152, information that can identify the metric that is being acquired with priority (in this example, "★") is displayed. For example, if the manager 111 is prioritizing acquisition of metric A, the acquisition interval for metric A will be shorter than the acquisition interval for metric C, and the number of plots of metric A displayed on the graph will be greater than the number of plots of metric C. In addition, for metrics that are not prioritized for acquisition (metrics that interest the user 140 less), data is thinned out compared to metrics that are prioritized for acquisition (metrics that interest the user 140 more).

[0029] Next, the functional configuration of the manager host 110 will be described with reference to FIG. 2, the functional configuration of the agent host 120 will be described with reference to FIG. 3, and the hardware configuration of the manager host 110 and the agent host 120 will be described with reference to FIG.

[0030] FIG. 2 is a diagram showing an example of the functional configuration of the manager host 110. As shown in FIG.

[0031] The manager host 110 manages operation history 201 , failure information 202 , priority information 203 , system configuration information 204 , and metrics information 205 .

[0032] More specifically, the manager host 110 includes an operation history recording function 210, a login processing function 220, a priority management function 230, an agent management function 240, and an output processing function 250. The operation history recording function 210 is realized, for example, by an operation history recording unit 211. The operation history recording unit 211 records information relating to an operation in which the user selected (referenced) a metric on the confirmation screen 150 when a failure occurred, as an operation history 201. The operation history 201 will be described with reference to FIG. 5.

[0033] The login processing function 220 is realized, for example, by a login processing unit 221. The login processing unit 221 performs processing related to the login of the user 140. For example, when the user 140 logs in to the monitoring system 100, when the user 140 selects a metric that he or she wishes to check, the login processing unit 221 notifies the priority management function 230 of login information (user ID, login time, etc.).

[0034] The priority management function 230 is realized by, for example, a priority evaluation unit 231 and a priority recording unit 232. The priority evaluation unit 231 determines a metrics priority indicating the degree (rank) at which the manager 111 preferentially acquires metrics based on the operation history 201, the fault information 202, and the system configuration information 204. The priority recording unit 232 records information indicating the metrics priority determined by the priority evaluation unit 231 as priority information 203. The fault information 202 will be described with reference to FIG. 6. The priority information 203 will be described with reference to FIG. 7. The system configuration information 204 is information that makes it possible to grasp the configuration of the system 130, and is information indicating the connection relationship of the agent host 120. The system configuration information 204 is acquired and registered by a known technique, or is registered by the user 140.

[0035] The agent management function 240 is realized by, for example, a priority acquisition unit 241, an information collection unit 242, and an information storage unit 243. The priority acquisition unit 241 acquires priority information 203. The information collection unit 242 requests and acquires (collects) metrics from the agent 121. More specifically, the information collection unit 242 generates metrics transmission information indicating an interval for transmitting metrics for each agent 121 (agent host 120) based on the priority information 203 and the system configuration information 204, and transmits the generated metrics transmission information to the agent 121. The agent 121 transmits metrics to the information collection unit 242 in accordance with the metrics transmission information. The information storage unit 243 stores the metrics collected by the information collection unit 242 as metrics information 205. The metrics information 205 will be described with reference to FIG. 8.

[0036] The output processing function 250 is realized, for example, by an output processing unit 251. The output processing unit 251 provides a GUI (Graphical User Interface) 260 that is used by the user 140 to monitor the system 130. For example, the output processing unit 251 reads out metrics from the metrics information 205, and outputs a confirmation screen 150 including the read out metrics.

[0037] FIG. 3 is a diagram showing an example of the functional configuration of the agent host 120. As shown in FIG.

[0038] The agent host 120 manages metrics transmission information 301 and metrics temporary storage information 302. More specifically, the agent host 120 comprises a metrics transmission information processing function 310, a metrics collection function 320, a metrics temporary storage function 330, and a metrics transmission function340.

[0039] The metrics transmission information processing function 310 is realized by, for example, a metrics transmission information receiving unit 311 and a metrics transmission information processing unit 312. The metrics transmission information receiving unit 311 receives metrics transmission information transmitted from the manager 111, and records the received metrics transmission information as metrics transmission information 301. The metrics transmission information 301 will be described with reference to Fig. 9. The metrics transmission information processing unit 312 notifies the metrics temporary storage function 330 of the metrics collected by the metrics collection function 320, extracts (selects) metrics from the metrics collected by the metrics collection function 320 based on the metrics transmission information 301, and notifies the metrics transmission function 340 of the extracted metrics.

[0040] The metrics collection function 320 is realized, for example, by a metrics collection unit 321. The metrics collection unit 321 collects data of the monitoring target (monitoring target data 303) and notifies the collected monitoring target data 303 as metrics to the metrics transmission information processing unit 312. The metrics temporary storage function 330 is realized, for example, by a metrics temporary storage unit 331. The metrics temporary storage unit 331 temporarily stores the metrics notified by the metrics transmission information processing unit 312 as metrics temporary storage information 302. The metrics temporary storage information 302 will be described with reference to FIG. 10. The metrics transmission function 340 is realized, for example, by a metrics transmission unit 341. The metrics transmission unit 341 transmits the metrics notified by the metrics transmission information processing unit 312 to the manager 111.

[0041] FIG. 4 is a diagram showing an example of the hardware configuration of the manager host 110 and the agent host 120. As shown in FIG.

[0042] The manager host 110 and the agent host 120 are connected to each other via a network 400 so as to be able to communicate with each other.

[0043] The manager host 110 comprises, as components, a processor 411, a main memory device 412, an auxiliary memory device 413, an input device 414, an output device 415, and a communication device 416.

[0044] The processor 411 is a device that performs arithmetic processing. The processor 411 is, for example, a CPU, a micro processing unit (MPU), a graphics processing unit (GPU), an artificial intelligence (AI) chip, or the like.

[0045] The main memory device 412 is a device that stores information such as programs and data. The main memory device 412 is, for example, a read only memory (ROM), a random access memory (RAM), etc. The ROM is, for example, a static random access memory (SRAM), a non-volatile RAM (NVRAM), a mask read only memory (mask ROM), a programmable ROM (PROM), etc. The RAM is, for example, a dynamic random access memory (DRAM), etc.

[0046] The auxiliary storage device 413 is a device that stores information such as programs and data. For example, the auxiliary storage device 413 stores the failure information 202, the priority information 203, the system configuration information 204, and the metrics information 205. The auxiliary storage device 413 is a hard disk drive, a flash memory, a solid state drive (SSD), an optical storage device, etc. The optical storage device is a compact disc (CD), a digital versatile disc (DVD), etc. The programs, data, etc. stored in the auxiliary storage device 413 are read into the main storage device 412 as needed.

[0047] The input device 414 is a user interface that accepts information from a user. The input device 414 is, for example, a keyboard, a mouse, a card reader, a touch panel, or the like.

[0048] The output device 415 is a user interface that outputs various types of information (display output, audio output, print output, etc.). The output device 415 is, for example, a display device that visualizes various types of information, an audio output device (speaker), a printer, etc. The display device is an LCD (Liquid Crystal Display), a graphics card, etc.

[0049] The communication device 416 is a communication interface that communicates with other devices via a communication medium. The communication device 416 is, for example, a network interface card (NIC), a wireless communication module, a universal serial bus (USB) module, a serial communication module, etc. The communication device 416 can also function as an input device that receives information from other devices that are communicatively connected. The communication device 416 can also function as an output device that transmits information to other devices that are communicatively connected.

[0050] The functions of the manager host 110 (operation history recording function 210, login processing function 220, priority management function 230, agent management function 240, output processing function 250, etc.) may be realized, for example, by the processor 411 reading a program stored in the auxiliary storage device 413 into the main storage device 412 and executing it (software), or may be realized by hardware such as a dedicated circuit, or may be realized by a combination of software and hardware. Note that one function of the manager host 110 may be divided into multiple functions, or multiple functions may be integrated into one function. Also, some of the functions of the manager host 110 may be provided as a separate function, or may be included in another function. Also, some of the functions of the manager host 110 may be realized by another computer that can communicate with the manager host 110. Also, in addition to the above functions, the manager host 110 may further include functions such as an operating system, a device driver, a file system, and a DBMS (DataBase Management System).

[0051] The agent host 120 comprises, as its components, a processor 421, a main memory device 422, an auxiliary memory device 423, an input device 424, an output device 425, and a communication device 426. The components of the agent host 120 are similar to the components of the manager host 110, so the following mainly describes the different configurations.

[0052] For example, the auxiliary storage device 423 stores metrics transmission information 301 and metrics temporary storage information 302 .

[0053] Furthermore, the functions of the agent host 120 (metrics transmission information processing function 310, metrics collection function 320, metrics temporary storage function 330, metrics transmission function 340, etc.) may be realized, for example, by the processor 421 reading a program stored in the auxiliary storage device 423 into the main storage device 422 and executing it (software), or may be realized by hardware such as a dedicated circuit, or may be realized by a combination of software and hardware. Note that one function of the agent host 120 may be divided into multiple functions, or multiple functions may be integrated into one function. Also, some of the functions of the agent host 120 may be provided as a separate function, or may be included in another function. Also, some of the functions of the agent host 120 may be realized by another computer capable of communicating with the agent host 120. Also, in addition to the above functions, the agent host 120 may further include functions such as an operating system, a device driver, a file system, and a DBMS.

[0054] FIG. 5 is a diagram showing an example of the operation history 201 (operation history table 500).

[0055] The operation history table 500 is provided for each user 140, and stores information related to metrics operations by the user 140. The information related to metrics operations is, for example, information indicating that metrics acquired by the agent host 120 have been transmitted by the manager host 110 to the user terminal 141 of the user 140 for failure investigation. More specifically, the operation history table 500 stores records in which information on date and time 501, host name 502, metrics name 503, component type 504, and metrics system 505 are associated with each other.

[0056] The date and time 501 stores information indicating the date and time when the metrics were operated by the user 140 via the confirmation screen 150 or the like. The host name 502 stores information indicating the name (host name) of the agent host 120 that includes the component from which the metrics were acquired. The metrics name 503 stores information indicating the name of the metrics (metrics name). The component type 504 stores information indicating the type of the component. The metrics lineage 505 stores information indicating the lineage of the metrics.

[0057] FIG. 6 is a diagram showing an example of the fault information 202 (fault table 600).

[0058] The fault table 600 is provided for each system 130, and stores information related to an event (e.g., a fault) that has occurred in the agent host 120. More specifically, the fault table 600 stores records in which the following information is associated: date and time 601, event content 602, host name 603, metrics name 604, metrics status 605, component type 606, and metrics system 607.

[0059] Date and time 601 stores information indicating the date and time when the event occurred. Event content 602 stores information indicating the content of the event. Host name 603 stores information indicating the name of the agent host 120 where the event occurred. Metrics name 604 stores information indicating the name of the metrics indicating the event (the name of the metrics related to the event). Metrics status 605 stores information indicating the status of the metrics. Component type 606 stores information indicating the type of component from which the metrics was obtained. Metrics lineage 607 stores information indicating the lineage of the metrics.

[0060] FIG. 7 is a diagram showing an example of the priority information 203 (priority table 700).

[0061] The priority table 700 is provided for each user 140, and stores information related to metrics priority determined by the priority evaluation unit 231. More specifically, the priority table 700 stores records in which information on priority 701, number of hops 702, metrics name 703, component type 704, metrics system 705, and number of views 706 are associated with each other.

[0062] Priority 701 stores information indicating metrics priority indicating the order in which metrics are preferentially acquired. Number of hops 702 stores information indicating the number of components (number of hops) configured between the agent host 120 having the component from which the metrics is acquired and the agent host 120 in which a failure has occurred. Metrics name 703 stores information indicating the name of the metrics. Component type 704 stores information indicating the type of the component. Metrics lineage 705 stores information indicating the lineage of the metrics. Number of views 706 stores information indicating the number of times the metrics has been displayed (operated).

[0063] For example, when the system configuration of the system 130 "α" is the system configuration 710, when a failure occurs in the host E711, the hop count of the host E711 is "-1". Also, for example, since there is no component in the shortest communication path between the host E711 and the host G712, the hop count of the host G712 is "0". Also, for example, since there is one component (host C714 or host G712) in the shortest communication path between the host E711 and the host F713, the hop count of the host F713 is "1".

[0064] FIG. 8 is a diagram showing an example of the metrics information 205 (metrics table 800).

[0065] The metrics table 800 stores metrics acquired by the manager 111. More specifically, the metrics table 800 stores records in which the following information is associated: metrics name 801, component type 802, metrics system 803, host name 804, collection time 805, and metrics value 806.

[0066] The metrics name 801 stores information indicating the name of the metrics acquired by the manager 111. The component type 802 stores information indicating the type of the component from which the metrics were acquired. The metrics lineage 803 stores information indicating the lineage of the metrics. The host name 804 stores information indicating the name of the agent host 120 that includes the component from which the metrics were acquired. The collection time 805 stores information indicating the time when the metrics were acquired. The metrics value 806 stores information indicating the value of the metrics.

[0067] FIG. 9 is a diagram showing an example of the metrics transmission information 301 (metrics transmission table 900).

[0068] The metrics transmission table 900 stores information related to the transmission of metrics. More specifically, the metrics transmission table 900 stores records in which the following information is associated: a priority rank 901, a hop count 902, a metrics name 903, a component type 904, a metrics system 905, and a display count 906.

[0069] The priority rank 901 stores information indicating a rank of the metrics priority (priority rank). In the monitoring system 100, a transmission interval for transmitting the metrics is set corresponding to the priority rank. For example, the priority rank "A" indicates that the metrics transmission interval is 15 seconds, the priority rank "B" indicates that the metrics transmission interval is 1 minute, the priority rank "C" indicates that the metrics transmission interval is 15 minutes, and the priority rank "D" indicates that the metrics transmission interval is 30 minutes. The priority rank is determined based on the metrics priority in the metrics transmission information generation process described later. The hop count 902 stores information indicating the number of components (hop count) configured between the agent host 120 having the component from which the metrics is acquired and the agent host 120 in which a failure has occurred. The metrics name 903 stores information indicating the name of the metrics. The component type 904 stores information indicating the type of the component from which the metrics is acquired. The metrics lineage 905 stores information indicating the lineage of the metrics. The number of times displayed 906 stores information indicating the number of times the metrics has been displayed (operated).

[0070] The metrics transmission table 900-1 shows an example of metrics transmission information 301 registered in an agent host 120 with a hop count of "-1" (an agent host 120 where a failure has occurred). Also, the metrics transmission table 900-2 shows an example of metrics transmission information registered in an agent host 120 with a hop count of "0".

[0071] FIG. 10 is a diagram showing an example of the metrics temporary storage information 302 (metrics temporary storage table 1000).

[0072] The metrics temporary storage table 1000 stores information related to metrics collected by the agent host 120. More specifically, the metrics temporary storage table 1000 stores records in which the following information is associated: metrics name 1001, component type 1002, metrics system 1003, host name 1004, collection time 1005, and metrics value 1006.

[0073] The metrics name 1001 stores information indicating the name of the metrics collected by the agent host 120. The component type 1002 stores information indicating the type of component from which the metrics were collected. The metrics lineage 1003 stores information indicating the lineage of the metrics. The host name 1004 stores information indicating the name of the agent host 120 from which the metrics were collected. The collection time 1005 stores information indicating the time when the metrics were collected. The metrics value 1006 stores information indicating the value of the metrics.

[0074] 11 and 12 are diagrams showing an example of a sequence illustrating a series of processes executed by the manager 111. FIG.

[0075] In S1101, the user 140 performs a predetermined operation (an operation related to login or an operation of pressing a priority recalculation button) via the GUI 260. In this embodiment, the user 140 logs into the monitoring system 100 via the GUI 260, whereby metrics based on past experience are acquired in advance, and the user 140 can investigate the oldest failure that has occurred since the previous logout. Also, in this embodiment, the manager 111 provides the user terminal 141 of the user 140 with the GUI 260 (for example, a screen) that allows the user 140 to specify a failure for which investigation is to be performed. After logging in, the user 140 selects a desired failure via the GUI 260 and presses a priority recalculation button, whereby metrics based on past experience are acquired in advance, and the user 140 can investigate the desired failure.

[0076] In S1102, when a predetermined operation is performed by the user 140, the login processing unit 221 provides the priority evaluation unit 231 with login information including the login time. In addition, when the predetermined operation is an operation of pressing the priority recalculation button, the predetermined operation is an operation performed after logging in to the system 130, so that the login processing unit 221 provides the priority evaluation unit 231 with login information including the login time of the login.

[0077] In S1103, upon receiving the login information, the priority evaluation part 231 notifies the login processing part 221 of information indicating that the login information has been received (a return value indicating completion of processing).

[0078] In S1104, the priority evaluation unit 231 acquires the fault information of the fault to be investigated (fault information of the investigated fault) from the fault information 202. If the predetermined operation is an operation related to login, the investigated fault is the oldest fault among the fault information of faults that occurred after the previous logout. Also, if the predetermined operation is an operation of pressing the priority recalculation button, the investigated fault is the fault selected by the user 140.

[0079] In S1105, the priority evaluation unit 231 calculates the failure elapsed time, which indicates the time from when the investigation failure occurred to when the login was made, from the time of the failure information of the investigation failure acquired in S1104 (time of failure occurrence) and the login time received in S1102.

[0080] In S1106, the priority evaluation unit 231 searches the fault information 202 for faults (past faults) with a metrics classification that matches the metric classification (metric name, or combination of component type and metric system) of the investigated fault, and obtains fault information of the past faults.

[0081] In S1107, the priority evaluation unit 231 acquires operation history of past failures for the failure elapsed time from the operation history 201. For example, if the failure elapsed time is "30 minutes" and the past failure is "a failure indicated by metric A of host A at 10:00 on Dec. 1, 2022," the priority evaluation unit 231 acquires 22 records from the operation history table 500, whose dates and times 501 are from 10:00 on Dec. 1, 2022 to 10:30 on Dec. 1, 2022.

[0082] In S1108, the priority evaluation unit 231 acquires, from the system configuration information 204, the system configuration information of the system 130 in which a failure has occurred in the past.

[0083] In S1109, the priority evaluation unit 231 determines the metrics priority based on the operation history of the past failure acquired in S1107 and the system configuration information 204 acquired in S1108.

[0084] In S 1110 , the priority recording unit 232 records the metrics priority determined by the priority evaluation unit 231 as the priority information 203 .

[0085] In S1200, the agent host 120 repeatedly acquires the monitoring target data 303 (metrics) from the monitoring target.

[0086] In S 1201 , the priority acquisition unit 241 acquires the priority information of the user 140 from the priority information 203 .

[0087] In S1202, the information collection unit 242 acquires, from the system configuration information 204, the system configuration information of the system 130 in which the investigation failure has occurred.

[0088] In S1203, the information collection unit 242 generates (shapes) metrics transmission information based on the priority information acquired in S1201 and the system configuration information acquired in S1202.

[0089] In S1204, the information collection unit 242 transmits the metrics transmission information generated in S1203 to the agent host 120.

[0090] In S1205, the agent host 120 receives the metrics transmission information, and transmits (returns) the metrics to the manager 111 in accordance with the received metrics transmission information.

[0091] In S1206, the information collection unit 242 receives the metrics and notifies the information storage unit 243 of the received metrics, and the information storage unit 243 stores the received metrics as the metrics information 205.

[0092] In S1207, the output processing unit 251 acquires the selected metrics from the metrics information 205 based on the information indicating that the metrics have been selected by the user 140.

[0093] In S1208, the output processing unit 251 outputs the metrics acquired in S1207 as a confirmation screen 150 that the user 140 can confirm.

[0094] FIG. 13 is a diagram showing an example of the process (the process relating to S1103 to S1109) executed by the priority evaluation unit 231.

[0095] In S1301, the priority evaluation unit 231 judges whether or not login information has been received (whether or not the operation is related to login) from the login processing unit 221. If the priority evaluation unit 231 judges that the login information has been received, it shifts the process to S1304, and if it judges that the login information has not been received, it shifts the process to S1302.

[0096] In S1302, the priority evaluation unit 231 requests login information from the login processing unit 221. For example, when the predetermined operation is an operation of pressing a priority recalculation button, the priority evaluation unit 231 requests the login processing unit 221 for login information including the login time of the login, since the operation is an operation performed after logging in to the system 130.

[0097] In S1303 , the priority evaluation unit 231 acquires the login information from the login processing unit 221 .

[0098] In S1304, the priority evaluation unit 231 judges whether an error event or a warning event exists (whether a fault occurs) and whether an error event or a warning event has been selected (whether a fault is selected). If the priority evaluation unit 231 judges that a fault occurs or a fault is selected, the process proceeds to S1306, and if it judges that neither a fault occurs nor a fault is selected, the process proceeds to S1305.

[0099] In S1305, the priority evaluation unit 231 sets the default priority as the metrics priority.

[0100] In S1306, the priority evaluation unit 231 acquires the trouble information of the investigated trouble from the trouble information 202. For example, when the predetermined operation is an operation related to login, the priority evaluation unit 231 acquires the trouble information of the oldest trouble among the trouble information of the troubles that occurred after the previous logout, and when the predetermined operation is an operation of pressing the priority recalculation button, the priority evaluation unit 231 acquires the trouble information of the trouble selected by the user 140.

[0101] In S1307, the priority evaluation unit 231 calculates the failure elapsed time (failure elapsed time=login time-failure occurrence time) from the time (failure occurrence time) of the failure information of the investigated failure and the login time of the login information.

[0102] In S1308, the priority evaluation unit 231 sets the metrics priority of the metrics of the monitoring target that is the occurrence source of the investigated failure (occurrence source metrics) to "1."

[0103] In S1309, the priority evaluation unit 231 sets the metrics priorities of the metrics (post-problem metrics) that became errors or warnings after the occurrence source within the fault elapsed time to "2", "3", ... in the order of occurrence of the faults.

[0104] In S1310, the priority evaluation unit 231 acquires the metrics name of the manifestation source metric, the component type of the component from which the manifestation source metric is acquired, and the metrics system of the manifestation source metric from the fault information of the investigated fault.

[0105] In S1311, the priority evaluation unit 231 determines whether or not an operation history of a metric having the same name as the metric name of the origin metric exists in the operation history 201. If the priority evaluation unit 231 determines that the operation history exists, it proceeds to S1312, and if it determines that the operation history does not exist, it proceeds to S1313.

[0106] In S1312, the priority evaluation unit 231 executes an operation history acquisition process (same name), and moves the process to S1315. In the operation history acquisition process (same name), an operation history from the occurrence of a past failure with the same name as the metric name of the manifestation source metric is acquired for the failure elapsed time. The operation history acquisition process (same name) will be described with reference to FIG. 14.

[0107] In S1313, the priority evaluation unit 231 judges whether or not there is an operation history of metrics of the same type and type as the component type of the component from which the origin metrics were acquired and the metrics type of the origin metrics in the operation history 201. If the priority evaluation unit 231 judges that there is, it shifts the process to S1314, and if it judges that there is not, it shifts the process to S1305.

[0108] In S1314, the priority evaluation unit 231 executes an operation history acquisition process (same type and same system), and moves the process to S1315. In the operation history acquisition process (same type and same system), an operation history from the occurrence of a past failure of the same type and system as the component type of the component from which the manifestation metrics was acquired and the metrics system of the manifestation metrics is acquired for the time since the failure occurred. The operation history acquisition process (same type and same system) will be described with reference to FIG. 15.

[0109] In S1315, the priority evaluation unit 231 performs a priority setting process. In the priority setting process, a metrics priority is calculated and set. The priority setting process will be described with reference to FIG.

[0110] FIG. 14 is a diagram showing an example of the operation history acquisition process (same name).

[0111] In S1401, the priority evaluation unit 231 refers to the failure information 202 and determines whether there are multiple past failures of a metric with the same name as the manifestation source metric. If the priority evaluation unit 231 determines that there are multiple past failures, it moves the process to S1402, and if it determines that there are not multiple past failures (if it determines that there is only one past failure of a metric with the same name as the manifestation source metric), it moves the process to S1405.

[0112] In S1402, the priority evaluation part 231 executes the process of S1403 the number of times corresponding to the number of past failures.

[0113] In S1403, the priority evaluation unit 231 identifies fault information related to a past fault from the fault information 202, and calculates the fault duration (fault duration = (the time when the metric returned to a normal value) - (the time when the metric became an error or warning)) based on the identified fault information.

[0114] In S1404, the priority evaluation unit 231 acquires, from the operation history 201, an operation history having the shortest failure duration from the occurrence of a past failure for the failure elapsed time, and ends the operation history acquisition process (with the same name).

[0115] In S1405, the priority evaluation unit 231 acquires from the operation history 201 the operation history from the time since the occurrence of a past failure of a metric having the same name as the manifestation metric, and ends the operation history acquisition process (same name).

[0116] FIG. 15 is a diagram showing an example of the operation history acquisition process (same type and same system).

[0117] In S1501, the priority evaluation unit 231 refers to the failure information 202 and determines whether there are multiple past failures of metrics of the same type and type as the manifestation source metric. If the priority evaluation unit 231 determines that there are multiple failures, it moves the process to S1502, and if it determines that there are not multiple failures (if it determines that there is only one past failure of metrics of the same type and type as the manifestation source metric), it moves the process to S1505.

[0118] In S1502, the priority evaluation unit 231 executes the process of S1503 the number of times corresponding to the number of past failures.

[0119] In S1503, the priority evaluation unit 231 identifies fault information related to a past fault from the fault information 202, and calculates the fault duration (fault duration = (the time when the metric returned to a normal value) - (the time when the metric became an error or warning)) based on the identified fault information.

[0120] In S1504, the priority evaluation unit 231 acquires, from the operation history 201, an operation history having the shortest failure duration from the occurrence of the past failure for the failure elapsed time, and ends the operation history acquisition process (same type and same system).

[0121] In S1505, the priority evaluation unit 231 acquires from the operation history 201 the operation history since the occurrence of a past failure of a metric of the same type and type as the source metric, for the time since the failure occurred, and terminates the operation history acquisition process (same type and type).

[0122] FIG. 16 is a diagram illustrating an example of the priority setting process.

[0123] In S1601, since the priority evaluation unit 231 has set the metrics priority of the manifestation source metrics and the metrics priority of the posterior fault metrics in S1308 and S1309, it excludes the operation history of the manifestation source metrics and the operation history of the posterior fault metrics from the operation history acquired in the operation history acquisition process (same name) or operation history acquisition process (same type and same system).

[0124] In S1602, the priority evaluation unit 231 acquires, from the system configuration information 204, system configuration information of the system 130 (the system 130 in which a failure has occurred in the past) that includes the agent host 120 with the host name included in each operation history after exclusion.

[0125] In S1603, the priority evaluation unit 231 executes the processes of S1604 and S1605 the same number of times as the number of operation histories (the number of operations) after the exclusion.

[0126] In S1604, the priority evaluation unit 231 calculates the number of hops of the agent host 120 related to the operation history to be processed (the number of hops of the agent host 120 including the component from which the metrics operated by the user were obtained) based on the system configuration information acquired in S1602 and the agent host 120 from which the past failure occurred.

[0127] In S1605, the priority evaluation unit 231 adds "1" to the number of operations of the operated metric for the number of hops calculated in S1604 (number of operations = +1). In addition, the priority evaluation unit 231 manages the number of operations for each hop number and metric classification (metric name, or combination of component type and metric system).

[0128] In S1606, the priority evaluation unit 231 arranges each metric in descending order of the number of times the metric was operated, starting from the metrics for which the metric priority has been set (the excluded manifestation metrics and subsequent fault metrics), and determines the metric priority. Note that, if the number of times the metrics are operated is the same, the metrics may be arranged in ascending order (oldest first) of the operation history to determine the metric priority, or the same metric priority may be determined.

[0129] FIG. 17 is a diagram showing an example of the processing (processing relating to S1201 to S1206) executed by the information collecting unit 242. As shown in FIG.

[0130] In S1701, the information collection unit 242 receives, from the priority acquisition unit 241, the priority information 203 for all the agent hosts 120 (all agent hosts 120) included in the system 130 in which an investigation failure has occurred.

[0131] In S 1702 , the information collecting unit 242 executes the process of S 1703 the same number of times as the number of agent hosts 120 .

[0132] In S1703, the information collecting unit 242 executes a metrics transmission information generation process. In the metrics transmission information generation process, metrics transmission information is generated in which a priority rank is set for metrics that can be acquired in the processing target agent host 120 based on the priority information 203. The metrics transmission information generation process will be described with reference to FIG.

[0133] In S 1704 , the information collecting unit 242 executes the processes of S 1705 and S 1706 the same number of times as the number of agent hosts 120 .

[0134] In S1705, the information collection unit 242 distributes the metrics transmission information generated in S1703 to the agent host 120 to be processed.

[0135] In S1706, the information collection unit 242 receives metrics from the agent host 120 to be processed.

[0136] In S 1707 , the information collection unit 242 provides the metrics received from all the agent hosts 120 to the information storage unit 243 .

[0137] FIG. 18 is a diagram illustrating an example of the metrics transmission information generation process.

[0138] In S1801, the information collection unit 242 acquires, from the system configuration information 204, system configuration information of the system 130 including the agent host 120 to be processed (the system 130 in which an investigation failure has occurred).

[0139] In S1802, the information collecting unit 242 calculates the number of hops of the agent host 120 to be processed, based on the system configuration information acquired in S1801 and the agent host 120 from which the investigation failure occurred.

[0140] In S1803, the information collection unit 242 acquires, from the metrics information 205, a list of metrics that can be acquired in the agent host to be processed.

[0141] In S1804, the information collection unit 242 executes the processes of S1805 to S1811 the number of times corresponding to the number of obtainable metrics.

[0142] In S1805, the information collection unit 242 determines whether or not the category of the metrics to be processed (the relevant metrics) is included in the priority information 203. If the information collection unit 242 determines that the category is included, it proceeds to S1807, and if not, it proceeds to S1806.

[0143] In S1806, the information collection unit 242 sets (determines) the priority rank of the metrics to "D."

[0144] In S1807, the information collection unit 242 determines whether the metrics priority of the metric in the priority information 203 is within a first threshold (e.g., the top 25%). If the information collection unit 242 determines that the metric priority is within the first threshold, it proceeds to S1808, and if it determines that the metric priority is not within the first threshold (below the top 25%), it proceeds to S1809.

[0145] In S1808, the information collection unit 242 sets the priority rank of the metrics to "A."

[0146] In S1809, the information collection unit 242 judges whether the metric priority of the metric in the priority information 203 is equal to or lower than a second threshold (e.g., top 26%) and within a third threshold (e.g., top 50%) (e.g., whether it is lower than the top 50%). If the information collection unit 242 judges that it is equal to or lower than the second threshold and within the third threshold, it proceeds to S1810, and if it is lower than the third threshold, it proceeds to S1811.

[0147] In S1810, the information collection unit 242 sets the priority rank of the metrics to "B."

[0148] In S1811, the information collection unit 242 sets the priority rank of the metrics to "C."

[0149] In S1812, the information collecting unit 242 generates metrics transmission information to be distributed to the agent 121. For example, the information collecting unit 242 generates metrics transmission information including the priority rank set in S1806, S1808, S1810, or S1808 based on the metrics information of the metrics or the priority information of the metrics.

[0150] FIG. 19 is a diagram showing an example of a sequence showing a series of processes executed by the agent 121. In FIG.

[0151] In S1900, the metrics collector 321 acquires metrics (monitoring target data 303) and notifies the metrics transmission information processor 312 of the acquired metrics.

[0152] In S 1901 , the manager host 110 transmits metrics transmission information to the agent host 120 .

[0153] In S1902, the metrics transmission information receiving unit 311 receives the metrics transmission information and registers the received metrics transmission information as the metrics transmission information 301. Upon receiving a return value indicating completion of registration, the metrics transmission information receiving unit 311 transmits a return value indicating completion of transmission of the metrics transmission information to the manager host 110.

[0154] In S 1903 , the metrics transmission information processing unit 312 acquires the metrics transmission information 301 .

[0155] In S1904, the metrics transmission information processing unit 312 stores all the metrics notified by the metrics collection unit 321 in metric_map (Map variable).

[0156] In S1905, the metrics transmission information processing unit 312 provides the metrics_map to the metrics temporary storage unit 331.

[0157] In S1906, the metrics temporary save unit 331 registers metric_map as the metrics temporary save information 302, and upon receiving a return value indicating completion of the registration, notifies the metrics transmission information processing unit 312 of the return value indicating completion of the registration.

[0158] In S1907, the metrics transmission information processing unit 312 sets the value of the key "send_flag" for each element of metric_map.

[0159] In S1908, the metrics transmission information processing unit 312 stores the element in which the value of the key "send_flag" of metric_map is "true" in send_metric_map (Map variable).

[0160] In S1909 , the metrics transmission information processing unit 312 provides the metrics transmission unit 341 with send_metric_map.

[0161] In S 1910 , the metrics transmission module 341 transmits the metrics stored in the send_metric_map to the manager host 110 .

[0162] In S1911, the manager host 110 sends a return value indicating completion of the metrics reception to the metrics transmission unit 341.

[0163] FIG. 20 is a diagram showing an example of the processing (processing related to S1903 to S1909) executed by the metrics transmission information processing unit 312.

[0164] In S 2001 , the metrics transmission information processing unit 312 acquires the metrics transmission information from the metrics transmission information 301 .

[0165] In S 2002 , the metrics transmission information processing unit 312 acquires metrics from the metrics collection unit 321 .

[0166] In S2003, the metrics transmission information processing unit 312 stores all the acquired metrics in metric_map (Map type variable).

[0167] In S 2004 , the metrics transmission information processing unit 312 provides the metrics_map to the metrics temporary storage unit 331 .

[0168] In S2005, the metrics transmission information processing unit 312 executes the processes of S2006 to S2008 the same number of times as the number of metric_maps.

[0169] In S2006, the metrics transmission information processing unit 312 determines whether the time that has elapsed since the previous transmission of metrics is equal to or longer than the transmission interval (whether it is the transmission time). If the metrics transmission information processing unit 312 determines that it is the transmission time, it proceeds to S2007, and if it determines that it is not the transmission time, it proceeds to S2008. For example, the transmission interval is set in correspondence with the priority rank, as shown in the transmission interval table 2020.

[0170] In S2007, the metrics transmission information processing unit 312 sets the value of the key "send_flag" of the metric_map (metric) to be processed to "true."

[0171] In S2008, the metrics transmission information processing unit 312 sets the value of the key "send_flag" of the metric_map (metric) to be processed to "false."

[0172] In S2009, the metrics transmission information processing unit 312 executes the processes of S2010 and S2011 the same number of times as the number of metric_maps.

[0173] In S2010, the metrics transmission information processing unit 312 judges whether the key "send_flag" is "true". If the metrics transmission information processing unit 312 judges that the key is "true", the process proceeds to S2011, and if the key is not "true", the process proceeds to the next metric_map and the judgment of S2010 is performed.

[0174] In S2011, the metrics transmission information processing unit 312 stores the metrics in send_metric_map (Map variable).

[0175] In S2012, the metrics transmission information processing unit 312 provides the metrics transmission unit 341 with send_metric_map.

[0176] For example, when agent host 120 "A" obtains metrics transmission information 2030, if the priority rank and transmission interval are as shown in table 2020, agent host 120 "A" will transmit metric A to manager host 110 at 15 second intervals, metric B at 15 minute intervals, and other metrics at 30 minute intervals.

[0177] According to this embodiment, the metrics acquired for each user are dynamically changed over time, making it possible to reduce the amount of data.

[0178] (II) Supplementary Note The above-described embodiment includes, for example, the following contents.

[0179] In the above embodiment, the present invention is described as being applied to a monitoring system, but the present invention is not limited to this and can be widely applied to various other systems, devices, methods, and programs.

[0180] In the above embodiment, the present invention is not limited to the case where the present invention is applied to a plurality of systems. For example, the present invention may be applied to a single system. In this case, the process related to the number of hops may be performed or may not be performed.

[0181] In the above embodiment, the priority rank is set according to the metrics priority, but the present invention is not limited to this. For example, the transmission interval may be defined according to the metrics priority without providing the priority rank.

[0182] In the above embodiment, the metrics are classified by a combination of the metrics name, the component type, and the metrics system, but the present invention is not limited to this. For example, the metrics may be classified by the metrics name, a combination of the component type and the metrics system, the component type, or the metrics system.

[0183] In the above embodiment, the metrics priority is determined for each user, but the present invention is not limited to this. For example, the metrics priority of a first user (e.g., an expert) may be applied to a second user (e.g., a beginner).

[0184] In the above embodiment, the case where there are multiple agent hosts has been described, but the present invention is not limited to this. For example, there may be only one agent host.

[0185] Also, in the above embodiment, the case where metrics are acquired with priority has been described. Prioritizing acquisition of metrics is not limited to a configuration in which the higher the priority, the shorter the metric acquisition interval is. For example, the configuration may be such that metrics are acquired when the priority is greater than a predetermined value, or the higher the priority, the shorter the metric acquisition interval is, when the priority is greater than a predetermined value, or other configurations may be used.

[0186] Also, in the above-described embodiment, some or all of the programs may be installed from a program source into a device such as a computer that realizes the monitoring system 100. The program source may be, for example, a program distribution server connected via a network or a computer-readable recording medium (for example, a non-transitory recording medium). Also, in the above description, two or more programs may be realized as one program, and one program may be realized as two or more programs.

[0187] Furthermore, in the above-described embodiments, the configuration of each table is an example, and one table may be divided into two or more tables, or all or part of two or more tables may be one table.

[0188] In the above embodiment, for convenience of explanation, the information related to the monitoring system is explained using a table, but the data structure is not limited to a table. The information related to the monitoring system may be expressed by a data structure other than a table, such as XML (Extensible Markup Language), YAML (YAML Ain't a Markup Language), a hash table, a tree structure, etc.

[0189] Furthermore, the screens shown and described in the above embodiment are merely examples, and any design may be used as long as the information received is the same.

[0190] Furthermore, the screens shown and described in the above embodiment are merely examples, and any design may be used as long as the information presented is the same.

[0191] In the above-described embodiment, the output of information is not limited to display on a display. The output of information may be audio output from a speaker, output to a file, printing on a paper medium or the like by a printing device, projection on a screen or the like by a projector, or other form.

[0192] In addition, in the above description, information such as programs, tables, files, etc. that realize each function can be placed in a storage device such as a memory, a hard disk, or an SSD (Solid State Drive), or in a recording medium such as an IC card, an SD card, or a DVD.

[0193] The above-described embodiment has the following characteristic configurations, for example.

[0194] (1) The system comprises an agent host (e.g., the agent host 120) that acquires metrics (numerical data collected in a time series indicating the performance of the monitored object, numerical data collected in a time series indicating the state of the monitored object, etc.) of a monitored object (a component of the agent host 120, a processor 421, a main memory device 422, an auxiliary memory device 423, an input device 424, an output device 425, a communication device 426, etc.), a manager host (e.g., the manager host 110) that manages the metrics acquired by the agent host, and a storage unit (the auxiliary memory device 423, a storage device capable of communicating with the manager host 110, etc.) that stores an operation history (e.g., an operation history 201, an operation history table 500) indicating that the metrics acquired by the agent host have been transmitted by the manager host to a user terminal (e.g., the user terminal 141) for failure investigation, and When a fault investigation is performed on a specific user's operation history (such as a fault), the manager host extracts operation history for a specific period (elapsed time since the occurrence of the fault, a preset period, etc.) from the operation history of the specific user stored in the storage unit, which has a metrics classification that matches the metrics classification (a combination of component type and metrics system, metrics name, etc.) that indicated the specific fault, counts the extracted operation history for each metric classification, determines a priority of the metrics (metrics priority, priority rank, etc.) to be acquired by the agent host based on the number of operation histories of the metric classification that matches the metric classification, requests metrics from the agent host in accordance with the determined priority (for example, sends metrics transmission information), the agent host transmits the metrics to the manager host in response to the request from the manager host, and the manager host transmits the metrics transmitted from the agent host to the user terminal of the specific user.

[0195] According to the above configuration, for example, metrics based on operation history that reflects past experience are preferentially acquired, and the amount of data is reduced, so that a response to a failure can be made sooner.

[0196] (2) The manager host calculates the specified period as the elapsed time from when the specified failure occurs to when the specified user logs in (e.g., the failure elapsed time) (e.g., see S1307), and extracts, from the operation history of the specified user stored in the memory unit, the operation history for the elapsed time since the occurrence of a failure of a metric classification that matches the metric classification indicating the specified failure.

[0197] According to the above configuration, for example, the priority of metrics is determined based on operation history over an elapsed time, so that the user can immediately check the metrics required for initial response while limiting the metrics obtained for troubleshooting.

[0198] (3) The manager host extracts, from the operation history of the specified user stored in the memory unit, operation history for a specified period since the occurrence of a failure of a type of monitored object and a metric system that matches the type of monitored object (e.g., component type) and the system of the metrics (e.g., metrics system) from which the metrics indicating the specified failure was acquired (see, for example, Figure 15), counts the extracted operation history for each type of monitored object and each system of metrics, determines the priority of the metrics to be acquired by the agent host based on the number of operation histories of the type of monitored object and the metric system from which the metrics were acquired and the system of the metrics that matches, and requests the metrics from the agent host in accordance with the determined priority.

[0199] According to the above configuration, for example, the metrics acquired for fault investigation can be subdivided into combinations of the type of monitored object and the metric system, thereby further reducing the amount of acquired data.

[0200] (4) The manager host manages metrics acquired by each of a plurality of agent hosts included in a first system and metrics acquired by each of a plurality of agent hosts included in a second system different from the first system (for example, see FIG. 1 ). When the metrics acquired by a first agent host in the first system indicate a first failure and a failure investigation is carried out by a predetermined user regarding the first failure, the manager host extracts operation history for a predetermined period of time since the occurrence of a second failure of a metric classification matching the metric classification of the first failure from the operation history of the predetermined user stored in the storage unit (for example, see S1312 and S1314). When the system including the second agent host in which the second failure has occurred is the second system, the manager host calculates the number of components configured between the second agent host and other agent hosts in the second system. The number of hops which is the number of hops between the first agent host and another agent host of the first system is calculated based on the configuration information of the second system (see S1604, for example), the operation history for the specified period is counted for each metric classification and hop number (see S1605, for example), the priority of the metrics related to the operation history for the specified period is determined in accordance with the number of operation history for the metric classification and hop number which match the metric classification and the hop number of the agent host which acquires the metric (see S1606, for example), the number of hops which is the number of components configured between the first agent host and another agent host of the first system is calculated based on the configuration information of the first system (see S1802, for example), and the priority (priority rank, transmission interval, etc.) of the metrics to be transmitted to each of the multiple agent hosts included in the first system is determined in accordance with the priority of the metrics which match the metric classification and the hop number of the agent host which acquires the metric.

[0201] According to the above configuration, even if, for example, the system in which a fault has occurred and the system in which the fault is being investigated are different from the system in which the operation history for determining the priority is extracted, it is possible to determine the priority of the metrics to be obtained for the fault investigation.

[0202] (5) The memory unit stores fault information (fault information 202, fault table 600, etc.) including information indicating a metric classification indicating a fault, information on the date and time when the fault occurred, and information on the date and time when the fault was recovered from. If there are multiple faults of a metric classification that matches the metric classification indicating the specified fault, the manager host calculates a fault duration indicating the time the fault continued for each of the multiple faults based on the fault information stored in the memory unit (see S1403, S1503, etc.), identifies one fault with the shortest calculated fault duration from among the multiple faults, and extracts operation history for a specified period since the occurrence of the one fault from the operation history of the specified user stored in the memory unit (see S1404, S1504, etc.).

[0203] According to the above configuration, for example, the priority of the metrics is determined based on the operation history related to the failure with the shortest failure duration, so that the failure can be dealt with more quickly.

[0204] (6) The manager host sets the interval for transmitting metrics to be shorter the higher the determined priority (see S1804 to S1811, etc.), and requests the agent host to transmit metrics at the set interval.

[0205] According to the above configuration, for example, metrics with low priority are acquired at longer intervals, so that the amount of data can be appropriately reduced.

[0206] (7) The manager host provides a screen (e.g., GUI 260) on the user terminal of the user on which the user can specify a fault for which an investigation is to be performed, and when a specific fault is specified by a specific user via the screen, the manager host extracts operation history for a specific period of time since the occurrence of a fault of a metric classification that matches the metric classification indicating the specific fault specified by the specific user from the operation history of the specific user stored in the memory unit, counts the extracted operation history for each metric classification, determines the priority of the metrics to be acquired by the agent host based on the number of operation histories of the metric classification that matches the metric classification, and requests metrics from the agent host in accordance with the determined priority.

[0207] According to the above configuration, for example, a user can carry out a fault investigation on a desired fault.

[0208] Furthermore, the above-described configurations may be modified, rearranged, combined, or omitted as appropriate without departing from the spirit and scope of the present invention.

[0209] It should be understood that items listed in the format "at least one of A, B, and C" can mean (A), (B), (C), (A and B), (A and C), (B and C), or (A, B, and C). Similarly, items listed in the format "at least one of A, B, or C" can mean (A), (B), (C), (A and B), (A and C), (B and C), or (A, B, and C). [Explanation of symbols]

[0210] 100...monitoring system, 110...manager host, 120...agent host.

Claims

1. An agent host that obtains the metrics of the monitored object; a manager host that manages the metrics acquired by the agent host; a storage unit that stores an operation history indicating that the metrics acquired by the agent host have been transmitted by the manager host to a user terminal for fault investigation; Equipped with When a specific user performs a troubleshooting investigation on a specific problem, the manager host extracts operation history for a predetermined period from the occurrence of a failure of a metrics classification that matches the metrics classification indicating the predetermined failure from among the operation history of the predetermined user stored in the storage unit, counts the extracted operation history for each metric classification, determines a priority of the metrics to be acquired by the agent host based on the number of operation histories of the metric classification that matches the metric classification, and requests metrics from the agent host in accordance with the determined priority; the agent host transmits metrics to the manager host in response to a request by the manager host; The manager host transmits the metrics transmitted from the agent host to a user terminal of the predetermined user. Surveillance system.

2. the manager host calculates, as the predetermined period, the elapsed time from the occurrence of the predetermined failure to the login of the predetermined user, and extracts, from the operation history of the predetermined user stored in the storage unit, an operation history for the elapsed time from the occurrence of a failure of a metric classification that matches the metric classification indicating the predetermined failure; The monitoring system of claim 1 .

3. the manager host extracts, from the operation history of the specified user stored in the storage unit, operation history for a specified period since the occurrence of a failure of a type of monitoring target and a type of metrics system that match the type of monitoring target for which metrics indicating the specified failure were acquired, counts the extracted operation history for each type of monitoring target and each type of metrics system, determines a priority of the metrics to be acquired by the agent host based on the number of operation histories of the type of monitoring target and the type of metrics system that match the type of monitoring target for which metrics were acquired, and requests the agent host for metrics in accordance with the determined priority. The monitoring system of claim 1 .

4. the manager host manages metrics acquired by each of a plurality of agent hosts included in a first system and metrics acquired by each of a plurality of agent hosts included in a second system different from the first system; When the metrics acquired by the first agent host of the first system indicate a first fault, and a fault investigation is performed on the first fault by a predetermined user, the manager host: extracting operation history for a predetermined period from the operation history of the predetermined user stored in the storage unit, the operation history corresponding to a second failure having a metric classification matching the metric classification of the first failure; When the system including the second agent host in which the second failure has occurred is the second system, a number of hops, which is the number of components configured between the second agent host and another agent host of the second system, is calculated based on configuration information of the second system; Counting the operation history for the predetermined period for each metric classification and number of hops; determining a priority of the metrics related to the operation history for the predetermined period according to the number of operation histories of the metric classification and the number of hops of the agent host that acquires the metrics, the number of hops of the metric classification and the number of hops of the agent host that acquires the metrics; Calculating the number of hops, which is the number of components configured between the first agent host and another agent host of the first system, based on configuration information of the first system; determining a priority of the metrics to be transmitted to each of the plurality of agent hosts included in the first system according to a classification of the metrics and a priority of the metrics having the same number of hops of the agent host that acquires the metrics; The monitoring system of claim 1 .

5. the storage unit stores fault information including information indicating a classification of metrics indicating a fault, information on a date and time when the fault occurred, and information on a date and time when the fault was recovered from; When there are multiple failures of a metric classification that matches the metric classification indicating the specified failure, the manager host: Calculating a fault duration indicating a duration of each of the plurality of faults based on the fault information stored in the storage unit; Identifying a fault having the shortest calculated fault duration from among the plurality of faults; extracting an operation history for a predetermined period from the occurrence of the one failure from the operation history of the predetermined user stored in the storage unit; The monitoring system of claim 1 .

6. the manager host sets an interval for transmitting metrics so that the higher the determined priority is, the shorter the interval is, and requests the agent host to transmit the metrics at the set interval. The monitoring system of claim 1 .

7. the manager host provides a screen on a user terminal of the user on which a user can specify a fault for which a fault investigation is to be performed; When a specified failure is specified by a specified user via the screen, the manager host extracts, from the operation history of the specified user stored in the storage unit, operation history for a specified period since the occurrence of a failure of a metric classification matching the metric classification indicating the specified failure specified by the specified user, counts the extracted operation history for each metric classification, determines a priority of the metrics to be acquired by the agent host based on the number of operation history of the metric classification matching the metric classification, and requests metrics from the agent host in accordance with the determined priority. The monitoring system of claim 1 .

8. A monitoring method in a monitoring system including an agent host that acquires metrics of a monitoring target, a manager host that manages the metrics acquired by the agent host, and a storage unit that stores an operation history indicating that the metrics acquired by the agent host have been transmitted by the manager host to a user terminal for failure investigation, comprising: When a specific user investigates a specific problem, the manager host extracts operation history for a predetermined period from the occurrence of a failure of a metric classification that matches the metric classification indicating the predetermined failure from the operation history of the predetermined user stored in the storage unit, counts the extracted operation history for each metric classification, determines a priority of the metrics to be acquired by the agent host based on the number of operation histories of the metric classification that matches the metric classification, and requests metrics from the agent host in accordance with the determined priority; the agent host transmitting metrics to the manager host in response to a request by the manager host; the manager host transmitting the metrics transmitted from the agent host to a user terminal of the predetermined user; A monitoring method including:

Images