Data collection device, data collection method, and program

Abstract

This data collection device collects data from a cluster including a plurality of servers, and includes: a cluster management unit that manages configurations of servers in the cluster; a request processing unit that receives a request related to launch or deletion of controlled targets operating on the servers; an infrastructure management unit that launches or deletes the controlled targets in response to the request received by the request processing unit; and an infrastructure metric management unit that selects an infrastructure metric to be acquired. The infrastructure metric management unit selects the infrastructure metric to be acquired in units of cluster.

Description

Data collection device, data collection method and program

[0001] This application claims priority to Japanese Patent Application No. 2023-167646, filed on September 28, 2023, the contents of which are incorporated herein by reference.

[0002] In recent years, server and network functions have been virtualized, and multiple servers are now operated in clusters. This type of operation has improved scalability in scale-out and fault tolerance in the event of an abnormality. Furthermore, this technology has become an important foundation supporting IoT (Internet of Things) technology.

[0003] When managing infrastructure such as virtualized servers and network functions, how to acquire infrastructure information is important. Various methods are known for acquiring infrastructure information, and one of them is a method of acquiring infrastructure information from a kernel using an extended Berkley Packet Filter (eBPF) (see Patent Document 1).

[0004] Japanese Patent Application Laid-Open No. 2022-129899

[0005] According to such technology, information is acquired from a system call in a single server. However, with the advent of virtualization technology, systems are now operated on a cluster basis, and VMs (virtual machines), containers, and pods (pods) are added and moved within a cluster consisting of multiple servers. In other words, with the conventional configuration, information acquisition could not keep up with the addition and movement of VMs, containers, and pods within a server. In other words, with the conventional configuration, it can be said that the acquisition of infrastructure information could not keep up with changes in the operational status.

[0006] The present invention has been made in consideration of these circumstances, and its purpose is to provide a data collection device, a data collection method, and a program that can acquire necessary information even when controlled objects such as VMs, containers, and pods are added or moved within a cluster consisting of multiple servers.

[0007] (1) One aspect of the present invention is a data collection device that collects data from a cluster having a plurality of servers, the data collection device comprising: a cluster management unit that manages the configuration of the servers within the cluster; a request processing unit that receives requests for new launches and deletions of controlled objects running on the servers; an infrastructure management unit that launches and deletes the controlled objects in response to the requests received by the request processing unit; and an infrastructure metric management unit that selects targets for infrastructure metric acquisition, the infrastructure metric management unit selecting targets for infrastructure metric acquisition on a cluster basis. (2) Another aspect of the present invention is the data collection device of (1), wherein the infrastructure metric management unit further comprises an SLA management unit that manages the association of information used to acquire infrastructure information for each type of controlled object; a target kernel selection unit that acquires information used to acquire infrastructure information from the SLA management unit, selects a kernel and source code of an executable program to be executed by the kernel, and performs processing to enable infrastructure information acquisition; and a kernel data periodic acquisition unit that acquires infrastructure information by executing the executable program selected by the target kernel selection unit. (3) Furthermore, one aspect of the present invention is that in the data collection device described above in (2), the infrastructure information associated by the SLA management unit includes at least a monitoring interval, and the kernel data periodic acquisition unit acquires the infrastructure information by executing the execution program selected by the target kernel selection unit based on the monitoring interval corresponding to the type of controlled object.(4) Another aspect of the present invention is a data collection method for collecting data from a cluster having multiple servers, the data collection method comprising: a cluster management step for managing the configuration of the servers within the cluster; a request processing step for receiving requests for the new launch and deletion of controlled objects running on the servers; an infrastructure management step for launching and deleting the controlled objects in response to the requests received in the request processing step; and an infrastructure management step for selecting targets for infrastructure metric acquisition, wherein the infrastructure management step selects targets for infrastructure metric acquisition on a cluster basis. (5) Another aspect of the present invention is a program for causing a computer to collect data from a cluster having multiple servers, the program causing a computer to execute a cluster management step for managing the configuration of the servers within the cluster; a request processing step for receiving requests for the new launch and deletion of controlled objects running on the servers; an infrastructure management step for launching and deleting the controlled objects in response to the requests received in the request processing step; and an infrastructure management step for selecting targets for infrastructure metric acquisition, wherein the infrastructure management step selects targets for infrastructure metric acquisition on a cluster basis.

[0008] According to the present invention, it is possible to obtain the necessary information even when a controlled object such as a VM, container, or pod is added or moved within a cluster consisting of multiple servers.

[0009] FIG. 1 is a functional configuration diagram showing an example of the functional configuration of an entire system according to an embodiment. FIG. 1 is a functional configuration diagram showing an example of the functional configuration of a virtualization infrastructure orchestrator according to the embodiment. FIG. 1 is a functional configuration diagram showing an example of the functional configuration of an infrastructure manager according to the embodiment. FIG. 2 is a diagram for explaining an example of management by an SLA manager according to the embodiment. FIG. 3 is a diagram for explaining an example of execution program selection by a target kernel selector according to the embodiment. FIG. 4 is a diagram for explaining an example of an output format in the infrastructure manager according to the embodiment. FIG. 5 is a diagram for explaining an example of cluster management by a cluster manager according to the embodiment. FIG. 6 is a flowchart showing an example of processing of the entire system when a controlled object is started up according to the embodiment. FIG. 7 is a flowchart showing an example of processing of the orchestrator when a controlled object is started up according to the embodiment. FIG. 8 is a flowchart showing an example of processing of the infrastructure manager when a controlled object is started up according to the embodiment. FIG. 9 is a flowchart showing an example of processing of the entire system when infrastructure information of a controlled object is changed by user specification according to the embodiment. FIG. 10 is a flowchart showing an example of processing of the orchestrator when infrastructure information of a controlled object is changed due to inter-cluster server migration of the controlled object according to the embodiment. FIG. 11 is a block diagram showing an example of the internal configuration of a data collection device according to the embodiment.

[0010] A data collection device, a data collection method, and a program according to preferred embodiments of the present invention will be described in detail below with reference to the accompanying drawings. Note that the present invention is not limited to these embodiments and includes various modifications and improvements. In other words, the components described below include those that would be easily conceivable to a person skilled in the art or that are substantially identical, and the components described below can be combined as appropriate. Furthermore, various omissions, substitutions, or modifications of the components can be made without departing from the spirit of the present invention. Furthermore, in the drawings, the scale and number of components may differ from the scale and number of the actual structures to make each configuration easier to understand.

[0011] [Embodiment] Hereinafter, an embodiment of the present invention will be described with reference to the drawings. First, an example of the functional configuration of a system according to this embodiment will be described with reference to Figs.

[0012] FIG. 1 is a functional configuration diagram showing an example of the functional configuration of the entire system according to an embodiment. An example of the functional configuration of the entire system 1 will be described with reference to the diagram. The system 1 manages controlled objects in a cluster made up of multiple servers. Specifically, the system 1 includes an OSS / BSS 2, a controller 3, a cluster 4, a virtualization platform orchestrator 5, an AI / ML execution unit 6, and a user device 7. By adopting this configuration, the system 1 manages controlled objects present in the cluster made up of multiple servers via the OSS / BSS 2.

[0013] Cluster 4 represents a group of servers that make up system 1. Cluster 4 includes at least a plurality of servers. In a specific illustrated example, cluster 4 includes a first server 41 and a second server 46. Each server includes a kernel and a plurality of controlled objects. Controlled objects are objects that are operated and managed. Examples of controlled objects include VMs (virtual machines), containers, and pods. Controlled objects may be, for example, applications. Servers represent servers on which controlled objects are running.

[0014] Specifically, the first server 41 includes a kernel 42. The kernel 42 includes a first measurement function 43. The first server 41 also includes, as control targets, a first controlled target 441, a second controlled target 442, ..., and an n-th controlled target 44n. In the following description, when the multiple controlled targets included in the first server 41 are not distinguished, they may be referred to as controlled targets 44. The second server 46 also includes a kernel 47. The kernel 47 includes a second measurement function 48. The second server 46 also includes, as control targets, a first controlled target 491, a second controlled target 492, ..., and an n-th controlled target 49n. In the following description, when the multiple controlled targets included in the second server 46 are not distinguished, they may be referred to as controlled targets 49.

[0015] In the OSS / BSS2, OSS stands for Operation Support System, and BSS stands for Business Support System. The OSS / BSS2 is an overall operation management system. The OSS / BSS2 receives requests from users and requests the controller 3 to start up controlled objects, etc.

[0016] The controller 3 performs processing in accordance with the request received from the OSS / BSS 2. In this embodiment, the controller 3 transfers to the virtualization infrastructure orchestrator 5 a request regarding the controlled object and infrastructure information to be acquired.

[0017] The virtualization platform orchestrator 5 receives requests from the controller 3. The virtualization platform orchestrator 5 starts and manages the controlled objects according to the received information. The virtualization platform orchestrator 5 also enables measurement functions (such as the first measurement function 43 and second measurement function 48 described above) according to the infrastructure information requested by the controller 3. The detailed functions of the virtualization platform orchestrator 5 will be described later with reference to FIG. 2.

[0018] The AI / ML execution unit 6 performs machine learning (ML) processing using AI (artificial intelligence). The AI / ML execution unit 6 acquires information from the virtualization platform orchestrator 5 and performs learning based on the acquired information. The learning method may be, for example, supervised learning. It is assumed that the AI / ML execution unit 6 learns, for example, server data under normal conditions. The AI / ML execution unit 6 may detect that abnormal data has been sent in the inference stage based on the learned server data under normal conditions. The inference result is output to a predetermined device such as a user device 7. The output may be in the form of an alarm or the like.

[0019] The user device 7 is a device operated by a user who uses the system 1 .

[0020] 2 is a functional configuration diagram showing an example of the functional configuration of a virtualization platform orchestrator according to this embodiment. An example of the detailed functional configuration of the virtualization platform orchestrator 5 will be described with reference to the same figure. The virtualization platform orchestrator 5 includes a request storage DB 51, a request processing unit 52, an infrastructure management unit 53, an infrastructure metric management unit 54, and a cluster management unit 55. The virtualization platform orchestrator 5 collects data from a cluster 4 including multiple servers. In other words, the virtualization platform orchestrator 5, or a configuration including the virtualization platform orchestrator 5, can also be referred to as a data collection device.

[0021] The request processing unit 52 receives requests from the controller 3. The request processing unit 52 also transmits the received requests to the infrastructure management unit 53. The request processing unit 52 also stores the received requests in the request storage DB 51 one by one.

[0022] The request storage DB 51 acquires requests from the request processing unit 52 and stores the acquired requests. In other words, the request storage DB 51 stores the contents of requests that have been processed in the past. Here, the controlled object according to this embodiment may move between servers. For example, in the example shown in the figure, the first controlled object 441 may move from the first server 41 to the second server 46. In this way, when the operating server of the controlled object is changed, or when the request contents are to be transferred to another server, the contents stored in the request storage DB 51 are referenced.

[0023] The infrastructure management unit 53 starts up the controlled object, acquires the operating status, deletes the controlled object, etc. in response to the request received by the request processing unit 52. Note that the infrastructure management unit 53 may be realized by using existing technology.

[0024] The infrastructure metric manager 54 selects the infrastructure metric acquisition target. In other words, the infrastructure metric manager 54 determines which information to acquire as infrastructure information. Examples of infrastructure metric acquisition targets include CPU usage, memory usage, and TCP information (such as the number of TCP connections). The infrastructure metric manager 54 also determines the data output format for the AI / ML execution unit 6.

[0025] Furthermore, the infrastructure metric management unit 54 performs processes for starting, changing, and stopping the acquisition of infrastructure metrics. The timing for starting the acquisition of infrastructure metrics may be the timing when the controlled object is started up. The timing for changing the acquisition of infrastructure metrics may be the timing when there is a change in state. The timing for stopping the infrastructure metrics may be the timing when the controlled object is moved between servers or when the controlled object is stopped. When the controlled object is moved between servers, a stop process is performed on the server from which the control object is moved, and a start process (sometimes called a start process or a launch process) is performed on the server to which the control object is moved. Details of the processing by the infrastructure metric management unit 54 will be described later with reference to FIG. 3.

[0026] The cluster management unit 55 manages how the servers are configured in the cluster 4. The management targets of the cluster management unit 55 may include how many and what types of servers are present in the cluster 4, and further, what controlled objects such as VMs, containers, and pods are running on each server. The operating status of the controlled objects may be IP addresses or the number of pods. Specifically, a situation may be assumed in which the first server 41 has one pod with IP 10.0.0.1, and the second server 46 has no pods.

[0027] 3 is a functional configuration diagram showing an example of the functional configuration of the infrastructure metric manager according to this embodiment. An example of the detailed functional configuration of the infrastructure metric manager 54 will be described with reference to the same figure. The infrastructure metric manager 54 includes a target kernel selector 541, a kernel data periodic acquirer 542, an output data generator 543, and an SLA manager 544.

[0028] The SLA of the SLA management unit 544 is a Service Level Agreement. The SLA management unit 544 manages the association of necessary infrastructure information based on the type of controlled object. The type of controlled object may be, for example, an HTTP server or an internal DB (database). By specifying the SLA level in this way, it is possible to define the infrastructure information to be checked without specifying the infrastructure information individually.

[0029] 4 is a diagram illustrating an example of management by the SLA management unit according to this embodiment. An example of management by the SLA management unit 544 will be described with reference to the diagram. The diagram illustrates an example of a mobile device. The diagram shows SLA information for each NF (Network Function). An NF is an example of a function that is launched within a pod.

[0030] As shown in the figure, the monitoring interval for AMF (Access and Mobility Management Function) is 30 seconds, and the SLA information associated with it is "tcpdrop", "tcpretrans", "CPUusage", and "Memoryusage". In this case, when AMF is started up as a controlled object, the information indicated in this SLA information is obtained. Note that the monitoring interval for UDR (User Data Repository) is 10 seconds, and the SLA information associated with it is "tcpdrop", "tcpretrans", "CPUusage", "Memoryusage", and "Storageusage". The monitoring interval of the PCF (Policy Control Function) is 10 seconds, and the SLA information associated with it is "CPU usage" and "Memory usage." Returning to FIG. 3, the functional configuration of the infrastructure metric manager 54 will be described further.

[0031] The target kernel selection unit 541 obtains information regarding infrastructure information to be obtained from the SLA information from the SLA management unit 544. The target kernel selection unit 541 selects a target kernel for obtaining infrastructure information and selects the source code of the execution program to be executed by the kernel.

[0032] FIG. 5 is a diagram illustrating an example of execution program selection by the target kernel selection unit according to this embodiment. An example of execution program selection by the target kernel selection unit 541 will be described with reference to FIG. In FIG. 5, trace points, kernel versions, and platform information are associated with each other. This association information may be stored by the target kernel selection unit 541. Specifically, in FIG. 5, programs are associated with each kernel version for "tcpdrop" and "tclife." The target kernel selection unit 541 refers to the association information to determine which program to embed. Thereafter, the target kernel selection unit 541 enables infrastructure data acquisition for the controlled target. Returning to FIG. 3, the functional configuration of the infrastructure metric management unit 54 will be described further.

[0033] The kernel data periodic acquisition unit 542 is responsible for acquiring actual data after activation by the target kernel selection unit 541. Specifically, the kernel data periodic acquisition unit 542 receives the infrastructure information acquisition interval (see FIG. 4 ) determined from the SLA information, and acquires the infrastructure information based on the time interval. For example, the acquisition interval may be 30 seconds when AMF is activated, 10 seconds when UDR is activated, and 10 seconds when PCF is activated.

[0034] The output data generation unit 543 generates output data and transmits the data. The output data generation unit 543 holds templates for generating output data, and determines the template for output data based on the SLA information and cluster information.

[0035] FIG. 6 is a diagram showing an example of an output format in the infrastructure management unit according to this embodiment. An example of a template for generating output data held by the output data generation unit 543 will be described with reference to the same figure. When the trace point is "tcpdrop", the data format is "JSON (JavaScript Object Notation)", and the data is output as a "total value (i.e., the total number of dropped items)". When the trace point is "tcplife", the data format is "JSON", and the data is output as an "average value (i.e., the average lifespan)". When the trace point is "CPUusage", the data format is "XML (Extensible Markup Language)", and the data is output as a "maximum value". Returning to FIG. 3, the functional configuration of the infrastructure management unit 54 will be continued.

[0036] FIG. 7 is a diagram illustrating an example of cluster management by the cluster management unit according to this embodiment. The cluster management unit may hold correspondence information as shown in the figure. Specifically, the correspondence information associates NFs, IP addresses, NF names, and activation clusters. Specifically, the IP address of the NF "AMF" is "10.0.0.1", the NF name is "fujimino_amf_01", and the activation cluster is "fujimino_cluster_01". Furthermore, the IP address of the NF "AMF" is "10.0.0.2", the NF name is "fujimino_amf_02", and the activation cluster is "fujimino_cluster_02". The IP address of the NF "UPF" is "10.0.0.3", the NF name is "fujimino_upf_01", and the activation cluster is "fujimino_cluster_02".

[0037] Next, an example of a series of processes performed by the system according to this embodiment will be described with reference to the flowcharts shown in FIGS.

[0038] 8 is a flowchart showing an example of the overall system processing when a controlled object according to this embodiment is started up. First, with reference to the same figure, an example of the overall system processing when a new controlled object is started up will be described. The new controlled object is started up by a user via the OSS / BSS 2. More specifically, the controlled object is started up via the controller 3 and the virtualization platform orchestrator 5.

[0039] (Step S11) First, the OSS / BSS 2 sends the new startup instruction received from the user and the infrastructure information to be monitored to the controller 3. The infrastructure information to be monitored can be individually provided to the OSS / BSS 2, but can also be omitted. If omitted, the virtualization platform orchestrator 5 makes the decision and executes the infrastructure information acquisition process.

[0040] (Step S12) Next, the controller 3 transfers the startup information of the controlled object (e.g., creating one AMF in the first server 41) and infrastructure information to be monitored (e.g., acquiring TCP drop metrics at 10-second intervals) in the request received from the OSS / BSS 2 to the virtualization infrastructure orchestrator 5. The controller 3 may process the other information in accordance with specifications defined on the system 1.

[0041] (Step S13) Next, in order to determine the infrastructure information to be acquired, the virtualization platform orchestrator 5 determines the startup information of the controlled target received from the controller 3 and the infrastructure information to be monitored by referring to the operation status of the servers in the cluster 4. Details of the internal processing within the virtualization platform orchestrator 5 related to determining the infrastructure information will be described later with reference to FIG. 9.

[0042] (Step S14) After the acquisition information is determined in step S13, the virtualization infrastructure orchestrator 5 (more specifically, the infrastructure management unit 54) performs the startup processing of the controlled object based on the startup information of the controlled object (for example, creating one AMF on the first server 41).

[0043] (Step S15) Based on the infrastructure information of the controlled target determined in step S13, the acquisition of infrastructure information is enabled at the controlled target. The process of enabling infrastructure information acquisition is, for example, a process performed by the target kernel selection unit 541, and is a process such as starting an acquisition execution program for kfree_skb at 10-second intervals to acquire tcpdrop metrics on the first server 41 that has started up amf.

[0044] (Step S16) Next, the virtualization infrastructure orchestrator 5 acquires infrastructure information from the controlled object.

[0045] 9 is a flowchart showing an example of the processing of the orchestrator when a controlled object is started up according to this embodiment. With reference to the same figure, an example of the processing of the orchestrator when a controlled object is started up will be described. Specifically, the flow shown in the same figure is a detailed flow of step S13 described above.

[0046] (Step S21) First, the request processing unit 52 stores in the request storage DB 51 the request for acquiring information on new start-up of a controlled object and information on infrastructure, which is received via the controller 3.

[0047] (Step S22) Next, the request processing unit 52 transfers the new startup information of the controlled object out of the new startup information of the controlled object and the infrastructure information acquisition information received via the controller 3 to the infrastructure management unit 53. Note that steps S21 and S22 may be processed in parallel.

[0048] (Step S23) Next, the infrastructure management unit 53 newly launches the controlled object on the cluster 4. A specific example of the process performed in step S23 is a process in which Kubernetes deploys one pod of amf to the first server 41.

[0049] (Step S24) Next, the newly launched controlled target (in the illustrated example, controlled target 44) notifies information such as the generating server and parameters to the cluster management unit 55. Specific examples of the information notified in step S24 include information such as "management IP: 10.0.0.1," "pod name amf_1," and "server name A."

[0050] (Step S25) Furthermore, the request processing unit 52 transfers the infrastructure information acquisition information out of the received new launch information and infrastructure information acquisition information related to the controlled object to the infrastructure metric management unit 54. Note that the processing in step S25 may be performed in parallel with the processing in steps S21 and S22.

[0051] (Step S26) Next, the inframetric manager 54 inquires of the cluster manager 55 about information on the controlled objects on the cluster. An example of a specific inquiry result made in step S26 may be, for example, information that there are no pods running on the first server 41.

[0052] (Step S27) Next, the infrastructure metric manager 54 checks the information to be acquired, the acquisition interval, and the information required to start acquiring infrastructure information in order to acquire infrastructure information. Details of the process related to acquiring infrastructure information will be described later with reference to FIG. 10.

[0053] (Step S28) Next, the infrastructure metric manager 54 enables infrastructure information acquisition on the server on which the controlled object is running. An example of a specific query result performed in step S28 may be to start an execution program for acquiring tcpdrop metrics at 10-second intervals for kfree_skb on the first server 41 that has started up amf.

[0054] 10 is a flowchart showing an example of the processing of the infrastructure metric manager when a controlled object according to this embodiment is started up. An example of the processing related to the acquisition of infrastructure information will be described with reference to the same figure. The flow shown in the same figure is specifically a detailed flow of step S27 described above.

[0055] (Step S31) First, based on information about a newly launched controlled target, the infrastructure information to be acquired is confirmed with the SLA management unit 544. This confirmation process may be performed by referencing correspondence information such as that shown in FIG. 4. Note that the information about the newly launched controlled target is the information acquired in step S26, and specific examples include information such as "management IP: 10.0.0.1," "pod name amf_1," and "server name A." The infrastructure information to be acquired may be, for example, tcpdrop metrics acquired at 10-second intervals.

[0056] (Step S32) Next, the infrastructure metric manager 54 checks the cluster information and determines the infrastructure information checked in step S31 as the information to be acquired. Specifically, the cluster information may be information such as "there are no existing pods on the first server 41." As another example, if a similar service is running on cluster 4, for example, if services such as "management IP: 10.0.0.2," "pod name amf_2," and "server name A" are already running, the information related to amf is already operational, and the problem can be resolved using the existing information. In such a case, the infrastructure metric manager 54 does not need to acquire new infrastructure information or make any changes to the existing information.

[0057] That is, according to this embodiment, whether or not a control target is already running is determined on a cluster-by-cluster basis, and a specific control target is newly started on a server on which the specific control target is running, but the specific control target is not newly started on a server on which the specific control target is not running. By performing such processing, this embodiment makes it possible to realize management on a cluster-by-cluster basis.

[0058] (Step S33) Next, the infrastructure metric manager 54 queries the target kernel selector 541 for the infrastructure information to be acquired and determines which program code to apply (see FIG. 5). For example, the infrastructure metric manager 54 determines that the program code "tcpdrop_v1.c" should be applied to the trace point "kfree_skb."

[0059] (Step S34) Next, the target kernel selection unit 541 starts the operation of acquiring kernel data for the controlled target based on the infrastructure information acquisition method determined in step S33. For example, the target kernel selection unit 541 applies the program code “tcpdrop_v1.c” to the trace point “kfree_skb” of the first server 41, and starts the operation of acquiring kernel data for the controlled target.

[0060] (Step S35) The infrastructure metric manager 54 also notifies the kernel data periodic acquirer 542 of the acquisition interval (e.g., 10 seconds) determined in step S32. Since this data acquisition interval is common to multiple infrastructure information acquisitions, the minimum value may be selected. For example, if the tcpdrop metric is acquired at 10 seconds and the tclife metric is acquired at 20 seconds, the data acquisition interval will be 10 seconds. Furthermore, if the acquisition of the tcpdrop metric is no longer necessary, the data acquisition interval may be changed to 20 seconds.

[0061] (Step S36) In this case, the kernel data periodic acquisition unit 542 periodically acquires infrastructure information from the controlled object based on the acquisition interval of the updated data.

[0062] (Step S37) The infrastructure metric manager 54 also determines the output format based on the acquired information targeted by the SLA information. As a specific example, the infrastructure metric manager 54 outputs the following (1) based on information that server A acquires tcpdrop metrics at 10-second intervals:

[0063] {server:serverA, tcpdrop:10, time:12:00:10}...(1)

[0064] (Step S38) Next, the output data generation unit 543 processes the infrastructure information into the output format determined in step S37 and transmits it to the target AI / ML execution unit 6.

[0065] 11 is a flowchart showing an example of the processing of the entire system when infrastructure information of a controlled object is changed by a user according to this embodiment. With reference to the same figure, the flow of the infrastructure information acquisition processing when the infrastructure information acquisition information is changed by the user while the infrastructure information acquisition is in progress will be described. For example, the processing assumed in this flowchart may be when the user stops the acquisition of tcpdrop metrics.

[0066] (Step S41) First, a change in infrastructure information acquisition is notified from the OSS / BSS 2 to the controller 3. This notification may be, for example, a notification to stop the first server 41 from acquiring tcpdrop metrics.

[0067] (Step S42) Next, the controller 3 transfers the infrastructure information including the measurement function to be changed from the request received from the OSS / BSS 2 to the virtualization infrastructure orchestrator 5. For other information from the received request, the controller 3 performs data processing in accordance with the specifications defined on the system 1.

[0068] (Step S43) Next, in order to determine the infrastructure information to be changed, the virtualization platform orchestrator 5 determines the controlled target received from the controller 3 and the infrastructure information to be monitored by referring to the operation status of the servers in the cluster 4. Detailed processing within the virtualization platform orchestrator 5 related to determining the infrastructure information may be similar to the processing described with reference to FIGS. 9 and 10 .

[0069] (Step S44) Next, the virtualization platform orchestrator 5 enables or disables the change in infrastructure information measurement function determined in step S43 for the controlled object. For example, the virtualization platform orchestrator 5 may perform processing to delete the application of tcpdrop_v1.c to the kfree_skb trace point resulting from tcpdrop acquisition of the first server 41. The virtualization platform orchestrator 5 may also perform processing to change the periodic acquisition interval from 10 seconds to 20 seconds.

[0070] (Step S45) Furthermore, the controlled target periodically transmits infrastructure information to the virtualization infrastructure orchestrator 5 based on the changed infrastructure information acquisition information.

[0071] 12 is a flowchart showing an example of the processing of the orchestrator when infrastructure information of a controlled object changes due to inter-cluster server migration of the controlled object according to this embodiment. With reference to this figure, the flow of the infrastructure information acquisition process when infrastructure information acquisition changes due to a change in the state of the controlled object while infrastructure information acquisition is in progress will be described. An example of the processing envisioned by this flowchart is a case in which an AMF pod is moved to another server due to an error in a specific server. Here, when triggered by a change in the state of the controlled object, the processing starts not in the OSS / BSS2 but in the controlled object, so the explanation will be given with reference to a flowchart created based on a functional configuration diagram within the virtualization platform orchestrator 5.

[0072] In the explanation given with reference to the same figure, the controlled object is assumed to be moved from server A to server B, and the controlled object that is stopped on the first server 41 may be referred to as controlled object 44, and the controlled object that is newly started up on the second server 46 may be referred to as controlled object 49.

[0073] (Step S51) First, the controlled object 44 notifies the infrastructure management unit 53 that the controlled object 44 has stopped. That is, the controlled object notifies the cluster 4.

[0074] (Step S52) Next, the controlled object 44 notifies the cluster management unit 55 that the controlled object 44 has stopped. The notification of the stoppage may include, for example, information that one of the amfs of the first server 41 has stopped.

[0075] (Step S53) In response to the shutdown of the controlled object 44, the infrastructure management unit 53 performs a process of starting up a new controlled object. For example, the infrastructure management unit 53 starts up one amf on the second server 46.

[0076] (Step S54) Next, the controlled object 49 notifies the cluster management unit 55 that the controlled object 49 has been started up. This notification may include information such as IP: 10.0.0.2, pod name amf_2, and second server 46. That is, through the series of processes from step S51 to step S54, the cluster management unit 55 can obtain information that the controlled object 44 has stopped and the controlled object 49 has been newly started up.

[0077] (Step S55) If there is a change, the cluster management unit 55 notifies the infrastructure management unit 54 of the change in the state of the controlled object.

[0078] (Step S56) Next, the cluster management unit 55 makes an inquiry to the request storage DB 51, checks the request made when the controlled object 49 was created, and checks the infrastructure information that needs to be acquired.

[0079] (Step S57) Next, the infrastructure metric manager 54 checks the information to be acquired, the time interval, and the information required to start acquiring the information, based on the infrastructure information. The infrastructure information checking process may be the same as the series of processes described with reference to FIG. 10.

[0080] According to this embodiment, since management is performed in cluster units, even if the control target is moved from a specific server to another server, it can be followed.

[0081] FIG. 13 is a block diagram showing an example of the internal configuration of the data collection device of this embodiment. At least some of the functions of the data collection device can be implemented using a computer. As shown in the figure, the computer includes a central processing unit 901, a RAM 902, an input / output port 903, input / output devices 904 and 905, and a bus 906. The computer itself can be implemented using existing technology. The central processing unit 901 executes instructions contained in a program read from the RAM 902 or the like. In accordance with each instruction, the central processing unit 901 writes data to the RAM 902, reads data from the RAM 902, and performs arithmetic and logical operations. The RAM 902 stores data and programs. Each element included in the RAM 902 has an address and can be accessed using the address. Note that RAM is an abbreviation for "random access memory." The input / output port 903 is a port through which the central processing unit 901 exchanges data with external input / output devices. The input / output devices 904 and 905 are input / output devices. The input / output devices 904 and 905 exchange data with the central processing unit 901 via the input / output port 903. The bus 906 is a common communication path used within the computer. For example, the central processing unit 901 reads and writes data from and to the RAM 902 via the bus 906. Also, for example, the central processing unit 901 accesses the input / output port via the bus 906. Furthermore, all or part of the functional units provided in the data collection device may be realized using hardware such as an ASIC, a PLD, or an FPGA. Furthermore, all or part of the functional units may be realized by a combination of software and hardware.

[0082] [Summary of the Embodiment] According to this embodiment, the data collection device collects data from a cluster 4 including multiple servers. The data collection device includes a cluster management unit 55 to manage the configuration of the servers within the cluster 4, a request processing unit 52 to accept requests for launching or deleting controlled objects running on the servers, an infrastructure management unit 53 to launch or delete controlled objects in response to requests accepted by the request processing unit 52, and an infrastructure metric management unit 54 to select targets for infrastructure metric acquisition on a cluster-by-cluster basis. That is, according to this embodiment, management is achieved on a cluster-by-cluster basis rather than on a single server basis, and infrastructure information is acquired on a cluster-by-cluster basis. Therefore, according to this embodiment, necessary information can be acquired even when controlled objects such as VMs, containers, and pods are added or moved within a cluster consisting of multiple servers.

[0083] Furthermore, according to this embodiment, infrastructure information can be acquired for a cluster configuration rather than for a single server, so the scope of infrastructure information utilization can be expanded to include virtualization technology. Furthermore, according to this embodiment, the acquisition of infrastructure information can be varied according to the status of the servers in the cluster, so CPU and memory consumption can be reduced and the system can operate stably.

[0084] Although an embodiment of the present invention has been described in detail above with reference to the drawings, the specific configuration is not limited to this embodiment, and design changes and the like are also included within the scope that does not deviate from the gist of the present invention.

[0085] Furthermore, a computer program for implementing the functions of each of the above-described devices may be recorded on a computer-readable recording medium, and the program may be read and executed by a computer system. The term "computer system" may also include hardware such as an OS and peripheral devices. The term "computer-readable recording medium" refers to a flexible disk, a magneto-optical disk, a ROM, a writable nonvolatile memory such as a flash memory, a portable medium such as a DVD (Digital Versatile Disc), or a storage device such as a hard disk built into a computer system.

[0086] Furthermore, the term "computer-readable recording medium" also includes a storage medium that stores a program for a certain period of time, such as a volatile memory (e.g., DRAM (Dynamic Random Access Memory)) within a computer system that serves as a server or client when the program is transmitted via a network such as the Internet or a communication line such as a telephone line. The program may also be transmitted from a computer system that stores the program in a storage device or the like to another computer system via a transmission medium or by transmission waves within the transmission medium. Here, the "transmission medium" that transmits the program refers to a medium that has the function of transmitting information, such as a network (communication network) such as the Internet or a communication line (communication line) such as a telephone line. The program may also be a program that realizes part of the aforementioned functions. Furthermore, the program may be a so-called differential file (differential program) that can realize the aforementioned functions in combination with a program already recorded in the computer system.

[0087] According to the present invention, necessary information can be acquired even when a controlled object such as a VM, a container, or a pod is added or moved within a cluster made up of multiple servers.

[0088] DESCRIPTION OF SYMBOLS 1...System, 2...OSS / BSS, 3...Controller, 4...Cluster, 5...Virtualization infrastructure orchestrator, 6...AI / ML execution unit, 7...User device, 41...First server, 42...Kernel, 43...First measurement function, 44...Controlled object, 46...Second server, 47...Kernel, 48...Second measurement function, 49...Controlled object, 51...Request storage DB, 52...Request processing unit, 53...Infrastructure management unit, 54...Infrastructure metric management unit, 55...Cluster management unit, 541...Target kernel selection unit, 542...Kernel data periodic acquisition unit, 543...Output data generation unit, 544...SLA management unit

Claims

1. A data collection device that collects data from a cluster having multiple servers, comprising: a cluster management unit that manages the configuration of the servers within the cluster; a request processing unit that accepts requests for new launch and deletion of controlled objects operating on the servers; an infrastructure management unit that launches and deletes the controlled objects in response to the requests accepted by the request processing unit; and an infrastructure metric management unit that selects targets for obtaining infrastructure metrics, wherein the infrastructure metric management unit selects targets for obtaining infrastructure metrics on a cluster basis.

2. The data collection device of claim 1, wherein the infrastructure metric management unit further comprises: an SLA management unit that manages the correspondence of information used to acquire infrastructure information for each type of controlled object; a target kernel selection unit that acquires information used to acquire infrastructure information from the SLA management unit, selects a kernel and source code of an executable program to be executed by the kernel, and performs an enable process for infrastructure information acquisition; and a kernel data periodic acquisition unit that acquires infrastructure information by executing the executable program selected by the target kernel selection unit.

3. The data collection device of claim 2, wherein the infrastructure information associated by the SLA management unit includes at least a monitoring interval, and the kernel data periodic acquisition unit acquires the infrastructure information by executing an execution program selected by the target kernel selection unit based on a monitoring interval corresponding to the type of controlled object.

4. A data collection method for collecting data from a cluster having multiple servers, comprising: a cluster management process for managing the configuration of servers within the cluster; a request processing process for accepting requests for new launch and deletion of controlled objects operating on the servers; an infrastructure management process for launching and deleting the controlled objects in response to the requests accepted in the request processing process; and an infrastructure metric management process for selecting targets for obtaining infrastructure metrics, wherein the infrastructure metric management process selects targets for obtaining infrastructure metrics on a cluster basis.

5. A program that causes a computer to collect data from a cluster having multiple servers, the program executing a cluster management step of managing the configuration of servers within the cluster, a request processing step of accepting requests for new launch and deletion of controlled objects running on the servers, an infrastructure management step of launching and deleting the controlled objects in response to the requests accepted in the request processing step, and an infrastructure metric management step of selecting targets for obtaining infrastructure metrics, wherein the infrastructure metric management step selects targets for obtaining infrastructure metrics on a cluster basis.

Images