A cloud network scenario diagnosis platform based on decision tree

Abstract

This invention discloses a cloud network scenario-based diagnostic platform based on decision trees for end-to-end full-link network diagnosis. Addressing the root cause diagnosis problem when tenant end-to-end traffic anomalies occur, this invention proposes a multi-node full-link network diagnostic scheme based on decision trees. It designs decision logic based on expert experience, solving the decoupling and judgment of complex decision logic through root cause judgment with multiple combinations of conditions. It transforms the original independent condition judgments into state machine-based judgments, overcoming the challenges of long access links, numerous anomaly information, and difficulty in comprehensive root cause judgment faced by traditional diagnostic technologies. This diagnostic platform can be deployed on large-scale production cloud network operation and maintenance platforms and can be widely applied to the anomaly diagnosis of various network components such as virtual private networks, public network access, load balancing, and leased line access.

Description

Technical Field

[0001] This invention relates to the field of cloud network anomaly detection and diagnosis, and in particular to a decision tree-based cloud network scenario-based diagnostic platform that can be deployed on large-scale cloud network operation and maintenance platforms. Background Technology

[0002] Cloud networks are custom networks shared by multiple tenants. As cloud network scales, the frequency and complexity of tenant data interactions also increase. End-to-end transmission of tenant data involves numerous forwarding devices and paths. Therefore, any anomaly in any part of the forwarding path can lead to network failures, triggering a domino effect of network performance degradation and substantial economic losses. To avoid losses caused by large-scale anomalies, network engineers have deployed numerous monitoring systems. However, in end-to-end cloud network transmission scenarios, how to sift through massive amounts of network monitoring data and pinpoint the root cause of anomalies is a critical challenge that urgently needs to be addressed in the cloud networking field.

[0003] Current mainstream cloud network anomaly diagnosis solutions include network simulation solutions and network testing solutions. The core idea of ​​network simulation solutions is to reconstruct the network based on the policies and connection information of forwarding devices, obtain a structural simulation model, and then simulate tenant behavior based on this model. Based on the simulation results, a network diagnosis is attempted. Network testing solutions initiate connectivity tests, communication status tests, and service tests on the target application on the terminal device, layer by layer to confirm possible anomalies and attempt to achieve timely and comprehensive analysis of the causes of network communication status anomalies.

[0004] Existing solutions are not well adapted to large-scale real-world network scenarios and cannot effectively mine end-to-end anomaly information. Their main drawbacks are as follows:

[0005] 1. Network simulation solutions replace the existing environment with computing resources, which is detached from the real environment. At the resource level, they cannot cover the complete live network environment 1:1, including the hardware attributes of the devices, software versions, and tenant personalized configurations.

[0006] 2. Network testing solutions cannot determine which forwarding device on the link the anomaly occurred at.

[0007] 3. Neither of the above two types of network diagnostic solutions fully utilizes the large amount of effective digital information that has been generated and accumulated in the actual operation of the network, including logs, metrics, traces, etc., and does not involve the comprehensive decision-making logic between different abnormal information. Summary of the Invention

[0008] The purpose of this invention is to address the shortcomings of existing technologies by designing an end-to-end network scenario-based diagnostic platform that can be deployed in large-scale cloud networks for use by various network components, including virtual private networks, public network access, load balancing, and leased line access.

[0009] The objective of this invention is achieved through the following technical solution: a cloud network scenario-based diagnostic platform based on decision trees, which includes the following modules:

[0010] Configuration Management Module: Used to manage all configuration information required for scenario-based decision-making, abstracted into node management, rule management, and root cause management;

[0011] Configuration parsing module: Uses Petri net structure to realize structured transformation of node, rule and root cause information in decision tree;

[0012] Decision execution module: including scheduler, token management submodule, ignition triggering submodule and result output submodule, responsible for loading decision tree information and executing diagnostic decisions after the user triggers the scenario-based diagnosis;

[0013] The scheduler uses the JBPM process engine and, based on the token and transition management-driven decision tree process structure, has the multi-condition process management capability that requires all tasks to be completed before proceeding to the next step.

[0014] The token management submodule is used to calculate and execute the changes in token distribution caused by the occurrence of transitions;

[0015] The ignition triggering submodule: when all the preceding storages of a certain transition have tokens, the transition condition is met, that is, ignition occurs. When igniting, a token is taken out from each of the preceding storages according to the conditions, and a token is put into each of the subsequent storages.

[0016] The result output submodule is used to write the diagnostic decision results into the decision database and output them uniformly to the user.

[0017] Furthermore, the node is a virtual entity used to carry rules; the rule is logic that can be judged by a general regular expression; multiple rules are supported under the same node, and the multiple rules are independent of each other; the basic event library obtains abnormal event information after matching the node rules.

[0018] Furthermore, the root cause is the high-order reason for the occurrence of a problem when faced with numerous anomalous event information; the root cause analysis configuration includes two parts:

[0019] The edges connecting each node describe the necessary matching conditions when the rules configured on the starting node are "satisfied" or "not satisfied". A root cause supports "AND" and "OR" combinations of multiple conditions, presenting the characteristics of multiple combination conditions.

[0020] The root cause configuration information includes basic descriptive information and user-coded anomaly analysis, enabling complex root cause logic analysis and possessing customization capabilities.

[0021] Furthermore, when a diagnostic event is triggered, the analysis results of multiple root causes are ultimately presented based on the deduction of the decision tree and the different matching of nodes and rules.

[0022] Furthermore, the basic principles of the Petri net include places, transitions, directed arcs, tokens, and association matrices;

[0023] The decision tree nodes corresponding to the libraries represent characteristic entities with product attributes;

[0024] The transition corresponds to the node's rules, the result matching conditions of the rules, and the AND / OR condition judgment of the edges linking different nodes.

[0025] The directed arcs correspond to the edges of the decision tree between nodes;

[0026] If the matching result of the rule execution in the node corresponding to the token is successful and a match is achieved in the basic event library according to the rule, it means that the token has been effectively obtained and the necessary condition for triggering the corresponding transition has been met. Otherwise, the transition cannot be triggered.

[0027] Furthermore, the execution process of the decision execution module includes the following steps:

[0028] S1, Configuration Preloading: Based on the instance type input by the user, all configurations of the decision tree are loaded into the cache to complete the structuring of static configuration information;

[0029] S2, Data Matrix Construction: Constructing data matrices from the perspective of change, divided into input token data construction and output token data construction;

[0030] S3, Reachability Analysis: Based on the dynamic reachability principle of Petri nets, decision analysis is achieved through a token management mechanism. The different distributions of tokens indicate the current status of the decision-making process.

[0031] S4, Output: Write the diagnostic decision results into the decision database.

[0032] Furthermore, the construction of the data matrix includes:

[0033] Input token data construction: Based on the structured information of S1, associate it with the basic event library, and execute event judgment according to the rule configuration order on the node. If the rule is matched successfully, it is equivalent to obtaining the token and setting the memory matrix space value to 1; otherwise, it is set to 0.

[0034] Output token data construction: Tokens are formed based on the AND-OR result value in the transition. If the result is true, the token is set to 1; otherwise, it is set to 0.

[0035] Furthermore, in the reachability analysis, Petri net migration analysis and cloud network diagnostic services are integrated, so that the decision logic changes from the original mutually independent condition judgments to a state machine transition calculation.

[0036] Furthermore, the platform is integrated into the diagnostic system through diagnostic item invocation. Each diagnostic item corresponds to a decision tree-based diagnostic scenario, and efficient execution is achieved through parallel asynchronous triggering of diagnostic items.

[0037] Compared with the prior art, the present invention has the following advantages:

[0038] This invention designs a decision logic based on expert experience, which solves the decoupling and judgment of complex decision logic by judging the root cause of multiple combined conditions; this invention transforms the original mutually independent condition judgments into state machine-based judgments, improving the efficiency of root cause investigation from several hours to minute-level fault location; this invention greatly reduces the number of diagnostic items through the decision tree scheme. Attached Figure Description

[0039] Figure 1 This is an architecture diagram of a cloud network scenario-based diagnostic platform based on decision trees provided in an embodiment of the present invention;

[0040] Figure 2 This is a schematic diagram of a diagnostic decision tree containing multiple rules, multiple combinations of conditions, and multiple root causes, provided in an embodiment of the present invention.

[0041] Figure 3 This is a schematic diagram of the configuration management module page provided in an embodiment of the present invention;

[0042] Figure 4 This is a basic framework diagram of the Petri network provided in the embodiments of the present invention;

[0043] Figure 5 This is a simplified information structured matrix after loading a Petri net decision tree, as provided in this embodiment of the invention.

[0044] Figure 6 This is a schematic diagram illustrating the construction of input token data and the output token data provided in an embodiment of the present invention;

[0045] Figure 7 This is a schematic diagram of the reachability analysis logic provided in an embodiment of the present invention;

[0046] Figure 8 This is a diagram showing the virtual machine private network disconnection decision tree structure and configuration results provided in this embodiment of the invention;

[0047] Figure 9 This is a graph showing the performance optimization results of the decision tree provided in an embodiment of the present invention. Detailed Implementation

[0048] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings.

[0049] Many specific details are set forth in the following description in order to provide a full understanding of the invention. However, the invention may also be practiced in other ways different from those described herein, and those skilled in the art can make similar extensions without departing from the spirit of the invention. Therefore, the invention is not limited to the specific embodiments disclosed below.

[0050] like Figure 1 As shown in the embodiments of this application, a cloud network scenario-based diagnostic platform based on decision trees is proposed. This platform is integrated into the overall diagnostic system through diagnostic item invocation. Each diagnostic item corresponds to a decision tree-based diagnostic scenario, and efficient execution is achieved through parallel and asynchronous triggering of diagnostic items. The platform includes a configuration management module, a configuration parsing module, and a decision execution module. These three modules collaborate to manage and escape the nodes, rules, and root cause judgment logic of the decision tree, and achieve rapid diagnosis based on decision tree technology. The specific implementation process of each module is described in detail below.

[0051] (1) Configuration Management Module: This module is responsible for managing all configuration information required for scenario-based decision-making. It is further abstracted into node management, rule management, and root cause management. The combination of these three forms a similar... Figure 2 A decision tree structure.

[0052] Specifically, a node can represent either a device through which a message passes or a specific feature object on that device; a node is a virtual entity used to carry rules. For example... Figure 2 As shown in the diagram, the virtual switch, elastic computer, and elastic network interface are nodes. In addition to the ones shown in the diagram, they can also support more than 20 cloud network products, such as Alibaba Cloud public IP products, bandwidth package products, and load balancing products.

[0053] The rule described is a logical condition that can be determined using general regular expressions. For example, "CPU utilization > 95%" is a typical rule. Multiple rules are supported under the same node, and they are independent of each other. The basic event library, when matched against node rules, can obtain abnormal event information upon a match. The basic event library and the rules are connected via a data SQL engine. For example, matching a combination of conditions for a physical network card packet loss event caused by high CPU utilization:

[0054] (event.type=="NC_ETH_IN_PPS_DROP" or event.type=="nc_net_card_in_pps_drop")and("AVS_CPU_HIGH" in types or "nc_cpu_exceed_limit" in types)

[0055] The root cause refers to how to effectively determine the high-order causes of a problem when faced with numerous abnormal event information. The root cause analysis configuration is divided into two parts: 1) such as... Figure 2 The edges connecting each node are used to describe the necessary matching conditions when the rules configured on the starting node are "satisfied" or "not satisfied". A root cause supports "AND" and "OR" combinations of multiple conditions, presenting the characteristics of multiple combination conditions; 2) When configuring the root cause node, in addition to basic descriptive information such as root cause name, remarks, and risk level, it also supports user-coded anomaly analysis, implements complex root cause logic analysis through Python scripts, and has customization capabilities.

[0056] When a diagnostic event is triggered, the analysis results of multiple root causes are presented based on the deduction of the decision tree and the different matching of nodes and rules.

[0057] Figure 2 This is a schematic diagram of a diagnostic decision tree containing multiple rules, multiple combinations of conditions, and multiple root causes, taking the example of a virtual machine private network being inaccessible. Figure 3 This is an example of how to implement a configuration management module page.

[0058] (2) Configuration and Parsing Module: This module uses a Petri net structure to perform structured transformation of information such as nodes, rules, and root causes in the decision tree. The basic principles of Petri nets include the concepts of place (P), transition (T), directed arc (F), token, and association matrix. For the basic principles of Petri nets, see [link to Petri net configuration module]. Figure 4 .

[0059] Specifically, the place (P) corresponds to the decision tree node in this case, representing a characteristic entity with product attributes. The root cause itself is also a P node, the only difference being that it will not trigger the next transition T.

[0060] Transition (T) corresponds to the rules of the nodes in this case, the matching conditions of the rule results, and the AND-OR condition judgment of the edges linking different nodes.

[0061] A directed arc (F) corresponds to an edge in the decision tree between nodes in this case. Like the F in a Petri net, the edges of the decision tree are directional.

[0062] The token corresponds to the matching of the rule execution result in the node of this case. If the rule is matched in the basic event library, it means that the token is effectively obtained and the necessary condition for triggering the corresponding T is triggered. Otherwise, the transition of T cannot be triggered.

[0063] (3) Decision execution module: It includes scheduler, token management, ignition trigger and result output sub-modules. After the user triggers the scenario-based diagnosis through the one-click diagnosis platform, it is responsible for loading the entire decision tree information and executing the diagnosis decision.

[0064] Specifically, the scheduler uses the open-source JBPM process engine, which drives a decision tree process structure based on token and transition management, and has the ability to manage multi-condition processes where multiple tasks must all be completed before proceeding to the next step.

[0065] The token management submodule is responsible for calculating and executing changes in the token distribution when certain conditions are met. The different distributions of tokens represent the evolution of the system's dynamic behavior.

[0066] The ignition trigger submodule is used when all preceding storage locations of a certain transition have tokens. This transition condition is met, i.e., ignition occurs. During ignition, one token is taken from each preceding storage location according to the condition, and one token is put into each of the subsequent storage locations. The entire process is carried out in this manner.

[0067] The results output submodule is responsible for writing the diagnostic decision results into the decision database so that they can be uniformly output to users.

[0068] The execution steps of the decision execution module are as follows: configuration preloading → data matrix construction → reachability analysis → result output.

[0069] Step 1, Configuration Preloading. Based on the instance type input by the user, such as a cloud virtual machine instance, all configurations of the decision tree are loaded into the system cache, completing the structuring of static configuration information. For example... Figure 5 The figure shows the information structure matrix after loading a simplified Petri net decision tree.

[0070] Step 2, Data Matrix Construction. The overall construction is from the perspective of transition (T), and is divided into two parts: input token data construction and output token data construction. 1) Input token data construction: During the matrix data construction process, the structured information from Step 1 is associated with the basic event library. Event judgments are executed according to the rule configuration order on the nodes. If the rule matches successfully, it is equivalent to obtaining a token, and the value in the memory matrix space is set to 1; otherwise, it is set to 0. 2) Output token data construction: Tokens are formed based on the "AND / OR" result value in the transition. If the calculation result is true, it is set to 1; otherwise, it is set to 0. The overall result is as follows: Figure 6 As shown.

[0071] Step 3, Reachability Analysis. Based on the dynamic reachability principle of Petri nets, an initial identifier P1 is used. If there exists a series of transitions t1, t2, ..., tn such that P1 transforms into Pn, then identifier Pn is said to be reachable from P0. Decision analysis is achieved through a token management mechanism. Different token distributions indicate the current state of the decision-making process. If a transition occurs, the number of input locations is not equal to the number of output locations, i.e., the number of tokens consumed = the number of predecessor locations - the number of successor locations. The above token matrix calculation logic relies on the PIPE library (version 4.3), which can integrate Petri net migration analysis and cloud network diagnostic services. This transforms the original independent conditional judgments into a state machine transition calculation, thus reducing the root cause investigation time to 1 / 6 of the original solution. Furthermore, taking elastic computer instance diagnostics as an example, the number of diagnostic items before and after the introduction of the decision tree converges from 65 to 20, enhancing scenario-based decision-making capabilities. The detailed implementation of reachability analysis is as follows... Figure 7 As shown.

[0072] Step 4, Results Output: This step involves writing the diagnostic decision results into the decision database for unified output to users.

[0073] Decision tree nodes represent rule-based judgments based on expert experience, such as... Figure 8 The image shows a case study of a decision tree structure and configuration results for a virtual machine with a disabled private network. Figure 9 Experimental results were used to optimize the performance of the decision tree.

[0074] The above description is merely a preferred embodiment of the present invention. Although the present invention has been disclosed above with reference to preferred embodiments, it is not intended to limit the present invention. Any person skilled in the art can make many possible variations and modifications to the technical solutions of the present invention using the methods and techniques disclosed above, or modify them into equivalent embodiments with equivalent changes, without departing from the scope of the technical solutions of the present invention. Therefore, any simple modifications, equivalent changes, and modifications made to the above embodiments based on the technical essence of the present invention without departing from the content of the technical solutions of the present invention shall still fall within the protection scope of the technical solutions of the present invention.

Claims

1. A cloud network scenario-based diagnostic platform based on decision trees, characterized in that, Includes the following modules: Configuration Management Module: Used to manage all configuration information required for scenario-based decision-making, abstracted into node management, rule management, and root cause management; Configuration parsing module: Uses Petri net structure to realize structured transformation of node, rule and root cause information in decision tree; Decision execution module: including scheduler, token management submodule, ignition triggering submodule and result output submodule, responsible for loading decision tree information and executing diagnostic decisions after the user triggers the scenario-based diagnosis; The scheduler uses the JBPM process engine and, based on the token and transition management-driven decision tree process structure, has the multi-condition process management capability that requires all tasks to be completed before proceeding to the next step. The token management submodule is used to calculate and execute the changes in token distribution caused by the occurrence of transitions; The ignition triggering submodule: when all the preceding storages of a certain transition have tokens, the transition condition is met, that is, ignition occurs. When igniting, a token is taken out from each of the preceding storages according to the conditions, and a token is put into each of the subsequent storages. The result output submodule is used to write the diagnostic decision results into the decision database and output them uniformly to the user; The execution process of the decision execution module includes the following steps: S1, Configuration Preloading: Based on the instance type input by the user, all configurations of the decision tree are loaded into the cache to complete the structuring of static configuration information; S2, Data Matrix Construction: Constructing a data matrix from the perspective of change, divided into input token data construction and output token data construction; S3, Reachability Analysis: Based on the dynamic reachability principle of Petri nets, decision analysis is achieved through a token management mechanism. The different distributions of tokens indicate the current status of the decision-making process. S4, Output: Write the diagnostic decision results into the decision database.

2. The platform according to claim 1, characterized in that, The node is a virtual entity used to carry rules; the rule is logic that can be judged by a general regular expression; multiple rules are supported under the same node, and the multiple rules are independent of each other; the basic event library obtains abnormal event information after the node rules are matched.

3. The platform according to claim 1, characterized in that, The root cause is the high-order cause of a problem when faced with numerous abnormal event information; the root cause analysis configuration includes two parts: The edges connecting each node describe the necessary matching conditions when the rules configured on the starting node are "satisfied" or "not satisfied". A root cause supports "AND" and "OR" combinations of multiple conditions, presenting the characteristics of multiple combination conditions. The root cause configuration information includes basic descriptive information and user-coded anomaly analysis, enabling complex root cause logic analysis and possessing customization capabilities.

4. The platform according to claim 1, characterized in that, When a diagnostic event is triggered, the analysis results of multiple root causes are presented based on the deduction of the decision tree and the different matching of nodes and rules.

5. The platform according to claim 1, characterized in that, The basic principles of Petri nets include places, transitions, directed arcs, tokens, and association matrices; The decision tree nodes corresponding to the libraries represent characteristic entities with product attributes; The transition corresponds to the node's rules, the result matching conditions of the rules, and the "AND / OR" condition judgment of the edges linking different nodes. The directed arcs correspond to the edges of the decision tree between nodes; If the matching result of the rule execution in the node corresponding to the token is successful and a match is achieved in the basic event library according to the rule, it means that the token has been effectively obtained, thus triggering the necessary conditions for the corresponding transition. Otherwise, the transition cannot be triggered.

6. The platform according to claim 1, characterized in that, The construction of the data matrix includes: Input token data construction: Based on the structured information of S1, associate it with the basic event library, and execute event judgment according to the rule configuration order on the node. If the rule is matched successfully, it is equivalent to obtaining the token and setting the memory matrix space value to 1; otherwise, it is set to 0. Output token data construction: Tokens are formed based on the AND-OR result value in the transition. If the result is true, the token is set to 1; otherwise, it is set to 0.

7. The platform according to claim 1, characterized in that, In the reachability analysis, Petri net migration analysis and cloud network diagnostic services are integrated, so that the decision logic changes from the original independent condition judgments to a state machine transition calculation.

8. The platform according to any one of claims 1-7, characterized in that, The platform is integrated into the diagnostic system through diagnostic item invocation. Each diagnostic item corresponds to a diagnostic scenario based on a decision tree, and efficient execution is achieved through parallel asynchronous triggering of diagnostic items.

Images