Server monitoring device, server monitoring system, server monitoring method, and program
The server monitoring device dynamically adjusts data collection frequencies to reduce overhead and power consumption by using a monitoring unit and frequency control unit, addressing the inefficiencies in existing technologies.
Patent Information
- Application Number
- JP2024520110
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- Filing Date
- 2022-05-10
- Publication Date
- 2026-01-06
- Estimated Expiration
- 2042-05-10
AI Technical Summary
Existing server monitoring technologies do not provide a method for determining the frequency of data collection, leading to increased overhead and power consumption when a variety of applications are installed on hardware and their combinations are dynamically changed.
A server monitoring device with a monitoring unit, rule setting database, and monitoring frequency control unit that adjusts data collection frequencies based on monitoring rules, reducing collection intervals or increasing frequency as needed to optimize power usage.
Reduces overhead and power consumption by dynamically adjusting data collection frequencies, balancing power loads across physical servers, and optimizing monitoring operations.
Smart Images

Figure 0007794304000001 
Figure 0007794304000002 
Figure 0007794304000003
Abstract
Description
[Technical Field]
[0001] The present invention relates to a server monitoring device, a server monitoring system, a server monitoring method, and a program. [Background technology]
[0002] In recent years, various services have been provided on service platforms, and server monitoring functions are essential for providing these services.
[0003] In particular, a wide variety of virtualized applications (sometimes referred to as "apps") run on server platforms, and the necessary information is collected to control these applications using a controller. For example, a data collection tool collects necessary hardware information, such as the usage rate of the central processing unit (CPU) on which the application runs and the CPU's operating frequency. Applications also include those whose internal configuration is a black box.
[0004] The objects controlled by the controller include the placement control of virtualized applications, as well as the configuration and changes of hardware and the OS (Operating System). Application placement control also includes the scale-in, scale-out, and migration of VMs (Virtual Machines).
[0005] Here, when a deployment request from an application running in a virtualized environment reaches the controller, optimal component placement can be performed in that virtualized environment, eliminating the need for real-time monitoring (see non-patent document 1).
[0006] On the other hand, when a service is operated on the service platform, monitoring is performed at an arbitrary frequency, and optimal component placement and configuration are dynamically performed (see Non-Patent Documents 2 and 3). [Prior art documents] [Non-patent literature]
[0007] [Non-Patent Document 1] Von Laszewski, Gregor, et al. "Power-aware scheduling of virtual machines in dvfs-enabled clusters." 2009 IEEE International Conference on Cluster Computing and Workshops. IEEE, 2009. [Non-patent document 2] Rocha, Isabelly, et al. "Heats: Heterogeneity-and energy-aware task-based scheduling." 2019 27th Euromicro International Conference on Parallel, Distributed and Network-Based Processing (PDP). IEEE, 2019. [Non-patent document 3] Douhara, Ryuki, et al. "Kubernetes-based workload allocation optimizer for minimizing power consumption of computing system with neural network." 2020 International Conference on Computational Science and Computational Intelligence (CSCI). IEEE, 2020. Summary of the Invention [Problem to be solved by the invention]
[0008] Non-Patent Document 2 and Non-Patent Document 3 do not disclose any specific method for determining the frequency of data collection. What Non-Patent Document 2 and Non-Patent Document 3 disclose is that no overhead due to monitoring that affects services occurs during evaluation.
[0009] However, when monitoring is performed, dedicated software collects power and performance data within the server and transmits the collected data to an analysis unit, etc. In this way, the server's power required to provide the service is consumed by the processing performed by the dedicated software.
[0010] Therefore, the monitoring frequency, which indicates the frequency of data collection, is important in an environment where a wide variety of applications are installed on hardware and the combination of these applications is dynamically changed, and where a service infrastructure is managed.
[0011] The present invention was made in light of these points, and its objective is to reduce the overhead and power consumption caused by real-time monitoring on a service platform where a wide variety of applications are installed on hardware and the combination of these applications is dynamically changed. [Means for solving the problem]
[0012] A server monitoring device according to the present invention includes a monitoring unit that collects data from a group of physical servers having a plurality of physical servers that realize computing with virtual machines / containers installed, and monitors the status of each of the physical servers; a rule setting database in which monitoring rules indicating data collection frequencies are set for each of the physical servers; and a monitoring frequency control unit that updates a collection mode for each of the data based on the monitoring rules corresponding to the physical servers set in the rule setting database, and periodically sets the frequency of data collection executed according to the monitoring rules. The monitoring unit receives a feedback request from an application executed on the virtual machine / container, and the monitoring frequency control unit shortens the interval at which data is collected from the physical server executing the application, thereby increasing the collection frequency, or sets the interval at which data is collected to a predetermined value, thereby fixing the collection frequency. It is characterized by: [Effects of the Invention]
[0013] According to the present invention, it is possible to reduce overhead and power consumption due to real-time monitoring on a service platform where a wide variety of applications are installed on hardware and the combination of these applications is dynamically changed. [Brief explanation of the drawings]
[0014] [Figure 1] 1 is an explanatory diagram showing the configuration of a server monitoring system according to an embodiment of the present invention; [Figure 2] FIG. 2 is an explanatory diagram showing a rule setting database stored in a database. [Figure 3A] 1 is a flowchart showing the process flow for collecting data from computes and determining the frequency at which a controller monitors the computes in a server monitoring system (part 1). [Figure 3B] 10 is a flowchart showing the process flow for collecting data from a compute and determining the frequency at which a controller monitors the compute in a server monitoring system (part 2). [Figure 3C] 10 is a flowchart showing the process flow for collecting data from computes and determining the frequency at which the controller monitors the computes in a server monitoring system (part 3). [Figure 4] 10 is a flowchart showing the flow of an App request process. [Figure 5] 10 is a flowchart showing the flow of a CPU utilization rate determination process. [Figure 6] 10 is a flowchart showing the flow of a database rewriting process. [Figure 7] 10 is a flowchart showing the flow of a model construction process. [Figure 8] 10 is a flowchart showing the flow of CPU allocation processing. [Figure 9] FIG. 2 is a hardware configuration diagram illustrating an example of a computer that realizes the functions of a controller according to the present embodiment. DETAILED DESCRIPTION OF THE INVENTION
[0015] Hereinafter, an embodiment of the present invention will be described with reference to the drawings. <Present Embodiment> FIG. 1 is an explanatory diagram showing the configuration of a server monitoring system 100 according to this embodiment. As shown in FIG. 1, the server monitoring system 100 includes a controller 10 (server monitoring device) and a compute 30 (physical server group).
[0016] In the server monitoring system 100, a compute 30 and a controller 10 are connected via a network.
[0017] The compute 30 has a plurality of physical servers 31 (physical servers 31a to 31d) that implement a plurality of types of virtual machines / containers. In the description of this embodiment, " / " means "or." Each of the physical servers 31a to 31d constitutes a virtual server (compute) and is equipped with resources such as a plurality of CPUs (Central Processing Units), memory, system storage, and a network. In this embodiment, when it is not necessary to specify one of the physical servers 31a to 31d, it is simply referred to as the physical server 31.
[0018] The controller 10 is configured to include a monitoring unit 1, a monitoring frequency control unit 2, a database 3, an estimation unit 4, a control determination unit 5, a control unit 6, and a missing data processing unit 7. The controller 10 operates based on a program stored in a ROM 902 or HDD 904, which will be described later with reference to FIG. 9, and embodies the monitoring unit 1, the monitoring frequency control unit 2, the estimation unit 4, the control determination unit 5, the control unit 6, and the missing data processing unit 7.
[0019] The database 3 is configured to include a data store 3a and a rule setting database 3b. The database 3 is configured with a ROM 902 or an HDD 904, which will be described later with reference to Fig. 9, and the data store 3a stores data collected from the physical servers 31a to 31d. The rule setting database 3b has monitoring rules set for each of the physical servers 31a to 31d, which indicate the frequency of data collection.
[0020] Furthermore, data required for constructing a model is collected from the compute 30 (physical server group) and the data store 3a holds the collected data. In this embodiment, the data stored in the data store 3a covers all data that can be collected by the data collection unit 32, which will be described later, and includes, for example, CPU usage rate, CPU operating frequency, temperature of the physical server 31, memory usage rate, and file read / write count.
[0021] The monitoring unit 1 collects data on the compute 30 (a plurality of physical servers 31a to 31d: a physical server group) and monitors the status of each of the physical servers 31a to 31d.
[0022] The monitoring frequency control unit 2 updates the collection mode of each data based on the monitoring rules corresponding to the physical server 31 set in the rule setting database 3b, and periodically sets the collection frequency of the data executed according to the monitoring rules.
[0023] Furthermore, the monitoring frequency control unit 2 identifies a CPU core on which a data collection tool that collects data from the physical server 31 is executed. The monitoring frequency control unit 2 may reduce the collection frequency executed by the data collection tool based on the utilization rate of the identified CPU core. In this case, the predetermined threshold can be set to, for example, 80% or more or exceeding 80%, and the monitoring frequency control unit 2 reduces the collection frequency executed by the data collection tool when the utilization rate of the CPU core is 80% or more or exceeds 80%.
[0024] Furthermore, based on the utilization rate of the identified CPU core, if there is another CPU core whose utilization rate is lower than a predetermined threshold, the monitoring frequency control unit 2 may change the CPU core on which the data collection tool is executed to another CPU core. In this case, for example, if the physical server 31a is equipped with eight CPU cores (numbered 1 to 8) and it is identified that the CPU core on which the data collection tool is executed is number 5, and if the utilization rate of number 5 CPU core is equal to or higher than 80% or exceeds 80%, the monitoring frequency control unit 2 changes the CPU core utilization rate to number 6 or number 7 CPU core whose utilization rate is lower than the predetermined threshold.
[0025] The monitoring unit 1 may also receive a feedback request from an application running on a virtual machine / container. A feedback request is, for example, a request to increase the data collection frequency for a physical server 31 when performance of the physical server 31 is degraded among the multiple monitored physical servers 31a-31d. In other words, in this embodiment, the monitoring frequency control unit 2 periodically sets the data collection frequency for the physical server 31, and when an application detects a malfunction, the monitoring frequency control unit 2 requests that monitoring of the physical server 31 be strengthened. In this case, the monitoring frequency control unit 2 shortens the interval at which data is collected from the physical server 31 running the application to increase the collection frequency, or sets the data collection interval to a predetermined value to fix the collection frequency. The feedback request is also included in the data collected from the compute 30 (the group of physical servers).
[0026] The estimation unit 4 executes construction of a predetermined model. Specifically, the estimation unit 4 creates a model that estimates and calculates the power consumption of the physical server 31 from performance data (e.g., CPU utilization rate) of the physical server 31. Hereinafter, in this embodiment, the creation of such a model is referred to as construction of a model.
[0027] In this case, the estimation unit 4 constructs a model based on the data stored in the data store 3a, and if the number of data is insufficient or the accuracy of the data is not sufficient in constructing the model, the monitoring frequency control unit 2 shortens the interval at which data is collected from the physical server 31 that runs the application and increases the collection frequency.
[0028] The control determination unit 5 calculates the server power consumption for each physical server 31 from the model created by the estimation unit 4, and determines whether the calculated server power consumption exceeds a predetermined threshold. If the calculated server power consumption exceeds the predetermined threshold, the control determination unit 5 controls processing for that physical server 31. In other words, the control determination unit 5 executes processing to suppress power consumption for the physical server 31 whose power consumption exceeds the predetermined threshold.
[0029] The control unit 6 executes a process of, for example, changing the placement of components on the compute 30 (physical server group) and reducing the number of powered-on physical servers 31. Specifically, the control unit 6 receives a command to reduce power consumption from the control determination unit 5 and executes a change in the placement of components.
[0030] In this case, for a physical server 31 whose power consumption exceeds a predetermined threshold, the components allocated to that physical server 31 are reallocated to other physical servers 31, thereby balancing the power consumption load. The control unit 6 then appropriately switches the power of the physical servers 31 that are powered on off, and controls the power consumption loads of the operating physical servers 31 so that they are uniform.
[0031] The missing data processing unit 7 executes a process to complement missing data (this is also referred to as missing data processing). When the number of data for calculating power consumption is insufficient for the model created by the estimation unit 4, or when the accuracy of the data is not sufficient, the missing data processing unit 7 executes missing data processing and reconstructs the model. Here, the missing data processing can be, for example, a known technique such as single imputation (mean value imputation or median imputation), regression imputation, or K-nearest neighbor method, and is not particularly limited.
[0032] In this embodiment, since the data collection frequency can be varied, there is a possibility that data collected from the physical server 31 may contain missing data. For example, if the data collection frequency decreases, it is possible that data is collected periodically but there is a data shortage (i.e., missing data). In such a case, the missing data processing unit 7 uses the above-mentioned known techniques such as single imputation, regression imputation, and K-nearest neighbor algorithm to complement the missing data and reconstruct the model.
[0033] The controller 10 is configured by a physical server. The hardware configuration of the controller 10 will be described later with reference to Fig. 9. Furthermore, the multiple physical servers 31 that make up the compute 30 are also configured with hardware similar to that of the controller 10 (not shown).
[0034] <Compute configuration> The compute 30 is made up of physical servers 31a to 31d (physical servers 31). Each of the physical servers 31a to 31d (physical servers 31) operates based on a program stored in a ROM or HDD, and embodies a data collection unit 32.
[0035] The data collection unit 32 executes hardware performance analysis tools such as perf and dstat, and performs real-time analysis of server resources for each physical server 31. In this embodiment, the tools executed by the data collection unit 32 are referred to as data collection tools.
[0036] The data collection unit 32 collects predetermined data from the physical server 31 according to the data collection frequency set in the monitoring frequency control unit 2 of the controller 10. As an example, the physical server 31 is equipped with eight CPU cores, and a data collection tool is executed by any one of the eight CPU cores to collect the predetermined data.
[0037] <Rule setting database monitoring information> Next, a description will be given of the rule setting database 3b stored in the database 3. In this embodiment, application will be abbreviated to App, and terms such as "App lock" and "App modeling" will be used.
[0038] Fig. 2 is an explanatory diagram showing the rule setting database 3b stored in the database 3. As shown in Fig. 2, the rule setting database 3b has the following items: server number, collection mode, collection interval ΔTs, and coefficient n, where coefficient n is an integer.
[0039] The physical server 31 with server number 1 has a collection mode of "normal" mode, a collection interval ΔTs of "3 [s]", and a coefficient n of "3". The physical server 31 with server number 2 has a collection mode of "app lock" mode, a collection interval ΔTs of "2 [s]", and a coefficient n of "2". The physical server 31 with server number 3 has a collection mode of "normal" mode, a collection interval ΔTs of "5 [s]", and a coefficient n of "5". The physical server 31 with server number 4 has a collection mode of "app modeling" mode, a collection interval ΔTs of "1 [s]", and a coefficient n of "1". The physical server 31 with server number 5 has a collection mode of "overhead", a collection interval ΔTs of "4 [s]", and a coefficient n of "2".
[0040] One of four collection modes, "Normal," "App Lock," "App Modeling," and "Overhead," is assigned to each physical server 31. In this embodiment, four modes are assigned, but the present invention is not limited to this, and multiple collection modes can be set and assigned to each physical server 31. Each mode operates roughly as follows.
[0041] "Normal" mode indicates the normal collection mode, with the collection interval periodically increased. In the "App Lock" mode, feedback from the app is accepted and the periodic collection interval is stopped from being extended. Also, if the target app is deleted from the physical server 31, the mode returns to normal mode. In "App Modeling" mode, data is collected frequently to build a model, and once the data collection required for modeling is complete, the system returns to normal mode. In "overhead" mode, when the monitoring tool (data collection tool) is running and the CPU core usage is high, the data collection interval is extended. When the CPU core usage decreases, the mode is returned to normal.
[0042] The collection interval ΔTs shown in Figure 2 is the time interval for collecting data, and n is a coefficient used to determine the time interval for collecting data. Details of the collection mode will be explained in the flowchart explaining monitoring frequency management.
[0043] In this embodiment, the monitoring frequency control unit 2 updates the collection mode of each data based on the monitoring rules corresponding to each physical server 31 set in the rule setting database 3b, and periodically sets the collection frequency of the data executed according to the monitoring rules.
[0044] This allows the controller 10 to dynamically determine the optimum monitoring frequency using the monitoring frequency control unit 2, thereby reducing overhead and power consumption due to real-time monitoring.
[0045] <Monitoring frequency management> Next, a process for managing the monitoring frequency (monitoring frequency determination process) in the controller 10 of the server monitoring system 100 according to this embodiment will be described.
[0046] 3A to 8 are flowcharts showing the flow of processing in the server monitoring system 100 for collecting data from the computes 30 (physical server group) and determining the frequency at which the controller 10 monitors the computes 30. FIG.
[0047] In the flowcharts shown in FIGS. 3A to 3C, the monitoring unit 1 and the monitoring frequency control unit 2 cooperate with each other to determine the frequency at which the compute 30 is monitored.
[0048] First, the monitoring unit 1 starts collecting data from the compute 30 (physical server group) and monitors the status of each physical server 31a to 31d (step S001). First, the data collection interval ΔTs is set to the minimum interval ΔT0s that the data collection tool can collect, as an initial value.
[0049] The monitoring frequency control unit 2 receives an instruction from the operator (user) and determines whether or not to continue monitoring and controlling the compute 30 according to the operator's instruction (step S002). If the monitoring frequency control unit 2 determines not to continue monitoring and controlling the compute 30 according to the operator's instruction (No in step S002), it ends the monitoring frequency determination process.
[0050] On the other hand, if the operator instructs to continue monitoring and controlling the compute 30 (Yes in step S002), the monitoring frequency control unit 2 repeats the process of determining the monitoring frequency for the following monitoring operations in order for each physical server 31 that constitutes the compute 30 (step S003).
[0051] In this embodiment, the monitoring frequency control unit 2 is not limited to determining the monitoring frequency for each physical server 31 in order, but may, for example, determine the monitoring frequency for each physical server 31 in parallel and simultaneously.
[0052] 2 for each physical server 31 (step S004), and executes processing corresponding to each of the following modes 1 to 4. Specifically, the monitoring frequency control unit 2 executes one of four modes: 1. normal mode, 2. App lock mode, 3. App modeling mode, and 4. overhead mode.
[0053] <1. Normal mode> <2. App Lock Mode> <3. App Modeling Mode> <4. Overhead mode> These processes indicate the names of the modes, and are sometimes simply called Normal, App Lock, App Modeling, and Overhead.
[0054] <1. Normal mode> If the physical server 31 is in normal mode (step S004), the monitoring frequency control unit 2 proceeds to step S005 in Fig. 3B and determines whether a predetermined period has elapsed since the start of data collection. If the predetermined period has elapsed since the start of data collection (Yes in step S005), the monitoring frequency control unit 2 updates the collection interval (step S006).
[0055] In this case, the monitoring frequency control unit 2 multiplies the initial value ΔT0s by the coefficient n plus 1 (ΔTs=ΔT0s×(n+1)) to obtain the new data collection interval ΔTs. The monitoring frequency control unit 2 updates the data collection interval ΔTs to the value obtained by the multiplication.
[0056] In normal mode, the monitoring frequency control unit 2 can widen the data collection interval ΔTs by gradually increasing the coefficient n. This allows the monitoring frequency control unit 2 to reduce the data collection frequency. The data collection interval is updated, for example, every day. In this way, the monitoring frequency control unit 2 sets (updates) the data collection frequency to be regular (every day) by adding +1 to the coefficient n for each day (n+1).
[0057] After updating the data collection interval ΔTs for the physical server 31, the monitoring frequency control unit 2 rewrites the data in the rule setting database 3b shown in Fig. 2 (step S007). Specifically, the monitoring frequency control unit 2 rewrites the coefficient n and the data collection interval ΔTs in the row for the corresponding physical server 31 in the rule setting database 3b in Fig. 2, and then proceeds to step S08. Note that the collection mode remains normal mode, so it is not changed even if it is rewritten.
[0058] On the other hand, if the predetermined period has not elapsed since the start of data collection (No in step S005), or after the contents of the rule setting database 3b in FIG. 2 have been rewritten (step S007), the monitoring frequency control unit 2 determines whether there is a request from the App (step S008).
[0059] If there is a request from the app (Yes in step S008), the monitoring frequency control unit 2 proceeds to step S009, executes the app request process (step S009), and proceeds to step S020 in FIG. 3A.
[0060] On the other hand, if there is no request from the app (No in step S008), the monitoring frequency control unit 2 proceeds to step S010, identifies the CPU core on which the data collection tool runs, and proceeds to step S011. In step S011, the monitoring frequency control unit 2 executes a CPU usage rate determination process, and proceeds to step S020 in FIG. 3A.
[0061] The application request process in step S009 will be described with reference to FIG. 4, and the CPU utilization rate determination process in step S011 will be described with reference to FIG.
[0062] <2. App Lock Mode> 3A, if the application is in the app lock mode (step S004), the monitoring frequency control unit 2 proceeds to step S012 in FIG. 3A to determine whether the application is running on the server. If the application is running on the physical server 31 in step S012 (Yes in step S012), the monitoring frequency control unit 2 proceeds to step S020 in FIG. 3A.
[0063] On the other hand, if the app is not running on the physical server 31 (No in step S012), the monitoring frequency control unit 2 executes a database rewrite process (step S013) and proceeds to step S020 in Fig. 3A. The database rewrite process will be described with reference to Fig. 6.
[0064] In the App lock mode, the data collection interval ΔTs is updated by executing the database rewrite process of Fig. 6. That is, the monitoring frequency control unit 2 receives feedback regarding control from the App, changes to the App lock mode, and updates the data collection interval ΔTs. Specifically, if there is a performance degradation in the physical server 31, the monitoring frequency control unit 2 narrows the data collection interval ΔTs to increase the data collection frequency.
[0065] In this case, the monitoring frequency control unit 2 sets the data collection interval ΔTs to, for example, the initial value ΔT0s×coefficient m, where m is a predetermined integer smaller than the coefficient n at the time feedback from the app is received.
[0066] In response to this, in normal mode, the monitoring frequency control unit 2 may, for example, widen the data collection interval ΔTs, which may delay control such as scaling in / out of the physical server 31, and this may have an impact on the quality of service. If an impact on the quality of service is observed, the monitoring frequency control unit 2 receives feedback such as a request for strengthened monitoring from the service provider (app administrator). In such a case, the monitoring frequency control unit 2 fixes the data collection interval ΔTs without widening the collection frequency.
[0067] <3. App Modeling Mode> Returning to FIG. 3A, in the case of the App modeling mode (step S004), the monitoring frequency control unit 2 proceeds to step S014 in FIG. 3C to determine whether data collection has been completed. If data collection has been completed (Yes in step S014), the estimation unit 4 executes a model construction process (step S015) and proceeds to step S020 in FIG. 3A. The model construction process will be described with reference to FIG. 7.
[0068] On the other hand, if data collection is not complete (No in step S014), the monitoring frequency control unit 2 proceeds to step S020 in FIG. 3A.
[0069] In the App modeling mode, the model construction process of Fig. 7 is executed to construct a model using the data stored in the data store 3a of the database 3. The estimation unit 4 executes model construction, and if the number of data is insufficient or the accuracy is not satisfied, the estimation unit 4 sets the data collection interval ΔTs to a narrower value and sets the modeling mode.
[0070] When the estimation unit 4 has finished collecting data for constructing a model, it returns to the original data collection interval ΔTs. In this case, the data collection interval ΔTs is set to a value specified by the app or the initial value ΔT0s. Note that the estimation unit 4 may reduce power consumption by increasing or decreasing the number of data items collected.
[0071] <4. Overhead mode> Returning to Fig. 3A, in the case of overhead mode (step S004), the monitoring frequency control unit 2 proceeds to step S016 in Fig. 3C, identifies the CPU core on which the data collection tool operates, and proceeds to step S017. After executing the CPU allocation process (step S017), the monitoring frequency control unit 2 proceeds to step S020 in Fig. 3A. The CPU allocation process will be described using Fig. 8.
[0072] In overhead mode, if the CPU utilization rate in the physical server 31 remains high and there is another free CPU, the monitoring frequency control unit 2 changes the operating core to the free CPU. If there is no free CPU, the monitoring frequency control unit 2 further changes the data collection interval ΔTs, for example, to a collection interval ΔTh obtained by multiplying the data collection interval ΔTs by an arbitrary constant (2 to 5). In this way, the monitoring frequency control unit 2 sets the data collection interval ΔTh to be even longer than the current data collection interval ΔTs.
[0073] Next, in step S020, the monitoring frequency control unit 2 determines whether there is a change in the data collection mode, etc. If there is a change in the data collection mode, etc. (Yes in step S020), the monitoring frequency control unit 2 notifies the physical server 31 of the data collection method and instructs it to collect data in the changed collection mode (step S021).
[0074] On the other hand, if there is no change in the data collection mode (No in step S020), or after the collection mode is instructed (step S021), the monitoring frequency control unit 2 determines whether monitoring and control of all physical servers 31 has been completed (step S022).
[0075] If there is a physical server 31 for which monitoring and control have not been completed, the monitoring frequency control unit 2 returns to step S002 and repeats the process until monitoring and control of all physical servers 31 has been completed (steps S003 to S022).
[0076] In this way, the monitoring frequency control unit 2 determines the monitoring frequency for all physical servers 31 in sequence, and executes the monitoring frequency determination process for the number of physical servers 31. Also, when the monitoring frequency determination process is executed in parallel for each of the physical servers 31, the monitoring frequency control unit 2 executes the monitoring frequency determination process for all physical servers 31 in the processing time for one physical server 31.
[0077] <Explanation of Each Process> Next, the processes of App request processing, CPU usage rate determination processing, database rewrite processing, model construction processing, and CPU allocation processing will be described.
[0078] <App Request Processing> FIG. 4 is a flowchart showing the flow of the App request processing in step S009 in FIG. 3B.
[0079] As shown in FIG. 4, the monitoring frequency control unit 2 determines whether the App is running on the physical server 31 (step S101). If the App is not running on the physical server 31 (No in step S101), the process proceeds to step S020 in FIG. 3A.
[0080] On the other hand, if the App is running on the physical server 31 (Yes in step S101), the monitoring frequency control unit 2 proceeds to step S102 and determines whether the request from the App is for model construction (request 1) or feedback regarding control (request 2).
[0081] If the request from the App is for model construction (request 1 in step S102), the monitoring frequency control unit 2 proceeds to step S103 and executes the construction of the model by the estimation unit 4.
[0082] On the other hand, if the request from the App is for feedback regarding control (request 2 in step S102), the monitoring frequency control unit 2 updates the data collection interval ΔTs (step S109).
[0083] In this case, for example, the monitoring frequency control unit 2 substitutes m for the coefficient n and multiplies the initial value ΔT0s by the coefficient m as the collection interval ΔTs of new data (ΔTs = ΔT0s × m). Note that the coefficient m is an integer smaller than the coefficient n. Thereby, the monitoring frequency control unit 2 updates the obtained multiplied value as the collection interval ΔTs of the data (step S109).
[0084] By substituting an integer smaller than the coefficient n for the coefficient m (m < n), the monitoring frequency control unit 2 can narrow the collection interval ΔTs of the data, thereby increasing the data collection frequency.
[0085] When the monitoring frequency control unit 2 updates the collection interval ΔTs of the physical server 31, it rewrites the data in the rule setting database 3b shown in FIG. 2 (step S110). Specifically, the monitoring frequency control unit 2 rewrites the coefficient n, the collection interval ΔTs, and the collection mode (App lock) of the corresponding row of the physical server 31 in the rule setting database 3b of FIG. 2, and proceeds to step S020 in FIG. 3A.
[0086] On the other hand, when the request from the App is for model construction (request 1 in step S102), the estimation unit 4 executes model construction (step S103). Then, the estimation unit 4 determines whether the number of data of the constructed model is sufficient and whether the accuracy meets the requirements (step S104).
[0087] When the number of data of the constructed model is not sufficient or the accuracy does not meet the requirements (No in step S104), the estimation unit 4 cooperates with the missing data processing unit 7 to perform missing data processing and reconstruct the model (step S105). Then, the estimation unit 4 re-determines whether the number of data of the reconstructed model is sufficient or the accuracy meets the requirements (step S106).
[0088] On the other hand, when the number of data of the constructed model is sufficient and the accuracy also meets the requirements (Yes in step S104), the monitoring frequency control unit 2 proceeds to step S107.
[0089] In step S106, if the number of data of the reconstructed model is not sufficient or the accuracy does not meet the requirements (No in step S106), the monitoring frequency control unit 2 sets, for example, the collection interval ΔTs of new data to the specified value from the App or the initial value ΔT0s (step S108).
[0090] In this case, the monitoring frequency control unit 2 causes the data collection tool of the data collection unit 32 to start collecting data for model construction. Then, the monitoring frequency control unit 2 rewrites the data in the rule setting database 3b shown in FIG. 2. Specifically, the monitoring frequency control unit 2 changes the coefficient n in the row of the corresponding physical server 31 to 0 in the rule setting database 3b of FIG. 2, rewrites it to the initial value ΔT0s and the collection mode (App modeling), and proceeds to step S020 in FIG. 3A.
[0091] On the other hand, if the number of data of the reconstructed model is sufficient and the accuracy also meets the requirements (Yes in step S106), the monitoring frequency control unit 2 proceeds to step S107.
[0092] In step S107, the monitoring frequency control unit 2 provides the model constructed by the App that has a request from the compute 30 (physical server group), and proceeds to step S020 in FIG. 3A.
[0093] <CPU Usage Rate Determination Process> FIG. 5 is a flowchart showing the flow of the CPU usage rate determination process in step S011 in FIG. 3B.
[0094] As shown in FIG. 5, the monitoring frequency control unit 2 executes the CPU usage rate determination process. In this case, the monitoring frequency control unit 2 identifies the CPU core on which the data collection tool of the data collection unit 32 operates, and determines whether the CPU usage rate is equal to or higher than a predetermined threshold value (step S201). The predetermined threshold value is, for example, 80%. When the CPU usage rate of the identified CPU core is 80% or higher (Yes in step S201), the monitoring frequency control unit 2 changes it to widen the data collection interval ΔTh (step S202).
[0095] In this case, the monitoring frequency control unit 2 changes the data collection interval ΔTh to, for example, the data collection interval ΔTs multiplied by an arbitrary number (such as 2 to 5), and proceeds to step S203.
[0096] On the other hand, if the CPU utilization rate of the identified CPU core is less than 80% (No in step S201), the monitoring frequency control unit 2 determines that the CPU core still has room to run, and proceeds to step S020 in FIG. 3A without performing any processing.
[0097] In step S203, the monitoring frequency control unit 2 rewrites the collection interval ΔTh and collection mode (overhead) in the row of the corresponding physical server 31 in the rule setting database 3b, and proceeds to step S020 in FIG. 3A.
[0098] <Database rewrite process> 6 is a flowchart showing the process of rewriting the database in step S013 in FIG. 6. In this case, the monitoring frequency control unit 2 is in the app lock mode, and the app is not running on the physical server 31.
[0099] As shown in Fig. 6, the monitoring frequency control unit 2 rewrites the rule setting database 3b shown in Fig. 2 with the contents of the normal mode (step S301). Specifically, the monitoring frequency control unit 2 changes the coefficient n in the row of the corresponding physical server 31 in the rule setting database 3b of Fig. 2 to 0, rewrites the data collection interval ΔTs and collection mode (normal), and proceeds to step S020 of Fig. 3A.
[0100] <Model building process> FIG. 7 is a flowchart showing the flow of the model construction process in step S15 in FIG. 3C.
[0101] As shown in FIG. 7, the estimation unit 4 cooperates with the missing data processing unit 7 and executes a model construction process (step S401). The estimation unit 4 provides the model constructed in the App of the computer 30 (physical server group) via the control determination unit 5 and the control unit 6 (step S402).
[0102] In this case, when the monitoring frequency control unit 2 provides the constructed model, it rewrites the data in the rule setting database 3b shown in FIG. 2 (step S403). Specifically, the monitoring frequency control unit 2 changes the coefficient n in the corresponding row of the physical server 31 in the rule setting database 3b to 0, and rewrites it to the data collection interval ΔTs and the collection mode (normal), and proceeds to step S020 in FIG. 3A.
[0103] <CPU Scheduling Process> FIG. 8 is a flowchart showing the flow of the CPU scheduling process in step S17 in FIG. 3C.
[0104] As shown in FIG. 8, the monitoring frequency control unit 2 determines the CPU usage rate. In this case, the monitoring frequency control unit 2 determines whether the CPU usage rate is equal to or higher than a predetermined threshold (step S501). For example, when the monitoring frequency control unit 2 sets the predetermined threshold to 80%, if the CPU usage rate of the specified CPU core is 80% or higher (Yes in step S501), it proceeds to step S504.
[0105] On the other hand, when the CPU usage rate of the specified CPU core is less than 80% (lower than the predetermined threshold) (No in step S501), the monitoring frequency control unit 2 changes the data collection interval ΔTs to a value obtained by multiplying the initial value ΔT0s by the coefficient n. However, in the setting of the collection interval ΔTs, 1 is substituted for the coefficient n (n = 1) and multiplied by the initial value ΔT0s. The monitoring frequency control unit 2 sets the initial value ΔT0s to the collection interval ΔTs, starts the coefficient n from 0, returns to the normal mode, and proceeds to step S503.
[0106] In step S503, the monitoring frequency control unit 2 rewrites the data in the rule setting database 3b shown in Fig. 2. Specifically, the monitoring frequency control unit 2 changes the coefficient n in the row of the corresponding physical server 31 in the rule setting database 3b in Fig. 2 to 0, rewrites the data collection interval ΔTs and collection mode (normal), and proceeds to step S020 in Fig. 3A.
[0107] In step S504, if there is another free core (Yes in step S504), the monitoring frequency control unit 2 changes the operating core and resumes data collection by the data collection tool of the data collection unit 32 (step S505). Then, the monitoring frequency control unit 2 proceeds to step S506.
[0108] On the other hand, if there are no other free cores (No in step S504), the monitoring frequency control unit 2 changes the collection interval ΔTh to be further widened (step S507). In this case, the monitoring frequency control unit 2 sets the collection interval ΔTh of the new data to, for example, the collection interval ΔTh multiplied by an arbitrary constant (2 to 5). Note that there are no particular limitations on how the data collection interval is widened. Then, the monitoring frequency control unit 2 proceeds to step S508.
[0109] In step S506, the monitoring frequency control unit 2 rewrites the data in the rule setting database 3b shown in Fig. 2. Specifically, the monitoring frequency control unit 2 changes the coefficient n in the row of the corresponding physical server 31 in the rule setting database 3b in Fig. 2 to 0, rewrites the data collection interval ΔTs and collection mode (normal), and proceeds to step S020 in Fig. 3A.
[0110] Furthermore, in step S508, the monitoring frequency control unit 2 rewrites the data in the rule setting database 3b shown in Fig. 2. Specifically, the monitoring frequency control unit 2 rewrites the collection interval ΔTh and collection mode (overhead) of the row of data for the relevant physical server 31 in the rule setting database 3b in Fig. 2, and proceeds to step S020 in Fig. 3A.
[0111] As described above, the controller 10 of the server monitoring system 100 according to this embodiment is configured to include a monitor 1, a rule setting database 3b, and a monitoring frequency control unit 2. The monitor 1 collects data from the compute 30 (a group of physical servers) and monitors the status of each physical server 31. The monitoring frequency control unit 2 updates the collection mode for each piece of data based on the monitoring rules corresponding to the physical servers 31 set in the rule setting database 3b, and periodically sets the frequency of data collection executed according to the monitoring rules.
[0112] This allows the controller 10 to reduce overhead and power consumption due to real-time monitoring on a service platform where a wide variety of applications are installed on the hardware and the combinations of these applications are dynamically changed.
[0113] <Controller hardware configuration> The controller 10 according to this embodiment is realized by, for example, a computer 900 as shown in FIG.
[0114] FIG. 9 is a hardware configuration diagram showing an example of a computer 900 that realizes the functions of the controller 10 according to this embodiment.
[0115] The computer 900 has a CPU (Central Processing Unit) 901, a ROM (Read Only Memory) 902, a RAM (Random Access Memory) 903, a HDD (Hard Disk Drive) 904, an input / output I / F (Interface) 905, a communication I / F 906, and a media I / F 907.
[0116] The CPU 901 operates based on a program stored in the ROM 902 or the HDD 904, and functions as each functional unit (monitoring unit 1, monitoring frequency control unit 2, etc.) of the controller 10 shown in FIG.
[0117] The ROM 902 stores a boot program executed by the CPU 901 when the computer 900 is started, programs related to the hardware of the computer 900, and the like.
[0118] The CPU 901 controls an input device 910 such as a mouse or keyboard, and an output device 911 such as a display, via an input / output I / F 905. The CPU 901 acquires data from the input device 910 via the input / output I / F 905, and outputs generated data to the output device 911. Note that a GPU or the like may be used as a processor together with the CPU 901.
[0119] The HDD 904 stores programs executed by the CPU 901 and data used by the programs. The communication I / F 906 receives data from other devices (e.g., Compute 30) via a communication network (e.g., NW (Network) 920) and outputs the data to the CPU 901, and also transmits data generated by the CPU 901 to other devices (e.g., Compute 30) via the communication network.
[0120] The media I / F 907 reads a program or data stored in the recording medium 912 and outputs it to the CPU 901 via the RAM 903. The CPU 901 loads a program related to a target process from the recording medium 912 onto the RAM 903 via the media I / F 907, and executes the loaded program. The recording medium 912 is an optical recording medium such as a DVD (Digital Versatile Disc) or a PD (Phase Change Rewritable Disc), a magneto-optical recording medium such as an MO (Magneto Optical disc), a magnetic recording medium, a conductive memory tape medium, a semiconductor memory, or the like.
[0121] For example, when the computer 900 functions as the controller 10 according to the first embodiment, the CPU 901 of the computer 900 executes a program loaded onto the RAM 903 to realize each functional unit of the controller 10 (monitoring unit 1, monitoring frequency control unit 2, etc.).
[0122] The HDD 904 stores data in the RAM 903. The CPU 901 reads and executes a program related to a target process from the recording medium 912. Alternatively, the CPU 901 may read a program related to a target process from another device via a communication network (NW 920).
[0123] <Effects> The effects of the controller 10 according to this embodiment will be described below. (1) The controller 10 is characterized by comprising: a monitoring unit 1 that collects data from a group of physical servers having a plurality of physical servers that realize computing equipped with virtual machines / containers, and monitors the status of each physical server 31; a rule setting database 3b in which monitoring rules indicating the frequency of data collection are set for each physical server 31; and a monitoring frequency control unit 2 that updates the collection mode of each data based on the monitoring rules corresponding to the physical servers 31 set in the rule setting database 3b, and periodically sets the frequency of data collection executed according to the monitoring rules.
[0124] The monitoring unit 1 collects each data of the compute 30 (physical server group) and monitors the status of each physical server 31. The monitoring frequency control unit 2 updates the collection mode of each data based on the monitoring rules corresponding to the physical server 31, and periodically sets the frequency of data collection executed according to the monitoring rules. This allows the controller 10 to dynamically determine the monitoring collection frequency for each physical server 31 and periodically update it.
[0125] Therefore, when the controller 10 periodically updates the collection frequency of monitoring, it is possible to increase the collection interval of data from the compute 30 (physical server group), and gradually reduce the power consumption related to monitoring.
[0126] Therefore, the controller 10 can suppress overhead and power consumption due to real-time monitoring on a service platform where a wide variety of applications are installed on the hardware and the combinations of these applications are dynamically changed.
[0127] (2) The monitoring unit 1 of the controller 10 in (1) receives a feedback request from an application running on a virtual machine / container, and the monitoring frequency control unit 2 either shortens the data collection interval to the physical server 31 running the application, thereby increasing the collection frequency, or sets the data collection interval to a predetermined value, thereby fixing the collection frequency.
[0128] The monitoring unit 1 receives a feedback request from an application, and the monitoring frequency control unit 2 stops increasing the periodic data collection interval in response to the reception of the feedback by the monitoring unit 1. In other words, the monitoring frequency control unit 2 dynamically determines the optimal monitoring frequency by shortening the data collection interval and increasing the collection frequency, or by setting the data collection interval to a predetermined value and fixing the collection frequency.
[0129] This allows the controller 10 to dynamically determine the optimum monitoring frequency, and eliminates problems caused by extending the data collection interval.
[0130] (3) The monitoring frequency control unit 2 of the controller 10 described in (1) or (2) is characterized in that it identifies a CPU core on which a data collection tool that collects data from the physical server 31 is executed, and reduces the collection frequency executed by the data collection tool based on the utilization rate of the identified CPU core.
[0131] When the data collection tool is executed on the physical server 31, there is a possibility that the processes of the data collection tool and the applications may conflict with each other in the OS of the physical server 31. Since the execution of the data collection tool increases the probability of conflict between the processes of the data collection tool and the applications, it is necessary to avoid unstable operation for applications that require stable processing performance (for example, a communication system).
[0132] Therefore, by managing the CPU core usage rate using a predetermined threshold, the monitoring frequency control unit 2 can reduce the collection frequency executed by the data collection tool, thereby preventing unstable operation. For example, if the predetermined threshold for the CPU core is set to 80% and the CPU core usage rate is 80% or higher, the monitoring frequency control unit 2 reduces the collection frequency executed by the data collection tool. In this way, the monitoring frequency control unit 2 can prevent impacts on other applications processed by the same CPU core.
[0133] (4) The monitoring frequency control unit 2 of the controller 10 described in (1) or (2) is characterized in that it identifies a CPU core on which a data collection tool that collects data from the physical server 31 is executed, and based on the utilization rate of the identified CPU core, if there is another CPU core whose utilization rate is lower than a predetermined threshold, it changes the CPU core on which the data collection tool is executed to the other CPU core.
[0134] The monitoring frequency control unit 2 manages the CPU core usage rate using a predetermined threshold and changes the CPU core on which the data collection tool is executed to another CPU core, thereby distributing the load on the CPU core. The monitoring frequency control unit 2 can also reduce the power consumption of the physical server 31. This allows the monitoring frequency control unit 2 to avoid a high load on the CPU core, thereby maintaining stable operation of the physical server 31.
[0135] (5) The controller 10 described in (1) further comprises an estimation unit 4 that executes the construction of a predetermined model, and a data store 3a that collects data necessary for the construction of the model and stores the collected data, and the monitoring unit 1 receives a request to construct a model from an application executed on a virtual machine / container, and the monitoring frequency control unit 2 executes the construction of a model by the estimation unit 4 based on the data stored in the data store 3a, and when the number of data is insufficient or the accuracy of the data is not sufficient in the construction of the model, the controller shortens the interval of collecting data to the physical server 31 that executes the application and increases the collection frequency.
[0136] In this way, the estimation unit 4 executes model construction in response to instructions from the monitoring frequency control unit 2. If the accuracy of the constructed model is insufficient, the monitoring frequency control unit 2 can compensate for the lack of data or inaccuracy of the data when the estimation unit 4 constructs the model by shortening the data collection interval and increasing the collection frequency.
[0137] (6) The server monitoring system 100 is characterized by comprising: a monitoring unit 1 that collects data from a group of physical servers having a plurality of physical servers 31 that realize computing equipped with virtual machines / containers, and monitors the status of each physical server 31; a rule setting database 3b in which monitoring rules indicating the data collection frequency are set for each physical server 31; a monitoring frequency control unit 2 that updates the collection mode of each data based on the monitoring rules corresponding to the physical servers 31 set in the rule setting database 3b, and periodically sets the data collection frequency executed according to the monitoring rules; and a data collection unit 32 that collects specified data from the physical servers 31 at the data collection frequency set in the monitoring frequency control unit 2.
[0138] The server monitoring system 100 is configured to further include a compute 30 (a group of physical servers) in addition to the controller 10. The physical servers 31 also include a data collection unit 32, which runs as a data collection tool. This allows the server monitoring system 100 to collect data from each physical server 31 using the data collection unit 32 via the monitoring unit 1. The server monitoring system 100 can also dynamically determine the monitoring collection frequency for each physical server 31 using the controller 10, and periodically update it.
[0139] Therefore, when the server monitoring system 100 periodically updates the monitoring collection frequency, it can increase the interval at which data from the compute 30 (physical server group) is collected, thereby gradually reducing the power consumption associated with monitoring.
[0140] Therefore, the server monitoring system 100 can reduce overhead and power consumption due to real-time monitoring on a service platform where a wide variety of applications are installed on hardware and the combinations of these applications are dynamically changed.
[0141] (7) The server monitoring method is characterized in that the server monitoring device executes the steps of collecting data from a group of physical servers having a plurality of physical servers that realize computing equipped with virtual machines / containers, and monitoring the status of each physical server 31, and updating the collection mode of each data for each physical server 31 based on monitoring rules indicating the frequency of data collection, and periodically setting the frequency of data collection executed according to the monitoring rules.
[0142] In the server monitoring method, a server monitoring device collects data from compute 30 (a group of physical servers). Also, in the server monitoring method, the server monitoring device dynamically determines and periodically updates the monitoring collection frequency for each physical server 31 based on monitoring rules.
[0143] Therefore, when the server monitoring method periodically updates the monitoring collection frequency, it is possible to increase the interval between collections of data from the compute 30 (physical server group), and gradually reduce the power consumption related to monitoring.
[0144] Therefore, the server monitoring method can reduce the overhead and power consumption caused by real-time monitoring on a service platform where a wide variety of applications are installed on the hardware and the combination of these applications is dynamically changed.
[0145] (8) The program causes the computer to execute the following procedures: collect data from a group of physical servers having multiple physical servers 31 that realize computing equipped with virtual machines / containers, monitor the status of each physical server 31, update the collection mode of each data for each physical server 31 based on monitoring rules that indicate the frequency of data collection, and periodically set the frequency of data collection executed according to the monitoring rules.
[0146] In this program, the computer collects data from the compute 30 (a group of physical servers). In addition, in this program, the computer dynamically determines the monitoring collection frequency for each physical server 31 based on the monitoring rules, and periodically updates the frequency.
[0147] Therefore, when this program periodically updates the monitoring collection frequency, it is possible to increase the interval at which data is collected from the compute 30 (physical server group), and gradually reduce the power consumption related to monitoring.
[0148] Therefore, this program can reduce the overhead and power consumption caused by real-time monitoring on a service platform where a wide variety of applications are installed on the hardware and the combination of these applications is dynamically changed.
[0149] The present invention is not limited to the above-described embodiment, and many modifications can be made by a person having ordinary skill in the art within the technical concept of the present invention. [Explanation of symbols]
[0150] 1 Monitoring Department 2 Monitoring frequency control section 3 Database 3a Datastore 3b Rule setting database 4 Estimation part 5. Control decision section 6 Control Unit 7 Missing data processing section 10 Controller (server monitoring device) 30 Compute (physical servers) 31 physical servers 32 Data Collection Department 100 Server Monitoring System
Claims
1. a monitoring unit that collects data from a group of physical servers that includes a plurality of physical servers that realize computing on which virtual machines / containers are installed, and monitors the status of each of the physical servers; a rule setting database in which monitoring rules indicating data collection frequencies are set for each of the physical servers; a monitoring frequency control unit that updates a collection mode of each piece of data based on the monitoring rule corresponding to the physical server set in the rule setting database, and periodically sets a collection frequency of data executed according to the monitoring rule; Equipped with The monitoring unit Accepting a request for feedback from an application running on the virtual machine / container; The monitoring frequency control unit shortening the interval at which data is collected from the physical server that executes the application, thereby increasing the collection frequency, or setting the interval at which data is collected to a predetermined value, thereby fixing the collection frequency; A server monitoring device characterized by:
2. a monitoring unit that collects data from a group of physical servers that includes a plurality of physical servers that realize computing on which virtual machines / containers are installed, and monitors the status of each of the physical servers; a rule setting database in which monitoring rules indicating data collection frequencies are set for each of the physical servers; a monitoring frequency control unit that updates a collection mode of each piece of data based on the monitoring rule corresponding to the physical server set in the rule setting database, and periodically sets a collection frequency of data executed according to the monitoring rule; Equipped with The monitoring frequency control unit identifying a CPU core on which a data collection tool that collects data of the physical server is executed, and reducing the frequency of collection performed by the data collection tool based on the utilization rate of the identified CPU core; A server monitoring device characterized by:
3. a monitoring unit that collects data from a group of physical servers that includes a plurality of physical servers that realize computing on which virtual machines / containers are installed, and monitors the status of each of the physical servers; a rule setting database in which monitoring rules indicating data collection frequencies are set for each of the physical servers; a monitoring frequency control unit that updates a collection mode of each piece of data based on the monitoring rule corresponding to the physical server set in the rule setting database, and periodically sets a collection frequency of data executed according to the monitoring rule; Equipped with The monitoring frequency control unit identifying a CPU core on which a data collection tool that collects data of the physical server is executed, and, based on the utilization rate of the identified CPU core, if there is another CPU core whose utilization rate is lower than a predetermined threshold, changing the CPU core on which the data collection tool is executed to the other CPU core; A server monitoring device characterized by:
4. a monitoring unit that collects data from a group of physical servers that includes a plurality of physical servers that realize computing on which virtual machines / containers are installed, and monitors the status of each of the physical servers; a rule setting database in which monitoring rules indicating data collection frequencies are set for each of the physical servers; a monitoring frequency control unit that updates a collection mode of each piece of data based on the monitoring rule corresponding to the physical server set in the rule setting database, and periodically sets a collection frequency of data executed according to the monitoring rule; Equipped with an estimation unit that performs the construction of a predetermined model; a data store in which data necessary for constructing the model is collected and the collected data is stored; The monitoring unit Accepting a request to build a model from an application running on the virtual machine / container; The monitoring frequency control unit The model is constructed by the estimation unit based on the data stored in the data store, and if the number of data is insufficient or the accuracy of the data is not sufficient during the construction of the model, the data collection interval to the physical server that executes the application is shortened, and the collection frequency is increased. A server monitoring device characterized by:
5. a monitoring unit that collects data from a group of physical servers that includes a plurality of physical servers that realize computing on which virtual machines / containers are installed, and monitors the status of each of the physical servers; a rule setting database in which monitoring rules indicating data collection frequencies are set for each of the physical servers; a monitoring frequency control unit that updates a collection mode of each piece of data based on the monitoring rule corresponding to the physical server set in the rule setting database, and periodically sets a collection frequency of data executed according to the monitoring rule; a data collection unit that collects predetermined data of the physical server according to the data collection frequency set in the monitoring frequency control unit; Equipped with The monitoring unit Accepting a request for feedback from an application running on the virtual machine / container; The monitoring frequency control unit shortening the interval at which data is collected from the physical server that executes the application, thereby increasing the collection frequency, or setting the interval at which data is collected to a predetermined value, thereby fixing the collection frequency; A server monitoring system comprising:
6. The server monitoring device a step of collecting data on a group of physical servers including a plurality of physical servers that realize computing on which virtual machines / containers are installed, and monitoring the status of each of the physical servers; updating a data collection mode for each of the physical servers based on a monitoring rule indicating a data collection frequency, and periodically setting the data collection frequency executed by the monitoring rule; Run In the step of monitoring the status of each of the physical servers, a feedback request is received from an application running on the virtual machine / container; In the step of periodically setting the data collection frequency, the data collection interval for the physical server that executes the application is shortened to increase the collection frequency, or the data collection interval is set to a predetermined value to fix the collection frequency. A server monitoring method comprising:
7. On the computer, A procedure for collecting data on a group of physical servers having a plurality of physical servers that realize computing on which virtual machines / containers are installed, and monitoring the status of each of the physical servers; a step of updating a data collection mode for each of the physical servers based on a monitoring rule indicating a data collection frequency, and periodically setting the data collection frequency executed according to the monitoring rule; Execute In the step of monitoring the status of each of the physical servers, a feedback request is received from an application running on the virtual machine / container; In the step of periodically setting the data collection frequency, the data collection interval for the physical server that executes the application is shortened to increase the collection frequency, or the data collection interval is set to a predetermined value to fix the collection frequency. A program to make it happen.
Citation Information
Patent Citations
Method for determining collection start time of operation performance data
JP2007128122A
Information system
JP2015069449A
Monitoring control program, monitoring control system and monitoring control method
JP2017182160A
Information processing device, information processing system, and program
JP2020021292A
Rule-based adaptive monitoring of application performance
US20170168914A1