METHOD AND NETWORK NODE FOR GENERATING CONFIGURATION Rules FOR ONE OR MORE RESOURCES

Abstract

The present disclosure relates to a method and a network node for generating configuration rules for one or more resources. The method includes obtaining a graph-based representation of the system. The method includes mapping data collected in the system to corresponding nodes in a graph-based representation of the system. The method includes training a machine learning (ML) model to provide a configuration rule using a mapping of data to corresponding nodes in a graph-based representation of the system. The method includes generating an interpretation of the configuration rule using inductive reasoning, thereby obtaining an interpretable configuration rule. The method includes using an interpretable configuration rule as an input to a configuration solver to configure one or more resources.

Description

Technical Field

[0001] This disclosure relates to the use of artificial intelligence (AI) / machine learning (ML) to generate interpretable configuration rules in the cloud. Background Technology

[0002] Intent is typically expressed as a high-level requirement, rather than as how to implement it using low-level deployment and infrastructure details. Therefore, a translation is needed between what the requirement is and how to implement that intent to find the appropriate service and its configuration that will meet the expected requirements. An example of an intent could be: "A web service that processes 1000 transactions per minute and provides the highest level of security and reliability with a latency of no more than 3 seconds."

[0003] Given a high-level description of the intent, there exist solutions that decompose the input intent into a set of specific services (Virtual Network Functions (VNFs), microservices, etc.) and link them together based on their dependencies. However, such approaches do not guarantee that these services will achieve their goals and satisfy the intent requirements. Summary of the Invention

[0004] Therefore, these services should also be properly configured to ensure successful intent deployment and to control their contribution to intent requirements, thereby mitigating the risk of intent violations on the underlying cloud system. In other words, there should be a solution to determine service expectations based on factors such as the number of requests per node, maximum latency to the database, latency jitter, and loss rate.

[0005] A computer-implemented method for generating configuration rules for one or more resources is provided. The method includes obtaining a graph-based representation of the system. The method includes mapping data collected in the system to corresponding nodes in the graph-based representation of the system. The method includes training a machine learning (ML) model using the mapping of data to corresponding nodes in the graph-based representation of the system to provide configuration rules. The method includes using inductive reasoning to generate interpretations of the configuration rules, thereby obtaining interpretable configuration rules. The method includes using the interpretable configuration rules as input to a configuration solver to configure one or more resources.

[0006] A network node is provided for generating configuration rules for one or more resources. The network node includes processing circuitry and memory. The memory stores instructions executable by the processing circuitry, thereby enabling the network node to operate to obtain a graph-based representation of the system. The network node is operable to map data collected in the system to corresponding nodes in the graph-based representation of the system. The network node is operable to train a machine learning (ML) model using the mapping of data to corresponding nodes in the graph-based representation of the system to provide configuration rules. The network node is operable to use inductive reasoning to generate interpretations of the configuration rules, thereby obtaining interpretable configuration rules. The network node is operable to use the interpretable configuration rules as input to a configuration solver to configure one or more resources.

[0007] A non-transitory computer-readable medium is provided, on which instructions for generating configuration rules for one or more resources are stored. The instructions include obtaining a graph-based representation of a system. The instructions include mapping data collected in the system to corresponding nodes in the graph-based representation of the system. The instructions include training a machine learning (ML) model using the mapping of data to corresponding nodes in the graph-based representation of the system to provide configuration rules. The instructions include using inductive reasoning to generate interpretations of the configuration rules, thereby obtaining interpretable configuration rules. The instructions include using the interpretable configuration rules as input to a configuration solver to configure one or more resources.

[0008] The methods and network nodes presented in this paper offer improvements to the way configuration rules are generated for one or more resources. Attached Figure Description

[0009] Figure 1 It is a flowchart of a method used to map intents or service requests to one or more resources.

[0010] Figure 2 This is a block diagram of the proposed configuration rule generator system.

[0011] Figure 3 This is a flowchart of the proposed solution for configuration rule discovery.

[0012] Figure 4 This is a schematic diagram illustrating a service configuration example.

[0013] Figure 5 This is a flowchart of a method for generating configuration rules for one or more resources.

[0014] Figure 6 This is a schematic diagram of the hardware in which the steps and / or methods described herein can be performed.

[0015] Figure 7This is a schematic diagram of a virtualized environment in which the different steps and hardware components described herein can be deployed. Detailed Implementation

[0016] Various features will now be described with reference to the accompanying drawings in order to fully convey the scope of this disclosure to those skilled in the art.

[0017] Sequences of actions or functions may be used within this disclosure. It should be understood that, in some contexts, some functions or actions may be performed by dedicated circuitry, program instructions executed by one or more processors, or a combination of both.

[0018] Furthermore, a computer-readable carrier or carrier may contain a set of appropriate computer instructions that will cause a processor to perform the techniques described herein.

[0019] The functions / actions described herein may occur in a different order than indicated in the action sequence, or simultaneously. Furthermore, in some diagrams, certain boxes, functions, or actions may be optional and may or may not be executed; these are typically illustrated with dashed lines.

[0020] At least some aspects of the techniques described herein can be implemented using artificial intelligence, which includes a variety of techniques that will be obvious to those skilled in the art, including machine learning techniques. Machine learning techniques include neural networks (NNs), or artificial neural networks (ANNs), and these two terms may be used interchangeably herein. In some contexts, artificial neural networks may include biological components.

[0021] Furthermore, looking to the future, the technologies described in this article can be applied to relevant virtual scenarios in the virtual world (e.g., metaverse, digital twins, etc.).

[0022] Reference Figure 1 A solution 100 has been proposed in another application filed on the same day by the same inventors, entitled "Method and Network Node for Mapping Intents or Service Requests to One or More Resources," to map intent requests to relevant service expectations (according to Key Performance Indicators (KPIs)) in a service graph before configuring and deploying a service graph for services (e.g., resource configuration). Given the obtained mapping between intents and service KPIs, a configuration solver (e.g., optimization techniques) can be used to find values ​​for those KPIs. However, such techniques do not guarantee optimal solutions and are typically expensive (in terms of time and resources). Furthermore, any changes to the context and environment in which the service graph will be deployed may hinder the fulfillment of intent requests. This is because dynamic and changing cloud events / contexts are not captured.

[0023] Therefore, an improvement is proposed to capture the context in which services are deployed and generate configuration rules that can be used by configuration solvers (e.g., optimization, heuristics). The solution should be able to explain the impact of configuration rules on service KPIs to understand the rationale behind specific configuration recommendations or decisions.

[0024] As described above, the problems with existing solutions can be summarized as follows. Most existing work does not rely on configuration rules to find the expected service KPIs. Such solutions do not guarantee optimal results, and therefore, given the dynamic and changing nature of cloud environments, they do not guarantee that intended requirements will be met. When existing work defines rules to configure resources to ensure successful service execution, such rules cannot be applied to configuring service KPIs due to the number of factors that can affect service performance (e.g., user preferences, workload, application dependencies). Furthermore, the complex interdependencies between KPI services require other types of configuration rules (not just resource configuration rules).

[0025] This paper presents a system and method that proposes a machine learning model that can automatically discover configuration rules that affect service performance and help optimize the solver find better configuration solutions in a reasonable amount of time.

[0026] The solution / system proposed in this paper takes system specifications and data collected from the monitored cloud system (e.g., workload and performance-related parameters) as input, along with a set of requirement-expectation mappings: <service, KPI, requirement>. Such mappings can be obtained or generated by performing correlation analysis between the KPIs of the service and the intended requirements.

[0027] First, the solution / system builds a graph-based representation to model system specifications (by service / application, infrastructure, workload) and maps the corresponding data to the created graph. Then, the system / solution trains an ML model (e.g., a graph neural network) to provide a set of configuration rules. Finally, it uses inductive reasoning to generate generalizations from concrete observations to produce interpretable configuration rules and provides explanations for the resulting rules.

[0028] The output of the proposed system is a set of configuration rules and their interpretations for use by the configured solver (e.g., optimization model, particle swarm optimization (PSO), genetic algorithm, etc.).

[0029] This solution describes a system and method for discovering configuration rules that influence service expectations (e.g., KPIs) in a cloud environment. The proposed system develops a machine learning model capable of analyzing historical service KPI data, system specifications (by service, infrastructure, workload), and automatically discovering configuration rules that affect service performance. The proposed system analyzes the impact of configuration rules on service KPIs. The proposed system considers cloud system context data, such as workload and performance-related parameters, to optimize configuration rules. The proposed system monitors cloud system context data and updates configuration rules. When changes are detected, it generates new configuration rules or updates existing ones. The proposed system provides an explanation of the impact of configuration rules on service KPIs, explaining the rationale behind specific configuration recommendations or decisions.

[0030] The proposed system offers several advantages. It provides an automated solution to proactively generate configuration rules that influence service KPIs. It provides interpretations of the generated configuration rules to understand the rationale behind specific rules. It can generate configuration rules for different types of KPIs, such as soft KPIs, hard KPIs, and conflicting KPIs. The generated configuration rules can help reduce manual intervention in checking and identifying appropriate configurations in the service graph. It can be easily extended to support different types of KPIs.

[0031] Reference Figure 2 This paper proposes an automated solution 200 to automatically discover configuration rules that affect the performance of services in the cloud. The generated configuration rules should take into account contextual factors of the cloud service, such as workload patterns, user preferences, and environmental conditions, to optimize the configuration rules. It also provides interpretations of the configuration rules to understand the rationale behind specific configuration recommendations or decisions. Figure 2 An overview of the proposed configuration rule generator is presented, where box 205 represents the proposed solution and box 100 represents... Figure 1 The solution shown is as described.

[0032] The inputs 210 to system 200 include system specifications (e.g., running applications, infrastructure), data collected from the monitored cloud system (e.g., workload and performance-related parameters), and a set of requirement-expectation mappings generated by service expectation mapping component 100: <service, KPI, requirement> 220.

[0033] The output of system 200 consists of service configuration rules and their interpretations, which can be used by the existing "service configuration solver" 215.

[0034] The proposed service configuration system 200 models the managed cloud system 220 as a graph-based representation, where nodes represent its service KPIs, and links between nodes represent relationships between KPIs. It then maps collected data about running applications, workloads, and infrastructure to their corresponding nodes in this graph. The created graph and its data can be used to train a graph-based ML model (e.g., a graph neural network) to define configuration rules. This can help identify the different contexts in which workloads are running and capture variations at the infrastructure level. The trained ML model can then generate a set of configuration rules. Finally, it can use inductive reasoning to generate generalizations from concrete observations to produce interpretable configuration rules and provide explanations for the obtained rules.

[0035] Figure 3 The steps for discovering configuration rules are illustrated. In step 304, the solution takes data collected from the monitored cloud system 220 as input. This data describes the cloud system's contextual information 301, such as workload and performance-related parameters (e.g., relative workload distribution, service dependencies, and relative service performance metrics per unit of resource), environmental conditions, and system specifications 302 (e.g., cloud infrastructure node and link specifications). It also obtains a <service, KPI, requirement> mapping from a requirements mapping repository 305. It then transforms the collected data into a graph representation.

[0036] The nodes in the graph represent KPIs, and the links represent the connections between KPI nodes. Connections between KPIs correspond to the correlation between different KPIs. For example, a link between KPI_i and KPI_j describes how much these two KPIs influence each other. One way to measure this correlation is through Spearman's and / or Pearson's correlation measures, which can be found here: statistics.laerd.com / statistical-guides / spearmans-rank-order-correlation-statistical-guide.php. Both Spearman's and Pearson's correlations are statistical measures that assess the strength and direction of the relationship between two variables. The Pearson correlation coefficient, also known as Pearson's r, measures the linear relationship between two continuous variables. It quantifies the degree to which the variables are linearly correlated and ranges between -1 and 1. The Spearman correlation coefficient, also known as Spearman's rho(ρ), assesses the monotonic relationship between two variables. Unlike Pearson's correlation, Spearman's rho does not assume a linear relationship between variables, making it suitable for analyzing relationships that may be non-linear or non-normally distributed.

[0037] In step 306, training of the graph-based ML model begins. A graph neural network (GNN) model is used to illustrate this solution, but those skilled in the art will know and understand that other alternative models can be used interchangeably.

[0038] Training a graph-based ML model involves a series of steps. Data preparation requires collecting a dataset representing the problem domain as a labeled graph, with features, edges (if applicable), and node labels. Data preprocessing, including cleaning and encoding, ensures the data is ready for use in the model. A choice needs to be made regarding how to represent the graph, such as using an adjacency matrix. An appropriate GNN architecture also needs to be chosen, such as a graph convolutional network (GCN) or a graph attention network (GAT). Model design then follows, encompassing layer configuration, activation functions, and output specifications for label prediction. To measure model performance, a loss function, such as cross-entropy, should be defined. Training the GNN involves forward and backward propagation through the layers to update model parameters, continuing for multiple epochs until convergence. Regular validation checks help monitor model training and prevent overfitting, and adjustments can be made based on validation results. To evaluate the model's generalization ability, it is subjected to an independent test dataset with unseen data (data not used for training). When the GNN exhibits satisfactory performance, it is ready for deployment.

[0039] The input to the GNN consists of two main components: the graph structure generated in step 304, and node features; each node in the graph is associated with a set of features that provide information about that node. In this example, a node corresponds to a KPI, and the features of a KPI node may include: which service it belongs to, which VM the service is running on, the workload on that VM, etc. The output of the GNN model corresponds to three labels that can be used to create configuration rules. The three proposed labels are:

[0040] - Tag 1: Type of KPI configuration (e.g., static / dynamic);

[0041] - Tag 2: Minimum KPI value;

[0042] - Tag 3: Maximum value of KPI.

[0043] It should be noted that minimum and maximum labels are only meaningful when applicable, such as generating minimum and maximum values ​​for latency KPIs. Using those labels, configuration rules can be represented as follows: [Label 1, Label 2, Label 3] → [Configuration Type, Minimum KPI, Maximum KPI].

[0044] In step 307, a first check is performed to determine if an existing rule can be reused with a success rate greater than a defined threshold. If not, the system continues to generate configuration rules. Configuration rules for each KPI are defined as follows: [Label 1, Label 2, Label 3] or only [Label 1]. Label 1 corresponds to the type of KPI, i.e., static / dynamic. This indicates whether a given KPI configuration should be static (meaning it should be set with a fixed or predetermined value) or dynamic (meaning it should be adjusted based on changing conditions, objectives, etc.). Therefore, Label 1 exists in all rules. In contrast, depending on the nature of the KPI, Label 2 (i.e., minimum) and Label 3 (i.e., maximum) exist only when applicable. For example, Label 2 and Label 3 are applicable to KPIs such as response time and cost, but not to KPIs such as disaster recovery, which measures the ability of a cloud system to recover from failures.

[0045] Taking a latency KPI from a required mapping repository as an example, the GNN will generate rules indicating the type of latency and the range of minimum and maximum values; latency_KPI_rule = [static / dynamic, minimum latency, maximum latency].

[0046] In step 308, the solution generates possible interpretations of the generated configuration rules. This can be accomplished using inductive reasoning techniques. For this step, inductive reasoning algorithms can be used to generate generalizations from concrete observations. Inductive reasoning uses data generated from a given system to draw conclusions. Accordingly, new inference rules are constructed from the concrete to the general. This means making many observations to generate generalizations or patterns based on interpretations or theories.

[0047] Here is an example of inductive reasoning to explain why label 1 of the latency KPI rule indicates "dynamic configuration":

[0048] -Observation: The workload varies 89% of the time;

[0049] -Generalization: Based on this observation, it can be inferred that upcoming workloads will change;

[0050] - Conclusion: If new workloads arrive, they will likely change.

[0051] Therefore, this reasoning explains why there is a dynamic configuration for latency KPIs, as they should be adjusted based on changing conditions.

[0052] In step 309, the system checks whether the generated interpretable rules comply with the intent requirements received at a higher level. For example, the system may check whether the generated range for latency-type KPIs conforms to the latency thresholds defined in the intent requirements.

[0053] In step 310, if the previous step 309 produces "Yes", the rule generated for the given KPI type is saved in the configuration rule repository 311. If it produces "No", the system returns to 306 and attempts to generate a new rule for the given KPI.

[0054] It should be noted that the proposed system also operates reactively, wherein configuration rule discovery is triggered when step 303 generates an alert indicating changes in contextual factors of cloud system 220. These changes may indicate changes in workload-related parameters, modes, environmental conditions, etc. Accordingly, in step 303, an alert indicating a configuration rule update request is generated. Once the alert is received in step 304, the same steps described above are repeated to update the configuration rules.

[0055] The output of these steps is an interpretable configuration rule corresponding to each KPI. These rules are then used by the service configuration solver 215 to configure or set the precise value for each KPI.

[0056] Figure 4 The example presented shows a service graph to be configured according to latency and requests per second. An example configuration based on these two KPIs could be: {'S1': (0.81, 100.0), 'S2': (0.57, 53.0), 'S3': (0.551, 44.0), 'S4': (0.63, 48.0), 'S5': (0.50, 49.0)}, where each tuple defines (latency, requests / second).

[0057] Given this example, the following configuration rules can be defined:

[0058] - Predict workload arrival times at times t1, t2, and t3: [(t1, 100 users / sec), (t2, 200 users / sec), (t3, 150 users / sec), etc.]

[0059] Rule 1: Changes in workload arrival → then consider changes in configuration for latency time intervals (and therefore changes in resource allocation).

[0060] The rule defines the type of configuration based on the workload context.

[0061] - Predict workload arrival: to know the minimum and maximum number of users / second to be considered:

[0062] Rule 2: If the same workload is running, use the same scope and adapt the static configuration.

[0063] Rule 3: If the workload changes over time, use dynamic configuration → update those ranges each time a new context exists (new workload means the maximum latency increases).

[0064] These rules define the type of configuration, as well as the maximum and minimum values.

[0065] - Measure the failure rate at the infrastructure layer:

[0066] Rule 4: Higher values ​​are allowed, for example, for latency, if cloud nodes are experiencing high failure rates and they will host services from the service graph.

[0067] This rule defines the maximum and minimum values ​​to be configured.

[0068] Turning Figure 5 A computer-implemented method 500 for generating configuration rules for one or more resources is provided. The method includes obtaining a graph-based representation of a system 502. The method includes mapping (step 504) data collected in the system to corresponding nodes in the graph-based representation of the system. The method includes training (step 506) a machine learning (ML) model using the mapping of data to corresponding nodes in the graph-based representation of the system to provide configuration rules. The method includes using inductive reasoning to generate (step 508) an interpretation of the configuration rules, thereby obtaining interpretable configuration rules. The method includes using the interpretable configuration rules as input to a configuration solver (step 510) to configure one or more resources.

[0069] This system can be a cloud system. The graph-based representation of the system can include representations of services and applications, infrastructure, and workloads. The graph-based representation of the system can include nodes representing service key performance indicators (KPIs) and links between nodes representing relationships between KPIs. Data collected in the system can include data related to services and applications, infrastructure, and workloads, as well as corresponding nodes in the system's graph-based representation.

[0070] The ML model can be a graph neural network. The output of the ML model can include at least one label indicating the type of KPI configuration, whether static or dynamic. The output of the ML model can also include a second label indicating the minimum value of the KPI and a third label indicating the maximum value of the KPI.

[0071] Using inductive reasoning to generate interpretations of configuration rules can include generating generalizations from specific observations of data collected from the system.

[0072] The solver can be configured from any of the following: optimization model, particle swarm optimization (PSO), and genetic algorithm.

[0073] It should be noted that the methods and steps described herein are generally computer-implemented methods and steps. The term "computer" can be interpreted in different ways, such as as explained below.

[0074] Reference Figure 6 A network node (hardware) 601 is provided, in which the functions and steps described herein can be implemented.

[0075] Network node 601 (which can exceed) Figure 6 The content shown may be user devices, such as smartphones, tablets, computers, wearable devices (such as watches or glasses), connected vehicles, including but not limited to bicycles, cars, trucks, airplanes, drones, boats, or any other flying or floating vehicles.

[0076] Network node 601 can be a server, network node, radio base station, or any other computing device that is part of a cloud computing system or edge computing system, or it can be a standalone device.

[0077] Network node 601 can be an Internet of Things (IoT) device. An IoT device can be a sensor, such as a thermometer or any detector used to detect environmental conditions. An IoT device can be any type of camera and / or microphone, medical sensor, fitness tracker, etc. An IoT device can be a game console, large or small appliance (such as a refrigerator or toaster), office equipment (such as a printer), smart home device (such as a smart thermostat or lighting equipment), or any kind of smart electronic device, including but not limited to televisions or set-top boxes, voice-controlled devices, smart doorbells, alarm systems, home robots, etc.

[0078] Network node 601 is configured to provide interpretable configuration rules as input to the configuration solver to configure one or more hardware resources in the system to meet expectations and requirements.

[0079] Network node 601 includes processing circuitry 603 and memory 605. Memory 605 may store instructions executable by processing circuitry 603, thereby enabling the functions and steps described herein to be performed to provide any of the relevant features and advantages disclosed herein.

[0080] Network node 601 may also include a non-transitory, persistent, machine-readable storage medium 607 in which software and / or instructions 609 are stored, which can be executed by processing circuitry 603 to perform the functions and steps described herein. The network node may also include one or more network interfaces and a power supply.

[0081] Instruction 609 may include a computer program for configuring processing circuitry 603. The computer program may be stored in physical memory local to the device, which may be removable, or it may be alternatively or partially stored in the cloud. The computer program may also be embodied in a carrier, such as an electrical signal, optical signal, radio signal, or computer-readable storage medium.

[0082] Reference Figure 7 This document provides a virtualization environment 700 in which the functions and steps described herein can be implemented.

[0083] Virtualization environment 700 (which can exceed) Figure 7 The contents shown herein may include systems, networks, servers, nodes, devices, etc., which communicate with each other via wired or wireless means, for example, through a network interface component (NIC) that includes one or more physical network interfaces. Some or all of the functions and steps described herein may be implemented as one or more virtual components (e.g., via one or more applications, components, functions, virtual machines, containers, etc.) running on one or more physical devices in one or more networks, systems, environments, etc.

[0084] The virtualization environment provides hardware 701 including processing circuitry 703 and memory 705. Memory 705 may store instructions executable by processing circuitry 703, thereby enabling the functions and steps described herein to be performed to provide any of the relevant features and advantages disclosed herein.

[0085] Hardware 701 may also include a non-transitory, persistent, machine-readable storage medium 707 in which software and / or instructions 709 are stored, which can be executed by processing circuitry 703 to perform the functions and steps described herein.

[0086] Instruction 709 may include a computer program for configuring processing circuitry 703. The computer program may be stored in removable memory, such as a portable optical disc, portable digital video disc, or other removable media. The computer program may be stored in the physical memory local to hardware 701, which may be removable, or it may be alternatively or partially stored in the cloud. The computer program may also be embodied in a carrier, such as an electrical signal, optical signal, radio signal, or computer-readable storage medium.

[0087] Refer again Figure 6 and Figure 7A network node 601, 701 is provided for generating configuration rules for one or more resources. The network node includes processing circuitry 603, 703 and memory 605, 705. Memory 605, 705 stores instructions executable by the processing circuitry 603, 703, thereby enabling the network node to operate to obtain a graph-based representation of the system. The network node is operable to map data collected in the system to corresponding nodes in the graph-based representation of the system. The network node is operable to train a machine learning (ML) model using the mapping of data to corresponding nodes in the graph-based representation of the system to provide configuration rules. The network node is operable to use inductive reasoning to generate interpretations of the configuration rules, thereby obtaining interpretable configuration rules. The network node is operable to use the interpretable configuration rules as input to a configuration solver to configure one or more resources.

[0088] The system can be a cloud system. The graph-based representation of the system can include representations of services and applications, infrastructure, and workloads. The graph-based representation of the system can include nodes representing service key performance indicators (KPIs) and links between nodes representing relationships between KPIs. Data collected within the system can include data related to services and applications, infrastructure, and workloads, as well as corresponding nodes in the system's graph-based representation.

[0089] The ML model can be a graph neural network. The output of the ML model can include at least one label, which indicates the type of KPI configuration, whether static or dynamic. The output of the ML model can also include a second label and a third label, where the second label indicates the minimum value of the KPI and the third label indicates the maximum value of the KPI.

[0090] Using inductive reasoning to generate interpretations of configuration rules can include generating generalizations from specific observations of data collected in the system.

[0091] The solver can be configured from any of the following: optimization model, particle swarm optimization (PSO), and genetic algorithm.

[0092] Still refer to Figure 6 and Figure 7A non-transitory computer-readable medium 607, 707 is provided, on which instructions 609, 709 for generating configuration rules for one or more resources are stored. Instructions 609, 709 include obtaining a graph-based representation of the system. The instructions include mapping data collected in the system to corresponding nodes in the graph-based representation of the system. The instructions include training a machine learning (ML) model using the mapping of data to corresponding nodes in the graph-based representation of the system to provide configuration rules. The instructions include using inductive reasoning to generate an interpretation of the configuration rules, thereby obtaining interpretable configuration rules. The instructions include using the interpretable configuration rules as input to a configuration solver to configure one or more resources.

[0093] Instructions 609 and 709 may also include instructions for performing any of the steps described herein.

[0094] Modifications will arise in the mind of those skilled in the art from the teachings presented in the foregoing description and the associated drawings. Therefore, it should be understood that modifications, such as those other than the specific forms described above, are intended to be included within the scope of this disclosure. The foregoing description is merely illustrative and should not be considered restrictive in any way. The scope sought is given by the appended claims, not by the foregoing description, and all variations and equivalents falling within the scope of the claims are intended to be included therein. Although specific terms may be used herein, they are used only in a general and descriptive sense and not for limiting purposes.

Claims

1. A computer-implemented method for generating configuration rules for one or more resources, comprising: - Obtain a graph-based representation of the system; - Map the data collected in the system to the corresponding nodes in the graph-based representation of the system; - Using the mapping of the data to the corresponding nodes in the graph-based representation of the system, train a machine learning ML model to provide the configuration rules; - Inductive reasoning is used to generate interpretations of the configuration rules, thereby obtaining interpretable configuration rules; as well as - Use the interpretable configuration rules as input to the configuration solver to configure the one or more resources.

2. The method according to claim 1, wherein, The system in question is a cloud system.

3. The method according to claim 1 or 2, wherein, The graph-based representation of the system includes: service and application, infrastructure, and workload representation.

4. The method according to claim 3, wherein, The graph-based representation of the system includes nodes representing service key performance indicators (KPIs) and links between the nodes representing relationships between the KPIs.

5. The method according to claim 4, wherein, The data collected in the system includes: data related to the services and applications, the infrastructure, and the workloads, as well as the corresponding nodes in the graph-based representation of the system.

6. The method according to any one of claims 1 to 5, wherein, The ML model is a graph neural network.

7. The method according to any one of claims 1 to 6, wherein, The output of the ML model includes at least one label, which indicates the type of KPI configuration, whether static or dynamic.

8. The method according to claim 7, wherein, The output of the ML model further includes a second label and a third label, the second label indicating the minimum value of the KPI and the third label indicating the maximum value of the KPI.

9. The method according to any one of claims 1 to 8, wherein, Using inductive reasoning to generate an interpretation of the configuration rules includes generating generalizations from specific observations of the data collected in the system.

10. The method according to any one of claims 1 to 9, wherein, The configuration solver is selected from any of the following: optimization model, particle swarm optimization (PSO), and genetic algorithm.

11. A network node for generating configuration rules for one or more resources, comprising processing circuitry and a memory, the memory storing instructions executable by the processing circuitry, thereby enabling the network node to: - Obtain a graph-based representation of the system; - Map the data collected in the system to the corresponding nodes in the graph-based representation of the system; - Using the mapping of the data to the corresponding nodes in the graph-based representation of the system, train a machine learning ML model to provide the configuration rules; - Inductive reasoning is used to generate interpretations of the configuration rules, thereby obtaining interpretable configuration rules; as well as - Use the interpretable configuration rules as input to the configuration solver to configure the one or more resources.

12. The network node according to claim 11, wherein, The system in question is a cloud system.

13. The network node according to claim 11 or 12, wherein, The graph-based representation of the system includes: service and application, infrastructure, and workload representation.

14. The network node according to claim 13, wherein, The graph-based representation of the system includes nodes representing service key performance indicators (KPIs) and links between the nodes representing relationships between the KPIs.

15. The network node according to claim 14, wherein, The data collected in the system includes: data related to the services and applications, the infrastructure, and the workloads, as well as the corresponding nodes in the graph-based representation of the system.

16. The network node according to any one of claims 11 to 15, wherein, The ML model is a graph neural network.

17. The network node according to any one of claims 11 to 16, wherein, The output of the ML model includes at least one label, which indicates the type of KPI configuration, whether static or dynamic.

18. The network node according to claim 17, wherein, The output of the ML model further includes a second label and a third label, the second label indicating the minimum value of the KPI and the third label indicating the maximum value of the KPI.

19. The network node according to any one of claims 11 to 18, wherein, Using inductive reasoning to generate an interpretation of the configuration rules includes generating generalizations from specific observations of the data collected in the system.

20. The network node according to any one of claims 11 to 19, wherein, The configuration solver is selected from any of the following: optimization model, particle swarm optimization (PSO), and genetic algorithm.

21. A non-transitory computer-readable medium storing thereon instructions for generating configuration rules for one or more resources, the instructions comprising: - Obtain a graph-based representation of the system; - Map the data collected in the system to the corresponding nodes in the graph-based representation of the system; - Using the mapping of the data to the corresponding nodes in the graph-based representation of the system, train a machine learning ML model to provide the configuration rules; - Inductive reasoning is used to generate interpretations of the configuration rules, thereby obtaining interpretable configuration rules; as well as - Use the interpretable configuration rules as input to the configuration solver to configure the one or more resources.

Images