An event-based cloud resource metering method and system

Abstract

The present invention discloses an event-based cloud resource metering method and system, belonging to the field of data information technology. The method includes: listening for events of load request operations, where the events include user ID, load name, load type, operation, and time; determining whether the event is a user event; if so, collecting monitoring data of cloud resources according to the dimension of the load; and metering the usage amount of cloud resources based on the monitoring data. By combining the events of user load request operations with the monitoring data of cloud resources, the data statistics for metering are realized, improving the accuracy and reliability of metering data. It solves problems such as large deviations in traditional metering and billing methods, provides a more flexible and transparent billing model, and users can also pay according to the actual usage situation, avoiding resource waste and unfair metering and billing.

Description

Technical Field

[0001] The present invention relates to the field of data information technology, and particularly relates to an event-based cloud resource metering method and system. Background Art

[0002] As an underlying public resource, computing power infrastructure can be provided for multiple organizations or users to use simultaneously. With the development of technologies such as artificial intelligence, large models, and scientific computing, the demand for and dependence on the computing power infrastructure of cloud computing are growing rapidly. As of now, from the perspective of computing devices, in the past six years in China, the cumulative shipments of general-purpose servers exceeded 20.91 million, and the shipments of AI servers were 820,000. The total computing power scale reached 302 EFlops, accounting for 33% of the global total, with a growth rate of 50%. Among them, the intelligent computing power maintained a stable and high growth rate, reaching 72%.

[0003] Achieving refined management and reasonable allocation of computing power infrastructure and its computing power resources is an effective way to ensure the efficient use of computing power infrastructure. Metering and billing of computing power infrastructure are very important links. With the rapid development and wide application of cloud computing technology, cloud-native applications have become the preferred architecture for enterprises to build and deploy modern application programs. Cloud-native applications utilize technologies such as containerization, microservices architecture, service mesh, continuous delivery, and infrastructure as code to achieve high scalability, flexibility, and elasticity, and can quickly respond to market demands and changes. Currently, more and more data centers and intelligent computing centers adopt cloud-native architecture as the management method of computing power resources.

[0004] There are currently two mainstream metering and billing methods. One is for scenarios with stable business operations. Users can choose to be billed on an annual or monthly basis, that is, the cost of a certain amount of resources within a fixed time period. Regardless of whether the user actually uses the resources during this period, the cost is fixed. The other is pay-per-use, that is, a certain amount of resources are set for the user, and the user is billed when the machine is turned on and the billing stops when the user shuts down the machine. Generally, for task-based scenarios, that is, scenarios where the task operation is not fixed, users can choose this method for metering and billing.

[0005] These methods usually bill based on pre-configured computing power, storage, and network resources and cannot reflect the dynamic changes in actual resource usage. Due to the characteristics of cloud-native applications such as high concurrency, dynamic scaling, and event-driven, especially in some scenarios of dynamic resource over-allocation and elastic scaling, traditional metering and billing methods often show large deviations. If the metering and billing are less, it will lead to serious losses in the entire computing power infrastructure; if the metering and billing are more, it will lead to a large number of user complaints and a decline in the user experience. Therefore, a fine-grained metering and billing method in the cloud-native scenario becomes particularly important. Summary of the Invention

[0006] In view of the above technical problems existing in the prior art, the present invention provides an event-based cloud resource metering method and system, which combines events with monitoring data to meter cloud resources and improve the accuracy and reliability of metering results.

[0007] The present invention discloses an event-based cloud resource metering method, including the following steps: listening for events of load request operations, where the events include user ID, load name, load type, operation, and time; determining whether the event is a user event; if so, collecting monitoring data of cloud resources according to the dimensions of the load; and metering the usage of cloud resources according to the monitoring data.

[0008] Preferably, the method further includes a billing method: calculating the dimension cost according to the usage and unit price of the monitoring data; and summing up the multiple dimension costs to obtain the cloud resource cost.

[0009] Preferably, the dimensions of the monitoring data include: CPU resource usage, memory resource usage, CPU resource usage, network resource usage, and disk resource usage;

[0010] The dimension value is the maximum value of the request value and the usage.

[0011] Preferably, the formula for dimension cost is expressed as:

[0012]

[0013] The formula for cloud resource cost is expressed as:

[0014]

[0015] Among them, S i represents the usage of dimension i , n represents the total number of dimensions, C represents the cloud resource cost, R represents the rate, TimeInterval represents the collection period of the monitoring data, Request j represents the j th load request value in the collection period; Data j represents the j th detected value in the collection period, Max() represents taking the maximum value, A represents a constant.

[0016] Preferably, the method for listening for events of load request operations includes:

[0017] An interface service for monitoring load request operations, which is used to receive load request operations from users and generate events according to the load request operations. The load request operations include creation, deletion, and stop or update;

[0018] Establish a connection with the interface service and monitor the event.

[0019] Preferably, the method further includes a method for event preprocessing:

[0020] Judge whether the load type of the event matches the preset type;

[0021] If not, discard the event;

[0022] If it matches, judge whether the event is a user event;

[0023] If so, save the user event;

[0024] If not, discard the event;

[0025] Among them, the method for judging whether the event is a user event includes:

[0026] Preset the tenant name of non-user events;

[0027] If the tenant name of the event does not match the preset tenant name of non-user events, then the user event is a user event.

[0028] Preferably, the storage structure of the event includes: cluster, tenant name, user ID, load type, load name, load operation type, and operation occurrence time;

[0029] The method further includes a method for regularly collecting cloud resource monitoring data:

[0030] Regularly collect monitoring data of cloud resources by day, week or month, and generate a timed bill;

[0031] It also includes a method for generating a bill in real time:

[0032] Obtain the cloud resource monitoring data of the current day and the latest timed bill;

[0033] Calculate the bill of the current day according to the cloud resource monitoring data of the current day;

[0034] Generate a real-time bill according to the timed bill and the bill of the current day.

[0035] The present invention also provides a system for implementing the above cloud resource metering method, including: a metering module and a collection module. The metering module includes: a monitoring sub-module, a preprocessing sub-module, and a metering sub-module,

[0036] The monitoring sub-module is used to monitor events of load request operations;

[0037] The preprocessing sub-module is used to filter user events from the events;

[0038] The acquisition module is used to acquire monitoring data of cloud resources according to the dimensions of the load;

[0039] The metering sub-module is used to meter the usage amount of cloud resources according to the monitoring data.

[0040] Preferably, the system further includes a billing module, which is used to calculate the dimension fees according to the usage amount and unit price of the monitoring data; sum up the multiple dimension fees to obtain the cloud resource fees.

[0041] Preferably, the system further includes an operation module, an interface service, a storage module and a billing statement module.

[0042] The operation module is used to receive the load request operation of the user and send the load request operation to the interface service;

[0043] The interface service is used to receive the load request operation, generate an event, and perform application deployment according to the load request operation;

[0044] The billing statement module is used to call the billing module according to the user's request to obtain the cloud resource fees, generate a billing statement according to the cloud resource fees, and return or push the billing statement to the user;

[0045] The storage module is used to save the events and the acquired monitoring data.

[0046] Compared with the prior art, the beneficial effects of the present invention are as follows: The data statistics of metering are realized by combining the events of user load request operations with the monitoring data of cloud resources, improving the accuracy and reliability of metering data. It solves problems such as large deviation in traditional metering and billing methods, provides a more flexible and transparent billing mode, and users can also pay fees according to the actual usage situation, avoiding resource waste and unfair metering and billing. Description of the Drawings

[0047] Figure 1 is the flowchart of the event-based cloud resource metering method of the present invention;

[0048] Figure 2 is the system logic block diagram of the present invention;

[0049] Figure 3 is the specific metering method flowchart. Detailed Embodiments

[0050] To make the objectives, technical solutions and advantages of the embodiments of the present invention clearer, the following will clearly and completely describe the technical solutions in the embodiments of the present invention with reference to the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are some, but not all, of the embodiments of the present invention. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present invention without creative efforts shall fall within the scope of protection of the present invention.

[0051] The following further describes the present invention in detail with reference to the accompanying drawings:

[0052] An event-based cloud resource metering method, as Figure 1 shown, includes the following steps:

[0053] Step 101: Obtain the load request operation of the user and forward the load request operation to the interface service.

[0054] According to the load request operation, the interface service, on the one hand, generates an event; on the other hand, it performs application deployment. By performing application deployment in the cluster to execute the tasks or operations corresponding to the load request, the execution method is a prior art and will not be elaborated in the present invention.

[0055] Step 102: Listen for the event of the load request operation, where the event includes the user number, load / load name, load type, operation, and time.

[0056] Step 103: Determine whether the event is a user event.

[0057] If it is, execute Step 104: Collect the monitoring data of the cloud resources according to the dimension of the load, and execute Step 105.

[0058] During the execution of the load request operation, the cloud resources are consumed or changed. The monitoring data and its metric values can be collected by monitoring the cluster resources in the cloud computing. More specifically, the resource consumption of each container, each microservice, and each event can be collected.

[0059] If not, discard the event.

[0060] Step 105: Meter the usage amount of the cloud resources according to the monitoring data.

[0061] Step 106: Perform billing according to the metering.

[0062] Implement metering and billing data statistics by combining events related to user load request operations with monitoring data of cloud resources, improving the accuracy and reliability of metering and billing data. Solve problems such as large deviations in traditional metering and billing methods, provide a more flexible and transparent billing model, and enable users to pay according to actual usage, avoiding resource waste and unfair metering and billing.

[0063] In step 102, the method for listening to events of load request operations includes:

[0064] Step 201: Listen to the interface service of the load request operation, where the interface service is used to receive the user's load request operation and generate an event according to the load request operation. The load request operation includes create, delete, and stop or update.

[0065] The user performs an API load operation request through the API-Server of the Kubernetes cluster where the workload in the Kubernetes cluster is located by operating the workload.

[0066] Step 202: Establish a connection with the interface service and receive or listen to the event.

[0067] After receiving the event, the event can be preprocessed:

[0068] Step 301: Determine whether the load type of the event matches a preset type.

[0069] If not, execute step 302: Discard the event.

[0070] If it matches, execute step 303: Determine whether the event is a user event.

[0071] If so, execute step 304: Save the user event.

[0072] The saved structure of the event includes: cluster, tenant name, user ID, load type, load name, load operation type, and operation occurrence time.

[0073] If not, execute step 305: Discard the event.

[0074] In steps 103 and 304, the method for determining whether the event is a user event includes:

[0075] Step 311: Preset the tenant name Namespace of non-user events.

[0076] Step 312: If the tenant name of the event does not match the preset tenant name for non-user events, then the user event is a user event.

[0077] In step 106, the billing method:

[0078] Step 601: Calculate the dimension cost based on the usage amount and unit price of the monitoring data.

[0079] The dimensions of the monitoring data include: CPU resource usage, memory resource usage, CPU resource usage, network resource usage, and disk resource usage. The dimension value is the maximum value of the request value and the usage amount.

[0080] Step 602: Sum up the multiple dimension costs to obtain the cloud resource cost.

[0081] More specifically, the formula for the dimension cost is expressed as:

[0082] (1)

[0083] The formula for the cloud resource cost is expressed as:

[0084] (2)

[0085] Among them, S i Represents the usage amount of dimension i Of n Represents the total number of dimensions, C Represents the cloud resource cost, R Represents the rate, TimeInterval Represents the collection period of the monitoring data, Request j Represents the j Load request value of the Data j Represents the j Detection value of the Max() Represents taking the maximum value, A Represents a constant. Among them, the rate is calculated in hours, TimeInterval When the unit is seconds, A The value is 3600 。

[0086] In step 104, the Promethues monitoring component can be deployed and run in the cluster to collect and store the resource monitoring data of cloud-native applications in real time. More specifically, the method of regularly collecting resource monitoring metrics can be adopted:

[0087] Step 401: Regularly collect the monitoring data of cloud resources by day, week, or day, and generate a timed bill.

[0088] Step 402: Obtain the cloud resource monitoring metric data for the current day and the most recent scheduled bill.

[0089] Step 403: Calculate the bill for the current day based on the cloud resource monitoring data for the current day.

[0090] Step 404: Generate a real-time bill based on the scheduled bill and the bill for the current day.

[0091] For example, if the user queries the scheduled bill at 12 o'clock, the real-time bill is calculated based on the sum of the scheduled bill at 2 o'clock and the bill for the current day from 2 o'clock to 12 o'clock.

[0092] Bill statistics based on the combination of historical scheduled bills and bills for the current day: If only historical bills are generated regularly and the user bill is generated by merging historical bills, there may be a significant bill delay. If the bill is calculated in real time based on events and resource monitoring metric data, there will be a large number of queries and calculations, resulting in slow bill generation and high computational complexity of the bill system. The present invention proposes a bill statistics method based on the combination of historical bills and bills for the current day, which can accurately and real-time generate user bills.

[0093] The present invention also provides a system for implementing the above cloud resource metering method, as Figure 2 , the system includes: a metering module 3 and a collection module 6, the metering module 3 includes: a listening sub-module 31, a preprocessing sub-module 32 and a metering sub-module 33,

[0094] The listening sub-module 31 is used to listen for events of load request operations;

[0095] The preprocessing sub-module 32 is used to screen user events from the events;

[0096] The collection module 6 is used to collect cloud resource monitoring data according to the dimension of the load;

[0097] The metering sub-module 33 is used to meter the usage of cloud resources according to the monitoring data.

[0098] The system further includes a billing module 5, and the billing module 5 is used to calculate the dimension cost according to the usage amount and unit price of the monitoring data; sum up the dimension costs of multiple dimensions to obtain the cloud resource cost.

[0099] More specifically, the system further includes an operation module 1, an interface service 2, a storage module 4, and a billing module 5. The operation module 1 is used to receive the user's load request operation and send the load request operation to the interface service; the interface service 2 is used to receive the load request operation, generate an event, and perform application deployment according to the load request operation; the billing module 5 is used to call the charging module according to the user's request to obtain the cloud resource cost, generate a bill according to the cloud resource cost, and return or push the bill to the user; the storage module 4 is used to save the event and the collected monitoring data.

[0100] Resources such as CPU, memory, GPU, network, and storage in the computing power infrastructure cluster are uniformly managed by the cloud native Kubernetes cluster management base in the present invention. During the execution process, multiple clusters can be deployed. For each cluster, the user can submit a workload through the corresponding interface service API-Server component. The supported workload types include common cloud native application types such as argo workflow, volcano job, k8s deployment, and k8s job. The collection module 6 is designed as a Promethues monitoring component deployed and running in each cluster, which real-time collects and stores the resource monitoring metric data of cloud native applications. The metering module is deployed as a Charging Agent component. This component establishes a list / watch link with the API-Server in the cluster, captures operations such as the creation, stop, update, and deletion of various cloud native applications, and constructs them into events to report to the upper-level billing module. The billing module provides a bill query interface for users through the Restful API method. The billing module has two functions: calculating the bill information in real time and returning it to the user; performing bill summary regularly to facilitate the quick generation of subsequent user bill queries.

[0101] Such as Figure 3 , the specific metering method includes the following steps:

[0102] Step 501: The user submits a load request operation, and can submit a task or delete a task through the load request operation.

[0103] Step 502: Send the load request operation to the interface service. The interface service generates an event and performs execution cluster and its application deployment through the operation to execute the task submitted by the user.

[0104] Step 503: Listen for events of the interface service through the Charging agent component. The metering module 3 is deployed as the Charging agent component. When it starts, it establishes a long connection with the interface service API-Server and listens for all operations of users on Workload in the Kubernetes cluster through list / watch. After receiving the request, API-Server generates corresponding events (K8s Event) and sends them to the Charging agent component through the long connection.

[0105] Step 504: The Charging agent component preprocesses the received events. It matches the CRDType of the workload with the WorkloadType. The supported WorkloadType includes argo workflow, volcano job, k8s deployment, and k8s job. The supported WorkloadType can be configured in the WorkloadType configuration item in the startup configuration file of the Charging agent component. If it is consistent with the CRD name of the corresponding workload in the cluster, it is considered a match.

[0106] The Charging agent component determines whether the K8s Event is a non-user event. To avoid listening for events of non-user Workloads such as monitoring, logging, and system components, the list of namespaces to be ignored can be configured in the ignore configuration item in the startup configuration file of the Charging agent component, so as not to listen for events of non-user Workloads, that is, filter non-user Workload events and only select user events.

[0107] Step 505: Collect monitoring data from the execution cluster.

[0108] Step 506: Data storage. The Charging agent component converts the user event into the Event data structure and writes it into the storage module. More specifically, a Mysql database is used, but it is not limited to this.

[0109] The Event data structure is as follows: Event (Cluster, Namespace, User, WorkloadType, WorkloadName, Action, Time). Among them, Cluster: the name of the cluster where the Workload is located; Namespace: the name of the tenant where the Workload is located; User: the user ID to which the Workload belongs; WorkloadType: the type of the Workload; WorkloadName: the name of the Workload; Action: the type of user operation (create / delete / update); Time: the time when the user operation occurs.

[0110] Step 507: Regular or real-time metering.

[0111] The metering module regularly counts the resource usage of each dimension of all workloads in each cluster, all workloads in each namespace, and all workloads of each user at 2 o'clock every day, 2 o'clock every Monday, and 2 o'clock on the first day of each month, respectively, and records them in the storage module.

[0112] Step 508: Generate a bill.

[0113] When the user queries the cost bill, the bill is calculated according to the parameters of the query request and returned to the user. The parameters of the query request are as follows: grained (query granularity): supports querying according to four query granularities: cluster dimension, namespace dimension, user dimension, and workload dimension. Cluster: If the query granularity is the cluster dimension, the name of the cluster needs to be specified. Namespace: If the query granularity is the namespace dimension, the Cluster name and Namespace name need to be specified. User: If the query granularity is the user dimension, the user ID needs to be specified. workloadName: If the query granularity is the workload dimension, the name of the workload needs to be specified. StartTime: the start time of the bill. EndTime: the end time of the bill.

[0114] The query logic of the bill is as follows:

[0115] Total bill = unit price of resources * amount of resources;

[0116] The unit price of resources is set by the cluster administrator for different resource dimensions, as follows:

[0117] The cost of CPU is generally B1 yuan per core-hour, that is, the cost for one core of CPU per hour. The cost of memory is generally B2 yuan per MiB-hour, that is, the cost for one MiB of memory per hour. The cost of GPU is generally B3 yuan per card-hour, that is, the cost for one GPU card per hour; the unit prices of different models of GPU cards are different. The cost of network is generally B4 yuan per GiB, that is, the cost for one GiB of traffic. The cost of storage is generally XX yuan per GiB-hour, that is, the cost for one GiB of storage per hour; SSD and HDD are different.

[0118] The calculation method of resource quantity is as follows:

[0119] First, divide the bill request into a historical part and a current-day part. For the historical part, directly query and merge the statistically calculated data in the Mysql database. For the current-day part, calculate the bill data in real time according to the time period; the final representation of the resource quantity is:

[0120] {

[0121] "CPU": C1 core-hours;

[0122] "Mem": C2 hours;

[0123] "GPU": {

[0124] "XXGPU": C3 card-hours;

[0125] "XXXGPU": C4 card-hours;

[0126] };

[0127] "Network": C5 GiB;

[0128] "Storage": C6 GiB-hours;

[0129] }

[0130] The logic for merging scheduled bills is the same as the logic for calculating real-time bills for the current-day part, which is as follows:

[0131] Query all Event events of all workloads within the specified time period in the Mysql database;

[0132] Dynamically generate a Promethues query statement PromQL based on the Event events, and request the Promethues of the corresponding cluster to query the corresponding resource monitoring metric data;

[0133] Calculate the resource usage data based on the resource monitoring metric data, which is as follows:

[0134] The data format of the monitoring metrics is:

[0135] {

[0136] "index": "metric name";

[0137] "timestamp": "timestamp";

[0138] "data": metric value;

[0139] }

[0140] The value of resource usage is as follows: For CPU resources, request represents the value of workload.resource.request.cpu; data represents the CPU usage metric value queried from Prometheus. For memory resources, request represents the value of workload.resource.request.Mem; data represents the memory usage metric value queried from Prometheus. For GPU resources, request represents the value of workload.resource.request.gpu / nvidia.com; data represents the GPU usage metric value queried from Prometheus. For network resources, only the detected value can be used, and request can be set to a smaller value: data represents the network bandwidth usage metric value queried from Prometheus. For disk resources, the detected value is also used: Sum(data * TimeInterval / 3600), where data is the disk space usage metric value queried from Prometheus. Max(request; data) is an optimization for the burst mode of containers, and accurate billing is achieved by taking the maximum value of Request and Usage.

[0141] Billing for cloud-native applications in burst mode should be based on taking the maximum value of Request and Data: Cloud-native applications limit the resource usage of applications by specifying the Request and limit of the application. The Request of the application specifies the resource reservation value of the application, that is, even if the actual application does not use so much resources, Kubernetes will reserve the corresponding resources, and these reserved resources cannot be used by other applications; the limit resource is to limit the maximum resource usage upper limit of the application. In burst mode, the usage of the application may be greater than the Request value of the application. At this time, if only Request is used to count the resource usage, there will be a situation where the actual resource usage is greater than the counted resource usage, resulting in deviation; if only Data is used to count the resource usage, there will also be a situation where when Data is less than Request, the actual resource usage is greater than the counted resource usage, resulting in deviation; The present invention proposes that billing for cloud-native applications in burst mode should be based on taking the maximum value of Request and Data to achieve accurate billing and metering.

[0142] For the event-based cloud resource metering and billing of the present invention, in view of the characteristics of cloud-native applications such as high concurrency, dynamic scaling, and event-driven, especially in some scenarios of dynamic resource over-allocation and elastic scaling, the traditional metering and billing methods often have large deviations. A billing and metering method for cloud-native applications based on event-driven is proposed, which can capture operation events of various workloads in real time and dynamically calculate bill data according to the operation events and monitoring metric data, ensuring the refinement and accuracy of the bill data. It can achieve accurate metering and billing of cloud-native applications, and improve the accuracy rate of infrastructure resource metering and billing to over 95%. It solves the problem that it is difficult to correctly count the application resources caused by resource over-allocation and dynamic scaling in the cloud-native scenario.

[0143] Bill statistics method combining historical bills and current-day bills: If only generating historical bills regularly and generating user bills in the way of merging historical bills, there may be a large bill delay. If calculating bills in real time according to event and resource monitoring metric data, there will be a large number of queries and calculations, resulting in slow bill generation and high calculation complexity of the bill system. The present invention proposes a bill statistics method combining historical bills and current-day bills to achieve accurate and real-time generation of user bills. It can achieve bill delay at the minute level and bill query at the second level, and users can view bill information in real time.

[0144] The above are only the preferred embodiments of the present invention and are not used to limit the present invention. For those skilled in the art, the present invention can have various changes and modifications. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present invention shall be included within the protection scope of the present invention.

Claims

1. An event-based cloud resource metering method, characterized in that, It includes the following steps: Listen for events of load request operations, where the events include user numbers and loads; Determine whether the event is a user event; If it is, collect monitoring data of cloud resources according to the dimension of the load; Measure the usage of cloud resources based on the monitoring data; It also includes a method for event preprocessing: Determine whether the load type of the event matches a preset type; If it does not match, discard the event; If it matches, determine whether the event is a user event according to the preset tenant name; If it is, save the user event; If it is not, discard the event; Among them, the method for determining whether the event is a user event includes: Configure the list of namespaces to be ignored in the ignore configuration item in the startup configuration file of the Charging agent component. If the tenant name of the event does not match the namespace list, the event is a user event; Among them, the method for determining whether the load type of the event matches a preset type includes: Configure the supported WorkloadType types in the WorkloadType configuration item in the startup configuration file of the Chargingagent component to be consistent with the CRD name of the corresponding Workload in the cluster, then the load type matches the preset type.

2. The cloud resource metering method according to claim 1, characterized in that It also includes a billing method: Calculate the dimension cost according to the usage and unit price of the monitoring data; Sum up the multiple dimension costs to obtain the cloud resource cost.

3. The cloud resource measurement method according to claim 2, wherein The event also includes: load type, operation, and time; The dimensions of the monitoring data include: CPU resource usage, memory resource usage, network resource usage, and disk resource usage; The dimension value is the maximum of the request value and the usage.

4. The cloud resource metering method according to claim 3, wherein The formula for the usage of the dimension is expressed as: ； The formula for the cloud resource cost is expressed as: ； Among them, S i is expressed as the usage amount in dimension i , n is expressed as the total number of dimensions, C is expressed as the cloud resource cost, R is expressed as the rate, TimeInterval is expressed as the collection period of the monitoring data, Request j is expressed as the load request value in the j th collection period; Data j is expressed as the detection value in the j th collection period, Max() is expressed as taking the maximum value, A is expressed as a constant.

5. The cloud resource measurement method according to claim 1, wherein The method for listening for events of load request operations includes: Listen for the interface service of the load request operation, which is used to receive the load request operation of the user and generate an event according to the load request operation. The load request operation includes create, delete, and stop or update; Establish a connection with the interface service and listen for the event.

6. The cloud resource measurement method according to claim 1, wherein The storage structure of the event includes: cluster, tenant name, user ID, load type, load name, load operation type, and operation occurrence time; It also includes a method for periodically collecting monitoring data of cloud resources: Periodically collect the monitoring data of cloud resources by day, week, or month and generate a timed bill; It also includes a method for generating a real-time bill: Obtain the monitoring data of cloud resources for the current day and the most recent timed bill; Calculate the daily bill from the time of the timed bill to the current time based on the monitoring data of cloud resources for the current day; Generate a real-time bill based on the sum of the timed bill and the daily bill.

7. A system, characterized in that, For implementing the cloud resource measurement method described in any one of claims 1-6, the system includes: a measurement module and a collection module. The measurement module includes: a listening sub-module, a preprocessing sub-module, and a measurement sub-module, The listening sub-module is used to listen for events of load request operations; The preprocessing sub-module is used to filter user events from the events; The acquisition module is used to collect monitoring data of cloud resources according to the dimensions of the load; The metering sub-module is used to meter the usage of cloud resources according to the monitoring data.

8. The system according to claim 7, wherein, It further includes a billing module, which is used to calculate the dimension fees according to the usage and unit price of the monitoring data, and sum up the dimension fees of multiple dimensions to obtain the cloud resource fees.

9. The system according to claim 8, wherein It further includes an operation module, an interface service, a storage module and a billing module. The operation module is used to receive the load request operation of the user and send the load request operation to the interface service; The interface service is used to receive the load request operation, generate events, and perform application deployment according to the load request operation; The billing module is used to call the billing module according to the user's request to obtain the cloud resource fees, generate a bill according to the cloud resource fees, and return or push the bill to the user; The storage module is used to save the events and the collected monitoring data.

Images