Service level target management methods, systems, electronic devices and storage media

Abstract

This application proposes a service level target management method, system, electronic device, and storage medium. The service level target management method includes: acquiring user-defined service level target configuration information for each microservice, as well as monitoring indicator data and workload context information of the currently running workload; a workload refers to the specific application implementing the microservice; workload context information refers to the environment and status information related to the workload during execution; generating corresponding service level target rule data based on the service level target configuration information and workload context information; the service level target rule data includes service level target metadata, service level indicator rules, and service alarm rules; and managing the service level targets of the microservices based on the monitoring indicator data and service level target rule data. This application can determine different service level indicator types and service level targets for different workloads.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of microservices, and particularly relates to a service level objective management method and system, an electronic device and a storage medium. BACKGROUND

[0002] Since the application program of the microservice architecture has higher performance and can realize more functions, relatively, the management work is relatively more complex, and the running status and service quality of the microservice need to be measured, and it is determined whether the application program of the microservice reaches the expected performance requirement. Therefore, the industry or open source community proposes concepts such as service level indicator (SLI) and service level objective (SLO).

[0003] Among them, the service level indicator is an indicator for measuring the service running status, and is used to describe a specific performance indicator of the service, such as request success rate, delay time, throughput and the like. The service level objective is a target value or value range of the service level, which is defined based on the service level indicator, and is used to describe the performance target that the service should reach, and provides a formalized way to describe, measure and monitor the performance, quality and reliability of the microservice application program. The service level objective usually includes an indicator and a target value, for example, the request success rate should reach 99.9%, qps (Queries Per Second, query rate per second) > 100k and the like.

[0004] In order to better manage the microservice, the service level objectives of each microservice can also be managed to more accurately describe the service running status. However, based on the existing service level objective management method, different service level indicator types and service level objectives cannot be formulated for different workloads based on the service level objective configuration information configured by the user, and more accurate service objective level management cannot be realized. SUMMARY

[0005] The application proposes a service level objective management method and system, an electronic device and a storage medium, which can determine different service level indicator types and service level objectives for different workloads based on service level objective configuration information configured by a user.

[0006] The first aspect embodiment of the application proposes a service level objective management method, comprising:

[0007] Obtaining service level objective configuration information defined by a user for each microservice, and monitoring index data and workload context information of a currently running workload; the workload refers to a specific application program implementing the microservice; the workload context information refers to environment information and state information related to the workload during execution of the workload;

[0008] Generating corresponding service level objective rule data according to the service level objective configuration information and the workload context information; the service level objective rule data includes service level objective metadata, service level index rules, and service alarm rules;

[0009] Performing service level objective management on the microservice based on the monitoring index data and the service level objective rule data.

[0010] In some embodiments of the present application, the obtaining of the service level objective configuration information defined by the user for each microservice, and the monitoring index data and workload context information of the currently running workload includes:

[0011] Obtaining user-oriented service level objective configuration information defined by the user for each microservice, and converting the user-oriented service level objective configuration information into service-oriented service level objective configuration information;

[0012] Obtaining monitoring index data collected by a service mesh agent and workload metadata reported by a metadata reporter, and generating workload context information based on the workload metadata; the workload metadata is used to describe attributes and characteristics of the workload.

[0013] The generating of corresponding service level objective rule data according to the service level objective configuration information and the workload context information includes:

[0014] Determining one or more service level objective rule generation plug-ins based on the service level objective configuration information;

[0015] Calling the service level objective rule generation plug-ins to respectively generate corresponding service level objective rule data based on the service level objective configuration information and the workload context information.

[0016] In some embodiments of the present application, the determining of the one or more service level objective rule generation plug-ins based on the service level objective configuration information includes:

[0017] Determining plug-in type information and plug-in configuration information in the service level objective configuration information;

[0018] Based on the plug-in type information, a corresponding service level objective rule generation plug-in is selected from a preset plug-in set; and a new service level objective rule generation plug-in is generated according to the plug-in configuration information.

[0019] In some embodiments of the present application, the service level objective rule data is generated based on the service level objective configuration information and the workload context information, respectively, including:

[0020] The service level objective metadata is determined based on the service level objective configuration information and the workload context information.

[0021] According to the service level objective configuration information and the workload context information, relevant content is added to a service level objective rule generation template provided by the service level objective rule generation plug-in to generate corresponding service level indicator rules and service alarm rules.

[0022] In some embodiments of the present application, the service level objective management of the microservice is performed based on the monitoring indicator data and the service level objective rule data, including:

[0023] The service level indicator data of the current workload is generated according to the service level indicator rules in the service level objective rule data and the monitoring indicator data.

[0024] The service level objective management of the microservice processing the workload is performed based on the service level indicator data, the service level objective metadata and the service alarm rules in the service level objective rule data.

[0025] In some embodiments of the present application, the service level objective management of the microservice processing the workload is performed based on the service level indicator data and the service level objective metadata and the service alarm rules in the service level objective rule data, including:

[0026] Whether the service level objective configured by the user meets the service alarm rules is determined based on the service level indicator data of the current workload and the service alarm rules in the service level objective rule data.

[0027] In the case that the service level objective configured by the user meets the service alarm rules, service alarm information of the microservice is generated, and the service alarm information is supplemented based on the service level objective metadata in the service level objective rule.

[0028] The second aspect of the present application provides a service level objective management system, including:

[0029] a data acquisition module, configured to acquire service level objective configuration information defined by a user for each microservice, and monitoring index data and workload context information of a currently running workload; the workload refers to a specific application program implementing the microservice; the workload context information refers to environment information and state information related to the workload during execution of the workload;

[0030] a rule generation module, configured to generate corresponding service level objective rule data according to the service level objective configuration information and the workload context information; the service level objective rule data includes service level objective metadata, service level index rules, and service alarm rules;

[0031] a target management module, configured to perform service level objective management on the microservice based on the monitoring index data and the service level objective rule data.

[0032] An embodiment of the third aspect of the present application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, and the processor executes the computer program to implement the method of the first aspect.

[0033] An embodiment of the fourth aspect of the present application provides a computer readable storage medium having a computer program stored thereon, and the program is executed by a processor to implement the method of the first aspect.

[0034] The technical scheme provided in the embodiments of the present application has at least the following technical effects or advantages:

[0035] In the embodiments of the present application, the service level objective configuration information defined by the user for each microservice of the application program, and the monitoring index data and workload context information of the currently running workload are acquired first. Then, the corresponding service level objective rule data is generated according to the service level objective configuration information and the workload context information, and the service level objective management is performed on the microservice of the application program based on the monitoring index data and the service level objective rule data. In this way, the method can generate the corresponding service level objective rule data according to different workload context information based on the service level objective configuration information configured by the user, and analyze the generated service level objective rule data based on the monitoring index data of the workload, so that different service level index types and service level objectives can be determined for different workloads based on the service level objective configuration information configured by the user, and then more accurate service level management can be achieved.

[0036] Additional aspects and advantages of the present application will be in part apparent and in part pointed out hereinafter. BRIEF DESCRIPTION OF DRAWINGS

[0037] Various other advantages and benefits will become apparent to those of ordinary skill in the art upon reading the following detailed description of the preferred embodiments. The detailed description is made with reference to the accompanying drawings.

[0038] In the drawings:

[0039] Figure 1 A schematic diagram of deployment of a service level objective management system provided by an embodiment of the present application in a service mesh is shown;

[0040] Figure 2 A schematic diagram of a flow of a service level objective management method provided by an embodiment of the present application is shown;

[0041] Figure 3 A schematic diagram of a detailed flow of step S2 of a service level objective management method provided by an embodiment of the present application is shown;

[0042] Figure 4 A schematic diagram of a detailed flow of step S3 of a service level objective management method provided by an embodiment of the present application is shown;

[0043] Figure 5 A schematic diagram of a service mesh architecture and processing logic including service level objective management provided by an embodiment of the present application is shown;

[0044] Figure 6 A schematic diagram of an architecture of a service level objective management system provided by an embodiment of the present application is shown;

[0045] Figure 7 A schematic diagram of a structure of an electronic device provided by an embodiment of the present application is shown;

[0046] Figure 8 A schematic diagram of a storage medium provided by an embodiment of the present application is shown. DETAILED DESCRIPTION

[0047] Exemplary embodiments of the present application will be described herein below with reference to the accompanying drawings. While exemplary embodiments of the present application are shown in the drawings, it should be understood that the present application can be embodied in various forms without being limited by the embodiments set forth herein. Rather, these embodiments are provided so that this application will be thorough and complete, and will fully convey the scope of the application to those skilled in the art.

[0048] It should be noted that the technical or scientific terms used in the present application should be understood as their ordinary meanings to those skilled in the art, unless otherwise specified.

[0049] In a microservices architecture, an application is divided into multiple small, autonomous services, called microservices, which can work together through lightweight communication mechanisms to build complex applications. Each microservice can be responsible for implementing a specific function, and its data storage, processing logic, and user interface are independent of other services. The workload can be a specific operation performed by a microservice or a user request. For example, a microservices architecture for an online shopping website that needs to handle a large number of order and payment requests and provide highly reliable and high-performance services. In this case, the workload can be divided into order processing, payment processing, user management, and product management. Among them, order processing includes processing user-submitted order requests, including order creation, order status update, and order cancellation operations, and this order processing process can be implemented through a microservice called "order service". Payment processing includes processing user payment requests, including payment verification, payment success processing, and payment failure processing operations, and this payment processing process can be implemented through a microservice called "payment service". User management includes operations such as user registration, login, and personal information management, and this user management process can be implemented through a microservice called "user service". Product management includes operations such as managing product information and inventory, and this product management process can be implemented through a microservice called "product service". For the workload, it refers to the specific application that implements the functions of the above microservices.

[0050] In order to solve the problem of unstable communication between microservices, a service mesh design based on the proxy pattern has emerged. Service mesh injects a proxy layer into the network communication of the application, that is, there is a proxy beside each instance of the service, and the communication logic between services is abstracted into the service mesh. The service can only focus on the function processing logic, thereby realizing the observability of inter-service communication, traffic management, fault recovery, and a series of automated functions. Service mesh can be regarded as a framework for managing communication between microservices and applications. In the service mesh, service requests are routed between proxies in their own infrastructure layer. The communication overhead generated by using service mesh technology to collect telemetry information is lightweight, and it is non-intrusive to existing applications.

[0051] A service mesh generally consists of a control plane and a data plane. Specifically, the control plane is a set of control components running in a dedicated namespace, which complete some control management functions, including aggregating telemetry data, providing user-oriented APIs (Application Programming Interface), providing control data to the grid agents of the data plane, and driving the behavior of the data plane. The data plane is composed of a series of grid agents running beside each service instance. Specifically, the microservice architecture can be directly deployed on distributed devices or clusters, or based on containers (groups). Similarly, the control components and grid agents of the service mesh can be implemented on distributed devices / clusters or containers (groups). In addition, the control components of the service mesh can also be formed in a hosting mode, which can be referred to as a service mesh hosting control plane. The hosting mode means that the control components of the service mesh run on a separate server, rather than running in a certain data plane cluster. The service mesh hosting control plane is usually used to manage and configure the grid service agents in the service mesh data plane cluster. Supporting service mesh capabilities in this hosting mode can reduce the complexity and cost of user operation and maintenance.

[0052] In related technologies, in order to better manage microservices, the service level objectives of each microservice can be managed. Specifically, the service level objectives of each microservice can be managed according to the service level objective configuration information made by the user, so as to more accurately describe the service running status. However, based on the existing service level objective management method, it is still not possible to formulate different service level indicator types and service level objectives for different workloads based on the service level objective configuration information configured by the user, and it is not possible to achieve more accurate service level management. In addition, the existing service level objective management method also requires the user to have prior knowledge of observable index collection and query and SLO related concepts, that is, the user has a high professional requirement, and it is not possible to configure service level indicator collection and alarm rules in an out-of-box manner.

[0053] Based on the above problems, the embodiment provides a service level objective management method and system. The method can first acquire service level objective configuration information defined by a user for each microservice of an application, and monitoring index data and workload context information of a currently running workload. Then, according to the service level objective configuration information and the workload context information, corresponding service level objective rule data is generated. And based on the monitoring index data and the service level objective rule data, service level objective management is performed on the microservices of the application. In this way, the method can generate corresponding service level objective rule data according to different workload context information based on the service level objective configuration information configured by the user, and analyze the generated service level objective rule data based on the monitoring index data of the workload, so that different service level index types and service level objectives can be determined based on the service level objective configuration information configured by the user and corresponding to different workloads, thereby realizing more accurate service level objective management.

[0054] The service level objective management system can be deployed in the control plane of the mesh service, as shown in Figure 1 The service level objective management system can be deployed in the control plane of the mesh service, as shown in Figure 1 The workload is a service instance, and the service mesh agent can acquire monitoring index data of the workload. The service level objective management can be realized without modifying the application or with little modification, by acquiring the monitoring index data of the workload monitored by the service mesh agent on the data plane and the workload metadata reported by the metadata reporter. Further, the service level objective management system can be realized based on containers (groups) and cloud native.

[0055] The workload refers to a specific application that implements a microservice. The workload context information refers to environment information and state information related to the workload during execution of the workload. For example, it can include service protocol types provided by the workload, deployment environments of the workload, and workload types, names, namespaces, and other information. The monitoring index data of the workload is used to describe original data related to performance indicators monitored by the service mesh agent during execution of the workload.

[0056] The service level objective configuration information is information related to service level objectives configured by the user for the service. The information related to the service level objectives includes but is not limited to service level index types and service level objectives. Different service level index types and service level objectives can be configured according to different services or workloads.

[0057] The service level objective management method provided in the embodiments of the present application can include the following steps:

[0058] The service level objective management method provided in the embodiments of the present application will be described in detail below with reference to the accompanying drawings.

[0059] Please refer to Figure 2 The service level objective management method provided in the embodiments of the present application can include the following steps: Figure 2 As shown in the figure, the service level objective management method can include the following steps:

[0060] In step S1, user-defined service level objective configuration information of each microservice, monitoring index data of a currently running workload, and workload context information are obtained.

[0061] In actual application, a user can make different service level objective configurations for each microservice of an application program and different workloads. Then, based on the monitoring index data of the currently running workload and the workload context information, the type of the currently running workload can be determined, and the service level objective configuration information corresponding to the workload type can be selected from the service level objective configuration information made by the user.

[0062] In some embodiments, step S1 can include the following processing: obtaining user-defined user-oriented service level objective configuration information of each microservice, and converting the user-oriented service level objective configuration information into service-oriented service level objective configuration information; obtaining monitoring index data collected by a service mesh agent and workload metadata reported by a metadata reporter, and generating workload context information based on the workload metadata.

[0063] The workload metadata is used to describe the attributes and characteristics of the workload, including but not limited to the type, size, resource demand, running time and other related attributes of the workload, and the like.

[0064] In the embodiment, the service level objective management system can provide a cloud-native declarative API for a user, based on which the user can define user-oriented service level objective configuration information in the form of YAML (YAML Ain't a Markup Language, which is a recursive acronym, YAML is not a markup language). However, the user-oriented service level objective configuration information cannot be recognized by the service level objective management system, so it is necessary to convert the user-oriented service level objective configuration information into service-oriented service level objective configuration information. The cloud-native declarative API is a method for defining cloud-native applications and services using declarative syntax. It is an extension of the Kubernetes (Kubernetes, K8s for short) API and can be used to define and manage various aspects of cloud-native applications, microservices, and infrastructure, such as application configuration, deployment, service discovery, load balancing, security control, and the like.

[0065] In the embodiment, when obtaining monitoring indicator data and workload metadata, the monitoring indicator data of the workload can be obtained based on the mesh service agent of the service mesh system, and the workload metadata reported by the metadata reporter connected to the workload can be obtained. And generate workload context information according to workload metadata, in order to extract environment information and state information related to workload. In this way, since the service mesh agent proxies the traffic of the workload without intrusion and reports the monitoring indicator data, the user does not need to care about the source of the service level objective rule data and the collection method of the monitoring indicator data, and does not need to have prior knowledge of observable indicator collection query and SLO related concepts. The service level indicator collection and service alarm rule can be configured in an out-of-box manner.

[0066] Step S2, generating corresponding service level objective rule data according to the service level objective configuration information and the workload context information; the service level objective rule data includes service level objective metadata, service level indicator rule and service alarm rule.

[0067] In some embodiments, as shown in Figure 3 Step S2 can include the following steps: step S21, determining one or more service level objective rule generation plug-ins based on the service level objective configuration information; step S22, calling the service level objective rule generation plug-in, and generating corresponding service level objective rule data based on the service level objective configuration information and the workload context information.

[0068] Among them, the service level objective rule generation plug-in is used to generate corresponding service level objective rule data based on the generated service level objective configuration information and workload context information according to the preset rule.

[0069] In actual application, one or more service level objective rule generation plug-ins can be set, each of which can correspond to different workload types and generate corresponding service level objective rule data. The user can add information about the service level objective rule generation plug-in to the service level objective configuration information. After receiving the service level objective configuration information including the plug-in information, the service level objective management system can determine one or more service level objective rule generation plug-ins specified by the user according to the plug-in information, and call the one or more service level objective rule generation plug-ins to generate corresponding service level objective rule information.

[0070] Further, the embodiment can also set a service level objective rule generation plug-in engine for determining and calling the service level objective rule generation plug-in according to the service level objective configuration information. The service level objective rule generation plug-in engine can provide a plug-in mode framework, which can be extended based on the service level objective rule generation plug-in defined by the user in addition to the built-in service level objective rule generation plug-in. That is, the service level objective configuration information configured by the user can also include plug-in configuration information, and the service level objective management system can generate a new service level objective rule generation plug-in based on the plug-in configuration information.

[0071] Further, step S21 can specifically include the following processing: determining the plug-in type information and the plug-in configuration information in the service level objective configuration information; selecting one or more service level objective rule generation plug-ins corresponding to the plug-in type information from a preset plug-in set; and generating a new service level objective rule generation plug-in according to the plug-in configuration information.

[0072] The plug-in type information can correspond to the workload type, i.e., the specific application program type implementing the microservice. Different workload types can correspond to different service level indicator types and different service level objectives. The plug-in configuration information can be understood as information used to generate a new service level objective rule generation plug-in.

[0073] In this embodiment, in addition to containing service level target related configuration information, the service level target configuration information can also contain one or more plug-in types of service level target rule generation plug-ins specified by the user, and can also contain plug-in configuration information of the service level target rule generation plug-in customized by the user. Therefore, when determining the service level target rule generation plug-in, it can be determined first whether the plug-in configuration information is contained in the service level target configuration information. If not, the service level target rule generation plug-in can be directly determined based on the plug-in type specified by the user in the service level target configuration information. If the plug-in configuration information is contained in the service level target configuration information, a new service level target rule generation plug-in can be generated according to the plug-in configuration information, and the new service level target rule generation plug-in is also determined as the service level target rule generation plug-in specified by the user. In this way, the user can customize and extend the service level target rule generation plug-in, more user needs can be met, and the practicability and reliability of the service level target management method can be improved.

[0074] Specifically, the service level target configuration information can declare the creation of a new service level target rule generation plug-in as needed. In this embodiment, a new custom resource with a specified name and architecture, i.e., a new service level target rule generation plug-in, can be created based on the Kubernetes API.

[0075] It can be understood that the service level target configuration information can contain any one of the plug-in type information and the plug-in configuration information, or both, which are not specifically limited in this embodiment.

[0076] In other embodiments, after the service level target rule generation plug-in is invoked in step S22, the step of generating corresponding service level target rule data based on the service level target configuration information and the workload context information can specifically include the following processing: determining service level target metadata based on the service level target configuration information and the workload context information; and adding relevant content to the service level target rule generation template provided by the service level target rule generation plug-in according to the service level target configuration information and the workload context information to generate corresponding service level indicator rules and service alarm rules.

[0077] Specifically, after the service level target rule generation plug-in is determined, the service level target rule generation plug-in can be invoked, and the workload metadata can be summarized first based on the workload context information and the service level target configuration information configured by the user. Then, according to the workload label, name, namespace and other information in the workload context information, and the service level target configuration information configured by the user, specific information is supplemented into the service level target rule generation template provided by the service level target rule generation plug-in to form service level indicator rules and service alarm rules.

[0078] It is understood that the above-described method of generating service level target rule data based on a preset service level target rule generation template is only one implementation method of this embodiment. This embodiment is not limited to this. For example, it is also possible to directly extract the service level target configuration information related to the workload context information from the service level target configuration information made by the user based on the workload context information of the currently running workload, and generate the corresponding service level target rule data.

[0079] Step S3: Based on monitoring indicator data and service level target rule data, perform service level target management for microservices.

[0080] Service level target management for application microservices may include, but is not limited to, analyzing service level targets and generating service alerts when the current workload fails to meet the generated service level targets.

[0081] In some embodiments, such as Figure 4 As shown, step S3 above may include the following steps: Step S31, generating the current service level indicator data of the workload based on the service level indicator rules in the service level target rule data and the monitoring indicator data; Step S32, performing service level target management on the microservices handling the workload based on the service level indicator data, the service level target metadata and service alarm rules in the service level target rule data.

[0082] In this embodiment, the service level target management system can sample, calculate, and analyze monitoring indicator data based on the service level indicator rules in the service level target rule data, thereby generating service level indicator data for the service. The service level indicator data has a similar data structure to the service level target data and may include the service level indicator and its actual value.

[0083] Specifically, step S32 may include the following processing: based on the current service level indicator data of the workload and the service alarm rules in the service level target rule data, determine whether the service level target configured by the user meets the service alarm rules; if the service level target configured by the user meets the service alarm rules, generate service alarm information for the microservice, and supplement the service alarm information based on the service level target metadata in the service level target rules.

[0084] In the embodiment, after the current service level indicator data of the workload is determined, whether the service level target configured in the service alarm rule is met based on the service level indicator data, and in the case of meeting the service alarm rule, the service alarm information can be generated, so as to realize the service level target management of the microservice. In the case of not meeting the service alarm rule, the information of good service state can be fed back, or no processing can be performed.

[0085] In another specific embodiment, the service level target management of the service can be implemented based on the service mesh architecture and processing logic as shown in Figure 5 Figure 5 The service mesh data plane is a logical division including a plurality of service mesh data plane clusters, which is managed uniformly by the service mesh hosting control plane. For example, the service mesh data plane cluster can be but is not limited to a Kubernetes cluster. In the embodiment, the workload and the service mesh agent run in the data plane cluster. The service mesh hosting control plane is used to manage and configure the service mesh agent in the service mesh data plane cluster. In the embodiment, the service level target management system belongs to the component of the control plane.

[0086] In the service level target management system, the user can define the service level target configuration information in the form of YAML through the cloud native declarative API provided by the system. The service level target management system can include a data acquisition module, which can analyze the service level target configuration information defined by the user and convert it into service-oriented service level target configuration information (such as service level target type, service level target value, etc.). The service level target configuration information can also be controlled and managed throughout the life cycle, for example, the service level target type and the service level target value are modified. Specifically, the data acquisition module can include a service configuration controller and a service mesh controller: the service configuration controller is used to acquire the user-defined user-oriented service level target configuration information of each microservice of the application, and convert the user-oriented service level target configuration information into service-oriented service level target configuration information. The service mesh controller is used to acquire the workload metadata and generate the workload context information based on the workload metadata.

[0087] ​The service level objective management system can further include a rule generation module. The rule generation module can analyze the content of the service level objective configuration information and calculate service level objective rule data for the workloads based on workload context information. The workload context information can be generated based on workload metadata obtained by the service mesh controller. The workload metadata can be obtained by a metadata reporter from the service level objective metadata associated with the workloads and reported to the service mesh controller.

[0088] The rule generation module can include an SLO plugin engine and a plurality of SLO plugins. The SLO plugin engine provides a plug-in mode framework, and in addition to built-in SLO plugins, users can also define corresponding SLO plugin extensions. Different SLO plugins generate different SLO rule data for specific workload context information and SLO configuration information.

[0089] Based on different SLO plugins, the rule generation module can generate SLO rule data based on the SLO plugins. The SLO rule data includes SLO metadata, service level indicator rules, and service alert rules.

[0090] The target management module of the service level objective management system can include one or more SLO execution engines. Each SLO execution engine can run SLO rule data generated by any SLO plugin. The execution of the SLO execution engine depends on the monitoring indicator data reported by the service mesh agent. After the SLO execution engine receives the monitoring indicator data, it can calculate and analyze the SLO rule data in real time and generate corresponding service alert information. Since the service mesh agent proxies the traffic of the workloads without invasion and reports the monitoring indicator data, users do not need to be concerned about the collection method of the monitoring indicator data as the source of the SLO execution data, nor do they need to have prior knowledge of observable indicator collection queries and SLO-related concepts, thereby enabling out-of-the-box configuration of service level indicator collection and service alert rules.

[0091] In summary, the service level objective management method provided in the embodiment first acquires service level objective configuration information defined by a user for each microservice of an application program, and monitoring index data and workload context information of a currently running workload. Then, corresponding service level objective rule data is generated according to the service level objective configuration information and the workload context information, and the microservices of the application program are managed based on the monitoring index data and the service level objective rule data. In this way, the method can generate corresponding service level objective rule data according to different workload context information based on the service level objective configuration information configured by the user, and analyze the generated service level objective rule data based on the monitoring index data of the workload, so that different service level index types and service level objectives can be determined for different workloads based on the service level objective configuration information configured by the user, and more accurate service level management can be achieved.

[0092] Based on the same inventive concept of the service level objective management method, the embodiment further provides a service level objective management system for executing the service level objective management method. Figure 6 As shown in the service level objective management system, the service level objective management system comprises:

[0093] A data acquisition module is configured to acquire service level objective configuration information defined by a user for each microservice, and monitoring index data and workload context information of a currently running workload. The workload refers to a specific application program implementing the microservice, and the workload context information refers to environment information and state information related to the workload during execution of the workload.

[0094] A rule generation module is configured to generate corresponding service level objective rule data according to the service level objective configuration information and the workload context information. The service level objective rule data comprises service level objective metadata, service level index rules, and service alarm rules.

[0095] A target management module is configured to manage the service level objective of the microservice based on the monitoring index data and the service level objective rule data.

[0096] In some embodiments, the data acquisition module comprises a service configuration controller and a service mesh controller.

[0097] The service configuration controller is configured to acquire user-oriented service level objective configuration information defined by a user for each microservice of an application program, and convert the user-oriented service level objective configuration information into service-oriented service level objective configuration information.

[0098] The service mesh controller is configured to acquire workload metadata, and generate workload context information based on the workload metadata.

[0099] In some embodiments, the rule generation module comprises a service level objective rule generation plug-in engine and a plurality of service level objective rule generation plug-ins; the service level objective rule generation plug-in engine is invoked to load any service level objective rule generation plug-in;

[0100] The service level objective rule generation plug-in engine determines a corresponding service level objective rule generation plug-in from a preset service level objective rule generation plug-in set based on the workload context information, and loads the service level objective rule generation plug-in;

[0101] The service level objective rule generation plug-in generates corresponding service level objective rule data based on the service level objective configuration information, the workload context information, and the corresponding service level objective rule generation plug-in.

[0102] In some embodiments, the target management module comprises a plurality of service level objective execution engines;

[0103] Each service level objective execution engine can run service level objective rule data generated by any service level objective rule generation plug-in, to generate current service level indicator data of the workload according to service level indicator rules in the service level objective rule data and monitored indicator data, and perform service level objective management on microservices of the application based on the service level indicator data, service level objective metadata in the service level objective rule data, and service alarm rules.

[0104] It can be understood that the service level objective management system provided in the embodiments has the same inventive concept as the service level objective management method provided in the embodiments of the present application, and can at least achieve the same beneficial effects as the service level objective management method, and the various implementation manners of the service level objective management method are also applicable to the implementation of the service level objective management system, which will not be described here.

[0105] It should be noted that the data (including but not limited to data for model training, stored data, displayed data, etc.) involved in the embodiments of the present application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data need to comply with the relevant laws, regulations and standards of the relevant countries and regions, and provide corresponding operation portals for the user to choose authorization or refusal.

[0106] The embodiments of the present application also provide an electronic device for executing the service level objective management method described above. Please refer toFigure 7 Fig. 4 shows a schematic diagram of an electronic device according to some embodiments of the present application. As shown in Fig. 4, the electronic device 4 comprises a processor 400, a memory 401, a bus 402 and a communication interface 403, the processor 400, the communication interface 403 and the memory 401 are connected through the bus 402; the memory 401 stores a computer program which can be run on the processor 400, and the processor 400 runs the computer program to perform the service level target management method according to any one of the preceding embodiments of the present application. Figure 7

[0107] The memory 401 can include a high-speed random access memory (RAM: Random Access Memory) and can also include a non-volatile memory such as at least one disk memory. The communication connection between the apparatus network element and at least one other network element is realized through the at least one communication interface 403 (which can be wired or wireless), and the Internet, a wide area network, a local network, a metropolitan area network, etc. can be used.

[0108] The bus 402 can be an ISA bus, a PCI bus or an EISA bus, etc. The bus can be divided into an address bus, a data bus, a control bus, etc. The memory 401 is used to store programs, and the processor 400 executes the programs after receiving execution instructions. The service level target management method disclosed in any one of the preceding embodiments of the present application can be applied to the processor 400 or realized by the processor 400.

[0109] ​The processor 400 can be an integrated circuit chip with signal processing capability. In implementation, each step of the above method can be completed by integrated logic circuits or instructions in the form of software in the processor 400. The processor 400 described above can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a ready programmable gate array (FPGA) or other programmable logic device, a discrete gate or transistor logic device, a discrete hardware component. Each method, step and logic block disclosed in the embodiments of the present application can be implemented or executed. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in combination with the embodiments of the present application can be directly embodied as a hardware code processor for execution, or a combination of hardware and software modules in the code processor for execution. The software module can be located in a random access memory, a flash memory, a read-only memory, a programmable read-only memory or an electrically erasable programmable memory, a register, etc. The storage medium in the art. The storage medium is located in the memory 401, and the processor 400 reads the information in the memory 401, and combines the hardware to complete the steps of the above method.

[0110] The electronic device provided by the embodiments of the present application and the service level target management method provided by the embodiments of the present application have the same beneficial effects as the methods they adopt, run or implement.

[0111] The embodiments of the present application also provide a computer readable storage medium corresponding to the service level target management method provided by the preceding embodiments. Please refer to Figure 8 The computer readable storage medium shown is an optical disc 50, and a computer program (i.e. program product) is stored on the optical disc 50. When the computer program is run by a processor, the service level target management method provided by any of the preceding embodiments will be executed.

[0112] It should be noted that examples of the computer readable storage medium can also include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other optical, magnetic storage medium, which will not be described one by one here.

[0113] The computer readable storage medium provided by the above embodiments of the present application has the same beneficial effects as the method adopted, run or implemented by the application program stored therein, based on the same inventive concept as the service level objective management method provided by the embodiments of the present application.

[0114] It should be noted that:

[0115] In the description provided herein, numerous specific details are set forth. However, it is understood that embodiments of the application can be practiced without these specific details. In some instances, well-known structures and techniques have not been shown in detail in order not to obscure the understanding of this description.

[0116] Similarly, it is to be understood that the above description is illustrative of various embodiments of the application and certain specific features, structures, or characteristics, but that the exhaustive scope of the application is indicated by the appended claims. Many alternatives, modifications, and variations will be apparent to those skilled in the art in light of the above teachings. Accordingly, the application is intended to embrace all such alternatives, modifications, and variations which fall within the scope of the claims. Furthermore, to the extent that the terms "comprises", "includes", "has", "contains", "involves", and variations thereof, are used in either the detailed description or the claims, such terms are intended to be inclusive in a manner similar to the term "comprising" as an open transition term without precluding any additional or other elements.

[0117] In addition, those skilled in the art will appreciate that, unless otherwise indicated herein, the various embodiments described herein are not inherently related to any particular apparatus or method and can be manifested in various types of apparatuses, system, or methods, without departing from the scope of the present application. Therefore, the descriptions herein should be understood to include any such altered versions of the application that are, for example, developed later when changes to the application are made that do not depart from the inventive scope taught herein.

[0118] The above descriptions are only the preferred embodiments of the present application, but the protection scope of the present application is not limited to this, and any person skilled in the art can easily think of the changes or replacements within the technical scope disclosed by the present application, which should be covered in the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.

Claims

1. A service level objective management method characterized by, The method comprises the following steps: obtaining service level objective configuration information defined by a user for each microservice, and monitoring index data and workload context information of a currently running workload; the workload refers to a specific application program that implements the microservice; the workload context information refers to environment information and state information related to the workload during execution of the workload; generating corresponding service level objective rule data according to the service level objective configuration information and the workload context information; the service level objective rule data comprises service level objective metadata, service level index rules, and service alarm rules; based on the monitoring index data and the service level objective rule data, performing service level objective management on the microservice; wherein, obtaining monitoring index data and workload metadata of a currently running workload comprises: obtaining monitoring index data collected by a service mesh agent and workload metadata reported by a metadata reporter, and generating workload context information based on the workload metadata; the workload metadata is used to describe the attributes and characteristics of the workload.

2. The method of claim 1, wherein, The method comprises the following steps: obtaining user-defined service level objective configuration information for each microservice, and converting the user-oriented service level objective configuration information into service-oriented service level objective configuration information.

3. The method according to claim 1 or 2, characterized in that, The method comprises the following steps: based on the service level objective configuration information, determining one or more service level objective rule generation plug-ins; calling the service level objective rule generation plug-in, and respectively generating corresponding service level objective rule data based on the service level objective configuration information and the workload context information.

4. The method of claim 3, wherein, The method comprises the following steps: determining plug-in type information and plug-in configuration information in the service level objective configuration information; based on the plug-in type information, selecting one or more corresponding service level objective rule generation plug-ins from a preset plug-in set; and generating a new service level objective rule generation plug-in according to the plug-in configuration information.

5. The method of claim 3, wherein, The method comprises the following steps: based on the service level objective configuration information and the workload context information, determining the service level objective metadata; according to the service level objective configuration information and the workload context information, adding relevant content to a service level objective rule generation plug-in template provided by the service level objective rule generation plug-in, to generate corresponding service level index rules and service alarm rules.

6. The method of claim 1 or 2, wherein, The method comprises the following steps: generating service level indicator data of the workloads currently based on the service level indicator rules in the service level target rule data and the monitoring indicator data; performing service level target management on the microservices processing the workloads based on the service level indicator data, and service level target metadata and service alarm rules in the service level target rule data.

7. The method of claim 6, wherein, The service level target management on the microservices processing the workloads based on the service level indicator data and the service level target metadata and the service alarm rules in the service level target rule data comprises: determining whether the service level target configured by the user meets the service alarm rules based on the service level indicator data of the workloads currently and the service alarm rules in the service level target rule data; generating service alarm information of the microservices and supplementally describing the service alarm information based on the service level target metadata in the service level target rules in the case that the service level target configured by the user meets the service alarm rules.

8. A service level objective management system, characterized by, comprise: a data acquisition module configured to acquire service level target configuration information defined by a user for each microservice, and monitoring indicator data and workloads context information of a currently running workload; the workload refers to a specific application program implementing the microservice; and the workloads context information refers to environment information and state information related to the workload during execution of the workload; a rule generation module configured to generate corresponding service level target rule data based on the service level target configuration information and the workloads context information; the service level target rule data comprises service level target metadata, service level indicator rules and service alarm rules; a target management module configured to perform service level target management on the microservices based on the monitoring indicator data and the service level target rule data; wherein the monitoring indicator data and the workloads context information of the currently running workload are acquired by: acquiring monitoring indicator data collected by a service mesh agent and workloads metadata reported by a metadata reporter, and generating workloads context information based on the workloads metadata; the workloads metadata are used to describe attributes and characteristics of the workloads.

9. An electronic device, comprising: The computer program is executed by the processor to implement the method according to any one of claims 1-7.

10. A computer-readable storage medium having stored thereon a computer program, characterized in that, The computer program is executed by the processor to implement the method according to any one of claims 1-7.

Images