Network root cause analysis method and device based on persistent diagnostic session, equipment and medium

Abstract

The application discloses a network root cause analysis method and device based on a persistent diagnostic session, equipment and medium, relates to the technical field of computers, and comprises the following steps: creating or restoring a diagnostic session object corresponding to a network diagnostic request; constructing an inference context for the current diagnostic round and generating diagnostic decision information based on the diagnostic process state of the diagnostic session object; when the diagnostic decision information indicates that a diagnostic tool needs to be called, determining the current allowed tool permission level based on the diagnostic confidence information, calling a target diagnostic tool matching the current allowed tool permission level, and obtaining a tool execution result; updating the hypothesis set and the diagnostic confidence information based on the tool execution result, obtaining an updated diagnostic process state, and performing persistent processing on the updated diagnostic session object. It can be seen that the application reduces the situation of re-executing part of the diagnostic process after the network diagnostic task is interrupted, and improves the continuity and efficiency of the network root cause analysis process.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a method, apparatus, device, and medium for network root cause analysis based on persistent diagnostic sessions. Background Technology

[0002] As enterprise networks, data centers, and telecommunications networks continue to expand, network failures often involve multiple network domains, including wired networks, wireless networks, security devices, and application systems. A single root cause can trigger a large number of superficial alarms, making it difficult for operations and maintenance personnel to quickly pinpoint the true cause of the failure. Existing network diagnostic systems mainly include rule-based or decision tree-based troubleshooting systems, machine learning-based alarm correlation and fault classification systems, and chatbot-based intelligent troubleshooting systems. Among these, rule-based or decision tree-based solutions rely on manually pre-written rules, making it difficult to cover complex, novel, or compound faults; machine learning-based solutions typically focus on alarm correlation, fault classification, or handling suggestions, making it difficult to support continuous multi-round diagnostic reasoning and closed-loop diagnostic tool invocation; while chatbot-based solutions can interact with operations and maintenance personnel, their sessions are usually mainly used to carry message content, making it difficult to continuously save information related to the current diagnostic process, such as candidate fault causes, diagnostic confidence levels, and diagnostic tool execution results.

[0003] Therefore, when a network diagnostic task requires multiple diagnostic rounds, or when a diagnostic task is paused or interrupted and needs to be resumed, the existing system is prone to problems such as insufficient connection between the preceding and following diagnostic processes, difficulty in continuing to utilize existing diagnostic states, difficulty in retaining diagnostic evidence, and the need to re-execute some diagnostic processes, thereby affecting the continuity and efficiency of network root cause analysis. Summary of the Invention

[0004] In view of this, the purpose of this invention is to provide a network root cause analysis method, apparatus, device, and medium based on persistent diagnostic sessions, which reduces the need to re-execute parts of the diagnostic process after a network diagnostic task is interrupted, thereby improving the continuity and efficiency of the network root cause analysis process. The specific solution is as follows: In a first aspect, this application discloses a network root cause analysis method based on persistent diagnostic sessions, including: Create or restore a diagnostic session object corresponding to a network diagnostic request; wherein, the diagnostic session object is used to record the diagnostic process status of the corresponding network diagnostic task; the diagnostic process status includes at least a set of hypotheses characterizing the causes of candidate faults and diagnostic confidence information corresponding to the set of hypotheses; Based on the diagnostic process state of the diagnostic session object, a reasoning context for the current diagnostic round is constructed; Diagnostic decision information is generated based on the reasoning context; When the diagnostic decision information indicates that a diagnostic tool needs to be invoked, the currently allowed tool permission level is determined based on the diagnostic confidence information in the diagnostic process status, and the target diagnostic tool that matches the currently allowed tool permission level is invoked to obtain the tool execution result; wherein, the diagnostic tool is used to perform network operation status reading, active detection, or network configuration modification on the network device being diagnosed, and the tool permission level is divided according to the degree of influence of the diagnostic tool on the network device being diagnosed; The hypothesis set and diagnostic confidence information are updated based on the execution results of the tool to obtain the updated diagnostic process state. The updated diagnostic session object is then persisted so that the network diagnostic task can resume execution based on the persisted diagnostic process state after an interruption.

[0005] Optionally, the network root cause analysis method based on persistent diagnostic sessions further includes: Scan multiple active diagnostic session objects according to a preset scanning cycle, and extract the set of faulty devices and the diagnostic trigger time from each diagnostic session object; The diagnostic session objects whose diagnostic trigger times fall within a preset time window are divided into candidate aggregation groups, and the corresponding candidate common upstream nodes are determined based on the candidate aggregation groups; Query the change events related to the candidate public upstream node within the preset time window from the preset change management system; Based on the candidate common upstream node, the change event, and each diagnostic session object in the candidate aggregation group, common cause analysis information is generated; The common cause analysis information is written into each of the diagnostic session objects within the candidate aggregation group, so that each of the diagnostic session objects within the candidate aggregation group includes the common cause analysis information in the inference context of subsequent diagnostic rounds.

[0006] Optionally, the process of determining the candidate common upstream node includes: The sets of faulty devices corresponding to each diagnostic session object within the candidate aggregation group are merged to obtain the set of faulty devices within the group. Based on the device nodes in the set of faulty devices within the group, a reverse topology traversal is performed in the knowledge graph according to a preset number of hops to determine the candidate common upstream node.

[0007] Optionally, the reasoning context includes at least one of the following: topological subgraph information extracted from the knowledge graph, and historical diagnostic reference information obtained from the historical root cause analysis retrieval library.

[0008] Optionally, the network root cause analysis method based on persistent diagnostic sessions further includes: When the current session state of the diagnostic session object is either root cause confirmation completed or transition to manual processing, target decision information is extracted from the reasoning trajectory of the diagnostic session object; wherein, the target decision information includes key tool call information for eliminating or confirming hypotheses in the hypothesis set; Extract effective tool combination patterns from the tool call history of the diagnostic session object; wherein, the effective tool combination patterns include tool call sequences related to the root cause analysis process; Based on the target decision information, the effective tool combination mode, and the target feedback information, structured knowledge entries are generated; wherein, the target feedback information includes at least one of the following: diagnostic results for the network diagnostic task, verification information of the diagnostic process or the tool execution results, supplementary information, or correction information; The structured knowledge entries are vectorized. The vectorized structured knowledge entries are written into the historical root cause analysis retrieval database.

[0009] Optionally, the step of determining the currently allowed tool permission level based on the diagnostic confidence information in the diagnostic process status, and calling the target diagnostic tool that matches the currently allowed tool permission level to obtain the tool execution result, includes: Based on the degree of impact of the diagnostic tool on the network device being diagnosed, the diagnostic tool is divided into multiple tool permission levels; wherein, the multiple tool permission levels include a first permission level for performing network operation status reading, a second permission level for performing active probing, and a third permission level for performing network configuration modification; Determine the confidence value represented by the diagnostic confidence information; When the confidence level is less than the first threshold, the first permission level is determined as the currently allowed tool permission level; When the confidence value is not less than the first threshold and less than the second threshold, the first permission level and the second permission level are determined as the currently allowed tool permission levels; When the confidence level is not lower than the second threshold, the first permission level, the second permission level, and the third permission level are determined as the currently allowed tool permission levels. Specifically, when the target diagnostic tool belongs to the third permission level, the current session state of the diagnostic session object is updated to the pending approval state; after receiving the approval information, the target diagnostic tool is invoked to obtain the tool execution result.

[0010] Optionally, before invoking the target diagnostic tool belonging to the third permission level, the method further includes: A diagnostic intent lock with a validity period is set for the target network device on which the target diagnostic tool operates; wherein, the diagnostic intent lock is used to record the operation intent corresponding to the target network device, the diagnostic session object, and the target diagnostic tool; When other diagnostic session objects request to perform an operation on the target network device that conflicts with the operational intent and belongs to the third permission level within the validity period, the operation is rejected.

[0011] Optionally, before invoking the target diagnostic tool belonging to the third permission level, the method further includes: Invoke the change simulation tool to simulate the impact of network configuration modifications corresponding to the target diagnostic tool on at least one of the network topology, access control list, or routing table, and obtain change prediction information; The change prediction information will be used as approval material for the target diagnostic tool.

[0012] Optionally, the network root cause analysis method based on persistent diagnostic sessions further includes: Upon receiving a pause request, resume request, or transfer request for the diagnostic session object, the diagnostic session object is switched in session state or updated with collaboration information. Diagnostic process log information related to the session state switching or collaboration information update is written into the diagnostic session object to support the suspension, resumption or transfer of the network diagnostic task.

[0013] Optionally, the network root cause analysis method based on persistent diagnostic sessions further includes: External tools are accessed via open tool protocols, and corresponding tool permission levels are configured for the accessed external tools; wherein, the external tools include external diagnostic tools and / or external intelligent agents; The external tool is invoked to obtain the external execution result; The call records of the external tools, the permission levels of the tools, and the external execution results are written into the diagnostic process state of the diagnostic session object, and the updated diagnostic session object is persisted.

[0014] Secondly, this application discloses a network root cause analysis device based on persistent diagnostic sessions, comprising: The session management module is used to create or restore diagnostic session objects corresponding to network diagnostic requests; wherein, the diagnostic session object is used to record the diagnostic process status of the corresponding network diagnostic task; the diagnostic process status includes at least a set of hypotheses characterizing the causes of candidate faults and diagnostic confidence information corresponding to the set of hypotheses; The context enhancement module is used to construct an inference context for the current diagnostic round based on the diagnostic process state of the diagnostic session object. The intelligent diagnostic module is used to generate diagnostic decision information based on the reasoning context; The hierarchical execution module is used to determine the currently allowed tool permission level based on the diagnostic confidence information in the diagnostic process status when the diagnostic decision information indicates that a diagnostic tool needs to be invoked, and to invoke the target diagnostic tool that matches the currently allowed tool permission level to obtain the tool execution result; wherein, the diagnostic tool is used to perform network operation status reading, active detection, or network configuration modification on the network device being diagnosed, and the tool permission level is divided according to the degree of influence of the diagnostic tool on the network device being diagnosed; The session management module is further configured to update the hypothesis set and the diagnostic confidence information based on the tool execution results, obtain the updated diagnostic process state, and persist the updated diagnostic session object so that the network diagnostic task can resume execution based on the persisted diagnostic process state after interruption.

[0015] Thirdly, this application discloses an electronic device, comprising: Memory, used to store computer programs; A processor is configured to execute the computer program to implement the aforementioned disclosed network root cause analysis method based on persistent diagnostic sessions.

[0016] Fourthly, this application discloses a computer-readable storage medium for storing a computer program; wherein, when the computer program is executed by a processor, it implements the aforementioned network root cause analysis method based on persistent diagnostic sessions.

[0017] As can be seen, this application proposes a network root cause analysis method based on persistent diagnostic sessions, characterized by the following steps: creating or restoring a diagnostic session object corresponding to a network diagnostic request; wherein, the diagnostic session object is used to record the diagnostic process state of the corresponding network diagnostic task; the diagnostic process state includes at least a set of hypotheses characterizing candidate fault causes and diagnostic confidence information corresponding to the set of hypotheses; constructing an inference context for the current diagnostic round based on the diagnostic process state of the diagnostic session object; generating diagnostic decision information based on the inference context; when the diagnostic decision information indicates that a diagnostic tool needs to be invoked, determining the currently allowed tool permission level based on the diagnostic confidence information in the diagnostic process state, and invoking a target diagnostic tool that matches the currently allowed tool permission level to obtain the tool execution result; wherein, the diagnostic tool is used to perform network operation status reading, active probing, or network configuration modification on the network device being diagnosed, and the tool permission level is divided according to the degree of impact of the diagnostic tool on the network device being diagnosed; updating the hypothesis set and diagnostic confidence information based on the tool execution result to obtain the updated diagnostic process state, and persisting the updated diagnostic session object so that the network diagnostic task can resume execution based on the persistent diagnostic process state after interruption. As can be seen, by creating or restoring a diagnostic session object corresponding to a network diagnostic request, and using the diagnostic session object to record the diagnostic process status of the corresponding network diagnostic task, the network diagnostic task can construct the inference context of the current diagnostic round based on the recorded hypothesis set and the diagnostic confidence information corresponding to the hypothesis set, and generate diagnostic decision information based on the inference context. When it is necessary to call a diagnostic tool, the currently allowed tool permission level is determined based on the diagnostic confidence information, and the target diagnostic tool that matches the currently allowed tool permission level is called, so that the network operation status reading, active detection, or network configuration modification are aligned with the current diagnostic confidence. Information is matched; simultaneously, the hypothesis set and diagnostic confidence information are updated based on the tool execution results, enabling subsequent diagnostic rounds to continue based on the updated diagnostic process state; furthermore, by persisting the updated diagnostic session object, network diagnostic tasks can resume execution based on the persisted diagnostic process state after interruption, thus allowing different diagnostic rounds to connect using existing diagnostic process states, reducing the need to re-execute parts of the diagnostic process after network diagnostic task interruption, improving the utilization of existing diagnostic states, and facilitating the preservation of diagnostic evidence for network diagnostic tasks, thereby improving the continuity and efficiency of the network root cause analysis process. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0019] Figure 1 This application discloses a flowchart of a network root cause analysis method based on persistent diagnostic sessions. Figure 2 This is a schematic diagram of the state transition of a diagnostic session object disclosed in this application; Figure 3 This is a schematic diagram of the structure of a network root cause analysis device based on persistent diagnostic sessions disclosed in this application; Figure 4 This is a structural diagram of an electronic device disclosed in this application. Detailed Implementation

[0020] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0021] When a network diagnostic task requires multiple diagnostic rounds, or when a diagnostic task is paused or interrupted and needs to be resumed, existing systems are prone to problems such as insufficient connection between the preceding and following diagnostic processes, difficulty in continuing to utilize existing diagnostic states, difficulty in retaining diagnostic evidence, and the need to re-execute some diagnostic processes. These problems affect the continuity and efficiency of network root cause analysis, and the above-mentioned technical issues urgently need to be addressed by those in the field.

[0022] To address this, this application proposes a network root cause analysis scheme based on persistent diagnostic sessions, which reduces the need to re-execute parts of the diagnostic process after a network diagnostic task is interrupted, thereby improving the continuity and efficiency of the network root cause analysis process.

[0023] This application discloses a network root cause analysis method based on persistent diagnostic sessions. See also Figure 1 As shown, the method includes: Step S11: Create or restore the diagnostic session object corresponding to the network diagnostic request; wherein, the diagnostic session object is used to record the diagnostic process status of the corresponding network diagnostic task; the diagnostic process status includes at least a set of hypotheses characterizing the causes of candidate faults and diagnostic confidence information corresponding to the set of hypotheses.

[0024] In this embodiment, upon receiving a network diagnostic request, a query is performed to determine if a diagnostic session object corresponding to the request exists. If no corresponding diagnostic session object exists, a new one is created; if a corresponding diagnostic session object already exists, it is restored, and the corresponding network diagnostic task continues to be executed based on the diagnostic process status recorded therein. The diagnostic session object records the diagnostic process status as the network diagnostic task is executed. This status includes at least a set of hypotheses and diagnostic confidence information corresponding to the set of hypotheses. The set of hypotheses records candidate fault causes formed during the network diagnostic process, and the diagnostic confidence information characterizes the diagnostic confidence level of the corresponding candidate fault cause. In some embodiments, the diagnostic session object may also record inference trajectory, tool call history, faulty device set, current session status, collaboration information, checkpoint information, and diagnostic process record information. The current session status characterizes the current processing stage of the diagnostic session object, including at least one of the following: created, active, pending approval, paused, transferred to manual processing, root cause confirmation completed, and archived. Figure 2 As shown, the created state indicates that the diagnostic session object has been created and is waiting to start diagnostic inference; the active state indicates that diagnostic inference is currently underway; the pending approval state indicates that approval for the corresponding operation is pending; the paused state indicates that the current network diagnostic task is paused; the transferred to manual processing state indicates that the current network diagnostic task has been taken over by a human; the root cause confirmation completed state indicates that the root cause of the current network diagnostic task has been confirmed; and the archived state indicates that the diagnostic session object has been archived. The collaboration information is used to record relevant information when the network diagnostic task is collaborated or transferred between different processing personnel, and the checkpoint information is used to record the state snapshot formed by the network diagnostic task at the corresponding diagnostic stage.

[0025] Furthermore, in some embodiments, upon receiving a pause request, resume request, or transfer request for the diagnostic session object, the diagnostic session object can be switched or its collaboration information updated accordingly, and diagnostic process record information related to the session state switch or collaboration information update can be written into the diagnostic session object to support the pause, resume, or transfer of network diagnostic tasks.

[0026] In this embodiment, upon receiving a pause request, the current session state of the diagnostic session object is switched to a paused state, the generation of subsequent diagnostic decision information corresponding to the current diagnostic round is stopped, and the hypothesis set, diagnostic confidence information, inference trajectory, tool call history, and tool execution results already formed in the current diagnostic round are written into the checkpoint information to form a state snapshot corresponding to the current diagnostic process and retain the diagnostic process state formed before the pause. Upon receiving a resume request, the hypothesis set, diagnostic confidence information, inference trajectory, and tool execution results saved in the checkpoint information are read, and the inference context of the current diagnostic round is reconstructed based on the information to continue executing the network diagnostic task from the paused position. Upon receiving a transfer request, the collaboration information in the diagnostic session object is updated, the current handler is updated to the target handler, and the handler before the transfer, the target handler, and the corresponding diagnostic process state at the time of the transfer are recorded in the transfer history, so that the target handler can read the persistent inference trajectory, tool call history, tool execution results, hypothesis set, and diagnostic confidence information in the diagnostic session object, and continue executing the network diagnostic task based on the diagnostic process information.

[0027] Step S12: Based on the diagnostic process state of the diagnostic session object, construct the reasoning context for the current diagnostic round.

[0028] In this embodiment, a reasoning context for the current diagnostic round is constructed based on the diagnostic process status already recorded in the diagnostic session object. This reasoning context provides the current diagnostic round with diagnostic information related to the network diagnostic task, enabling the current diagnostic round to continue diagnostic reasoning by combining previously formed hypothesis sets, diagnostic confidence information, and relevant diagnostic information. In some embodiments, the reasoning context includes at least one of topology subgraph information extracted from a knowledge graph and historical diagnostic reference information obtained from a historical root cause analysis retrieval library. The knowledge graph records network devices and the topological relationships and / or dependencies between them. Each network device corresponds to a device node in the knowledge graph. The topological relationships characterize the topological connections between different network devices, and the dependencies characterize the associative dependencies between different network devices. The historical root cause analysis retrieval library is a vector retrieval library for storing and retrieving vectorized historical diagnostic information. By vectorizing the query information corresponding to the current network diagnostic task, matching historical diagnostic reference information is retrieved from the historical root cause analysis retrieval library based on vector similarity.

[0029] In some embodiments, common cause analysis is performed on multiple active diagnostic session objects. Specifically, multiple active diagnostic session objects are scanned according to a preset scanning cycle, and a set of faulty devices and a diagnostic trigger time are extracted from each diagnostic session object. Multiple diagnostic session objects whose diagnostic trigger times fall within a preset time window are divided into candidate aggregation groups. The candidate aggregation group represents a set of multiple diagnostic session objects whose diagnostic trigger times fall within the same preset time window. Based on the candidate aggregation group, a corresponding candidate common upstream node is determined. The candidate common upstream node represents a device node in the network topology that has a common upstream relationship with multiple faulty devices in the candidate aggregation group. After determining the candidate common upstream node, change events related to the candidate common upstream node within the preset time window are queried from a preset change management system, and common cause analysis information is generated based on the candidate common upstream node, the change events, and each diagnostic session object in the candidate aggregation group. The common cause analysis information is used to characterize fault cause information that may be commonly associated among multiple network diagnostic tasks in the candidate aggregation group, and includes the candidate common upstream node and the change events related to the candidate common upstream node. After generating the common cause analysis information, the common cause analysis information is written into each diagnostic session object within the candidate aggregation group, so that the corresponding diagnostic session object includes the common cause analysis information when constructing the inference context in subsequent diagnostic rounds. The preset change management system is used to record change events occurring in the network and the network devices involved in the corresponding change events.

[0030] The candidate common upstream node is determined based on the set of faulty devices corresponding to each diagnostic session object within the candidate aggregation group. Specifically, the sets of faulty devices corresponding to each diagnostic session object within the candidate aggregation group are merged to obtain a set of faulty devices within the group. The faulty devices in the set of faulty devices within the group are mapped to device nodes in the knowledge graph, and a reverse topology traversal is performed in the knowledge graph according to a preset number of hops, starting from the device node corresponding to the faulty device, to determine the candidate common upstream node. The reverse topology traversal refers to searching for upstream nodes along the upstream direction of the network topology according to a preset number of hops, starting from the device node corresponding to the faulty device. Specifically, the upstream nodes corresponding to each device node within the preset number of hops are determined, and the candidate common upstream node is determined based on the common relationships between the upstream nodes corresponding to multiple device nodes. The preset number of hops is a pre-set reverse topology traversal range, used to limit the maximum topology level searched upstream along the network topology from the device node corresponding to the faulty device.

[0031] In this way, by combining the faulty device information, diagnosis trigger time, candidate common upstream nodes and related change events corresponding to multiple diagnostic session objects in the above manner, common cause analysis information is formed, and the common cause analysis information is written into the corresponding diagnostic session object, so that subsequent diagnostic rounds can utilize the diagnostic information that is commonly associated between multiple related network diagnostic tasks when constructing the inference context.

[0032] Step S13: Generate diagnostic decision information based on the reasoning context.

[0033] In this embodiment, diagnostic decision information is generated based on the inference context of the current diagnostic round. This diagnostic decision information characterizes the subsequent diagnostic processing method corresponding to the current diagnostic round. Specifically, based on at least one of the hypothesis set, diagnostic confidence information, topology subgraph information, historical diagnostic reference information, and common cause analysis information contained in the inference context, the diagnostic progress of the current network diagnostic task is judged, and corresponding diagnostic decision information is generated accordingly. For example, when the existing diagnostic information is insufficient to confirm the cause of the current candidate fault, diagnostic decision information is generated to instruct the invocation of diagnostic tools to further obtain network operating status information or active probing results related to the cause of the current candidate fault; as another example, when the existing diagnostic information can support a judgment on the cause of the current candidate fault, diagnostic decision information is generated to characterize the current diagnostic conclusion; and as yet another example, when the network diagnostic task cannot be further advanced based on the current inference context, diagnostic decision information is generated to instruct manual processing.

[0034] In specific implementation, the inference context is organized into input information for the inference model according to a preset structure. This input information includes the hypothesis set and diagnostic confidence values ​​corresponding to each candidate fault cause, the topology subgraph information, historical diagnostic reference information, existing tool call history and tool execution results, and a list of available diagnostic tool identifiers under the current allowed tool permission level, along with the input parameter definitions for each tool. The inference model outputs structured diagnostic decision information, which includes at least the decision type, the target diagnostic tool identifier, the input parameters required to call the target diagnostic tool, and an update instruction for the hypothesis set. The decision type includes calling a diagnostic tool, outputting a diagnostic conclusion, and transferring to manual processing. Before calling the target diagnostic tool, the diagnostic decision information is validated: if the diagnostic decision information does not conform to the preset structure, the tool call is not executed and the diagnostic decision information is regenerated; if the target diagnostic tool identifier does not belong to the list of available diagnostic tool identifiers, the tool call is refused, no corresponding instruction is issued to the network device being diagnosed, and the refusal record and reason are written into the diagnostic process status of the diagnostic session object. The inference model runs on a server equipped with a graphics processor, and its input information, including topology subgraph information and tool execution results, comes from the measured network operation data of the network device being diagnosed.

[0035] Step S14: When the diagnostic decision information indicates that a diagnostic tool needs to be invoked, the current allowed tool permission level is determined based on the diagnostic confidence information in the diagnostic process status, and the target diagnostic tool that matches the current allowed tool permission level is invoked to obtain the tool execution result; the diagnostic tool is used to perform network operation status reading, active detection or network configuration modification on the network device being diagnosed, and the tool permission level is divided according to the degree of influence of the diagnostic tool on the network device being diagnosed.

[0036] In this embodiment, when diagnostic decision information indicates the need to invoke a diagnostic tool, the diagnostic tools are divided into different tool permission levels according to their impact on the diagnosed network device. The currently allowed tool permission level is determined based on the diagnostic confidence information in the diagnostic process status, and the target diagnostic tool is selected from the diagnostic tools corresponding to the currently allowed tool permission level. Specifically, the diagnostic tools are divided into a first permission level, a second permission level, and a third permission level. The first permission level corresponds to the L1 permission level and is used to perform network operation status reading; the second permission level corresponds to the L2 permission level and is used to perform active probing; the third permission level corresponds to the L3 permission level and is used to perform network configuration modification. Network operation status reading is used to obtain the operation status information of the diagnosed network device, such as device status query or log reading; active probing is used to obtain diagnostic information by probing the diagnosed network device or related network links, such as connectivity detection, path tracing, or packet capture; network configuration modification is used to change the configuration or operation status of the diagnosed network device, such as interface restart or configuration rollback. After determining the currently allowed tool permission level, the target diagnostic tool that matches the diagnostic decision information is selected from the diagnostic tools corresponding to the corresponding tool permission level, and then invoked according to the execution flow corresponding to the target diagnostic tool to obtain the tool execution result.

[0037] It should be noted that before invoking the target diagnostic tool, the tool permission level to which the target diagnostic tool belongs is compared with the currently allowed tool permission level. If the tool permission level to which the target diagnostic tool belongs does not belong to the currently allowed tool permission level, the tool invocation is refused, no corresponding read, probe, or configuration modification instructions are issued to the network device being diagnosed, and the refusal record and the reason for refusal are written into the diagnostic process status of the diagnostic session object.

[0038] When determining the currently allowed tool permission level, a confidence value represented by diagnostic confidence information is determined. When the hypothesis set includes multiple candidate fault causes, the maximum value among the diagnostic confidence values ​​corresponding to each candidate fault cause is used as the confidence value for determining the currently allowed tool permission level. The corresponding tool permission level is determined based on the relationship between the confidence value and a first threshold and a second threshold, where the first threshold is less than the second threshold. When the confidence value is less than the first threshold, the first permission level is determined as the currently allowed tool permission level. When the confidence value is not less than the first threshold and less than the second threshold, the first and second permission levels are determined as the currently allowed tool permission levels. When the confidence value is not less than the second threshold, the first, second, and third permission levels are determined as the currently allowed tool permission levels. In this way, the range of currently allowed diagnostic tools is adjusted according to the diagnostic confidence level formed during network diagnosis, matching diagnostic tools with different levels of execution impact to the current diagnostic confidence level. The first and second thresholds for different network diagnostic scenarios can be set according to the impact of the diagnostic tool's execution and the diagnostic requirements. In the specific test scenario below, the first threshold is set to 0.15 and the second threshold is set to 0.85, for example. The above thresholds are only exemplary values ​​for this specific test scenario. In other network diagnostic scenarios, other thresholds can be adopted according to the impact of the diagnostic tool's execution and the diagnostic requirements.

[0039] In some embodiments, the confidence value is determined based on diagnostic evidence related to the candidate fault cause. The diagnostic evidence includes supporting evidence for the corresponding candidate fault cause and contradictory evidence that contradicts the corresponding candidate fault cause. The confidence value for the corresponding candidate fault cause is adjusted based on the supporting and contradictory evidence, and the confidence value is determined in conjunction with the exclusion status of candidate fault causes in the hypothesis set, so that the confidence value reflects the degree of support for the corresponding candidate fault cause from the diagnostic information obtained during the current diagnostic process. Specifically, the confidence value can be determined based on the number of supporting evidence items, the number of contradictory evidence items, and the proportion of excluded candidate fault causes. For example, let the number of supporting evidence items be... The number of contradictory evidence items is Assume that the number of candidate fault causes in the set, excluding the current candidate fault cause, is . The number of candidate causes of failure that have been ruled out is Then, according to Determine the degree of support of the evidence, based on The degree of hypothesis exclusion is determined, and a confidence value in the range of 0 to 1 is determined based on the degree of evidence support and the degree of hypothesis exclusion. For example, the average of the two can be used as the confidence value. In other embodiments, an initial confidence value for the corresponding candidate fault cause is first generated, and then the initial confidence value is calibrated based on the measured network indicators returned by the diagnostic tool. Specifically, corresponding supporting or contradictory evidence can be determined based on the measured network indicators, and the initial confidence value is re-determined or adjusted according to the aforementioned method for determining confidence values. It should be noted that the measured network indicators include at least one of interface status, packet loss rate, latency, and configuration comparison results. Based on the determined confidence value, the currently allowed tool permission level is determined, and the corresponding tool invocation process is executed according to the tool permission level to which the target diagnostic tool belongs.

[0040] When the target diagnostic tool belongs to the first or second permission level, it is invoked to perform corresponding network operation status reading or active probing to obtain the tool execution result. When the target diagnostic tool belongs to the third permission level, before actually invoking the target diagnostic tool to perform network configuration modification, diagnostic intent conflict detection and change rehearsal are performed on the network configuration modification corresponding to the target diagnostic tool, and the target diagnostic tool is invoked to perform the corresponding network configuration modification after approval. Specifically, before invoking the target diagnostic tool belonging to the third permission level, a diagnostic intent lock with a valid period is set for the target network device to which the target diagnostic tool is applied. The diagnostic intent lock is used to record the target network device, the current diagnostic session object, and the operation intent corresponding to the target diagnostic tool. The operation intent is used to characterize the network configuration modification that the current diagnostic session object intends to perform on the target network device through the target diagnostic tool. When other diagnostic session objects request to perform operations belonging to the third permission level on the same target network device within the valid period, the operation intent corresponding to the other diagnostic session objects is compared with the operation intent recorded in the diagnostic intent lock; when the two conflict, the operation requested by the other diagnostic session objects is rejected. The diagnostic intent lock is released when the validity period of the diagnostic intent lock expires, the corresponding diagnostic session ends, or a lock release operation is received.

[0041] Furthermore, before actually invoking the target diagnostic tool belonging to the third permission level, a change simulation tool is invoked to simulate the network configuration modifications corresponding to the target diagnostic tool, and to determine the impact of the network configuration modifications on at least one of the network topology, access control lists, or routing tables, thus obtaining change prediction information. It is understood that this change prediction information is used to characterize the network changes that may occur after the actual execution of the network configuration modifications, and serves as approval material for the target diagnostic tool. Subsequently, the current session state of the diagnostic session object is updated to a pending approval state, awaiting approval for the target diagnostic tool; upon receiving approval information, the target diagnostic tool is invoked to perform the corresponding network configuration modifications on the diagnosed network device, obtaining the tool execution result.

[0042] It should also be noted that when creating a new diagnostic session object, the hypothesis set is initialized to an initial candidate fault cause set generated based on the network diagnostic request, and the diagnostic confidence value corresponding to each initial candidate fault cause is initialized to 0. In this way, in the first diagnostic round before any tool execution results are obtained, the currently allowed tool permission level only includes the first permission level for performing network running status reading.

[0043] Step S15: Update the hypothesis set and the diagnostic confidence information based on the tool execution results to obtain the updated diagnostic process state, and persist the updated diagnostic session object so that the network diagnostic task can resume execution based on the persisted diagnostic process state after interruption.

[0044] In this embodiment, after obtaining the tool execution result, the tool execution result is parsed into supporting evidence or contradictory evidence for the corresponding candidate fault cause. When the tool execution result contradicts the corresponding candidate fault cause, the candidate fault cause is excluded from the hypothesis set. When the tool execution result points to a new candidate fault cause, the candidate fault cause is added to the hypothesis set. Following the aforementioned method for determining diagnostic confidence values, the diagnostic confidence values ​​corresponding to each candidate fault cause in the hypothesis set are re-determined based on the supporting evidence or contradictory evidence formed by the tool execution result in this round. The re-determined diagnostic confidence values ​​are written to the diagnostic session object to obtain the updated diagnostic process status. After each diagnostic round, the updated diagnostic session object is persisted. The persistence process includes writing the session identifier, current session status, hypothesis set, diagnostic confidence information, inference trajectory, tool call history, and tool execution result recorded in the diagnostic session object into persistent storage. The persistent storage is a non-volatile storage independent of the inference process's runtime memory, such as a relational database. After the network diagnostic task is interrupted due to process exit, system restart, or manual pause, the current session state, hypothesis set, diagnostic confidence information, inference trajectory, tool call history, and tool execution results of the corresponding diagnostic session object are read from the persistent storage based on the session identifier. The diagnostic session object and its corresponding inference context are then reconstructed based on this information to continue the network diagnostic task from the diagnostic rounds completed before the interruption, thus avoiding the need to re-execute the previously completed diagnostic rounds. Specifically, the checkpoint information generated upon receiving a pause request for the diagnostic session object is a snapshot of the diagnostic process state of the diagnostic session object at the time the pause request is received. This checkpoint information and the persistent processing performed after each diagnostic round use the same persistent storage; the difference lies in the timing of the writes.

[0045] In this embodiment, when the current session state of the diagnostic session object is either root cause confirmation complete or transition to manual processing, diagnostic information for generating structured knowledge entries is extracted from the diagnostic session object. Specifically, target decision information is extracted from the reasoning trajectory of the diagnostic session object. This target decision information includes key tool call information used to exclude or confirm corresponding hypotheses in the hypothesis set. Effective tool combination patterns are extracted from the tool call history of the diagnostic session object. These effective tool combination patterns include tool call sequences related to the root cause analysis process. After extracting the target decision information and effective tool combination patterns, structured knowledge entries are generated by combining them with target feedback information. The target feedback information includes at least one of the following: diagnostic results for the network diagnostic task, verification information of the diagnostic process or tool execution results, supplementary information, or correction information, used to verify, supplement, or correct the corresponding diagnostic information. Subsequently, the structured knowledge entries are vectorized, and the vectorized structured knowledge entries are written into the historical root cause analysis retrieval library, enabling subsequent network diagnostic tasks to retrieve historical diagnostic reference information related to the current network diagnostic task from the historical root cause analysis retrieval library when constructing the reasoning context.

[0046] In some embodiments, external tools are accessed via an open tool protocol, and corresponding tool permission levels are configured for the accessed external tools. An open tool protocol refers to a communication protocol used to standardize the connection, tool capability information, invocation requests, and execution result return methods between the diagnostic system and external tools. For example, the open tool protocol can be a Model Context Protocol (MCP). Through the MCP, the diagnostic system can obtain the callable capability information of external tools, send invocation requests to external tools, and receive corresponding external execution results. The external tools include external diagnostic tools and / or external intelligent agents. An external intelligent agent refers to an external program entity that accesses the system via the open tool protocol, can receive diagnostic task descriptions, autonomously execute corresponding diagnostic subtasks, and return execution results. After accessing the external tool, a corresponding tool permission level is configured for the external tool based on the operation type of the external tool and the degree of execution impact on the diagnosed network device. The degree of execution impact characterizes the extent to which the external tool's invocation process affects the diagnosed network device. When an external tool is used to obtain the operational status information of the network device being diagnosed, the external tool is configured with a low level of execution impact and a first level of permission for reading the network operational status. When an external tool is used to perform active probing on the network device being diagnosed or related network links, the external tool is configured with a medium level of execution impact and a second level of permission for performing active probing. When an external tool is used to modify the network configuration of the network device being diagnosed, the external tool is configured with a high level of execution impact and a third level of permission for performing network configuration modification.

[0047] Furthermore, when an external tool needs to be invoked, the external tool to be invoked is determined based on the matching relationship between the tool permission level corresponding to the external tool and the currently allowed tool permission level, and the external tool is invoked to obtain the external execution result. After the external tool invocation is completed, the external tool invocation record, the tool permission level, and the external execution result are written into the diagnostic process state of the diagnostic session object, and the updated diagnostic session object is persisted. In this way, the diagnostic information generated during the external tool invocation process can be saved along with the diagnostic session object.

[0048] The following example illustrates the network root cause analysis method based on persistent diagnostic sessions. This example uses a network failure where finance department users cannot access the Enterprise Resource Planning (ERP) system as a specific test scenario. The main points are as follows: An incorrect Access Control List (ACL) rule was configured on the GigabitEthernet 1 / 0 / 12 interface of the access layer switch sw-acc-3. This ACL rule blocked the access of the finance department user IP address range 10.10.20.0 / 24 to the internal ERP server 10.50.1.100. After this failure occurred, the physical connection status of the interface remained normal, but network layer communication between the finance department user and the ERP server was interrupted, manifesting as ERP system access timeouts. The maintenance personnel entered a network diagnostic request for the finance department user Alice's inability to access the ERP system. The network root cause analysis system created a corresponding diagnostic session object for the network diagnostic request and continuously updated the diagnostic session object in subsequent diagnostic rounds.

[0049] T represents the trigger time of the network diagnostic request, and all subsequent times are based on this trigger time. Table 1 shows the diagnostic process performed for the network failure that user Alice cannot access the ERP system. The diagnostic confidence value shown in each diagnostic round in Table 1 is the diagnostic confidence value corresponding to the candidate fault cause with the highest value in the corresponding round.

[0050] Table 1. Diagnostic procedures performed for network failures preventing user Alice from accessing the ERP system.

[0051] After receiving the approval information, the corresponding network configuration modification interface is invoked to execute the ACL configuration rollback corresponding to work order #12345. Approximately 5 minutes after T+1, the configuration rollback is complete. Alice re-accesses the ERP system and confirms that network access has returned to normal. This confirms that the "ACL error rule introduced by work order #12345" is the root cause of the current network failure, and the diagnostic session object is updated to the root cause confirmation completed status. The tool call records, tool permission levels, tool execution results, changes in candidate fault causes, and changes in diagnostic confidence generated during the above diagnostic process are all persisted along with the diagnostic session object. The diagnostic confidence levels corresponding to this specific test process are 0.18, 0.42, 0.71, 0.83, and 0.92, respectively. When the diagnostic confidence levels are 0.18, 0.42, 0.71, and 0.83, respectively, all below the second threshold of 0.85, the actual number of calls to the network configuration modification tool at the third permission level is 0. Only when the diagnostic confidence level increases to 0.92 is entry into the network configuration modification process corresponding to the third permission level permitted, and an ACL configuration rollback is performed after completing diagnostic intent conflict detection, change rehearsal, and approval. In this way, network configuration modification tools are restricted from being called when diagnostic evidence is insufficient and diagnostic confidence is low.

[0052] In another test targeting the same fault scenario, after completing configuration reading and updating the diagnostic confidence to 0.71, a pause request was received, the current session state was switched to a paused state, and the currently formed hypothesis set, diagnostic confidence information, inference trajectory, tool call history, and tool execution results were written into the checkpoint information. Upon receiving a subsequent recovery request, the checkpoint information was read and the inference context was reconstructed, resuming execution from subsequent diagnostic rounds. Interface status queries, connectivity probes, and configuration readings already performed before the pause did not need to be re-executed.

[0053] In contrast, under the same fault scenario, if the diagnostic session object is not persisted, the three tool calls mentioned above need to be executed again when the diagnosis is restarted after an interruption. In this embodiment, the number of repeated tool calls is 0, compared to 3 in the control method. Therefore, persisting the diagnostic session can reduce repeated tool calls to the network device being diagnosed during the interruption recovery process.

[0054] In contrast, under the same diagnostic process and toolkit, the tool permission level restriction based on diagnostic confidence was disabled, ensuring that the network configuration modification tool at the third permission level was available for invocation in all diagnostic rounds. The comparison results show that in four diagnostic rounds with diagnostic confidence levels below the second threshold of 0.85 (0.18, 0.42, 0.71, and 0.83 respectively), the third permission level tool in this embodiment was invoked 0 times, while in the control method, it was invoked 4 times. This demonstrates that by restricting the tool permission level based on diagnostic confidence, the number of times network configuration modification operations are performed during periods of insufficient diagnostic evidence is reduced.

[0055] Furthermore, under the aforementioned comparison method, when the diagnostic confidence level has not yet reached the second threshold, the network configuration modification tool at the third-level authority may perform configuration modifications on the diagnosed network device based on candidate fault causes that have not yet been fully confirmed. If the configuration modification is inconsistent with the actual fault cause, it may lead to an expansion of the original fault scope, and an additional rollback of the configuration modification will be required after the actual fault cause is determined. In contrast, this embodiment restricts the invocation of the third-level authority tool when the diagnostic confidence level is below the second threshold, thereby reducing the execution of erroneous configuration modifications on the diagnosed network device during the stage of insufficient diagnostic evidence and the resulting additional rollback operations.

[0056] In the specific testing process described above, the convergence of the network diagnostic task can be determined based on the diagnostic confidence level and the objective verification results returned by the diagnostic tool. Specifically, when the diagnostic confidence level of the current candidate fault cause reaches a preset convergence threshold, there is no unprocessed contradictory evidence, and the network operating status or the verification result after configuration modification returned by the diagnostic tool is consistent with the candidate fault cause, the network diagnostic task is determined to meet the convergence condition, iterative diagnosis is stopped, and the diagnostic session object is updated to the root cause confirmation completion status. The preset convergence threshold characterizes the minimum diagnostic confidence level required to confirm the current candidate fault cause. This preset convergence threshold can be set based on the diagnostic confidence level distribution corresponding to historically confirmed root cause cases, a second threshold, and the diagnostic requirements of the current network diagnostic scenario. Different network diagnostic scenarios can use different preset convergence thresholds. For cases involving network configuration modifications, the objective verification results can include the elimination of the corresponding fault phenomenon after the configuration modification or the restoration of network operating indicators related to the fault to a preset normal range. The preset normal range characterizes the value range corresponding to the network operating indicator when it is in normal operating condition and can be determined based on the operating parameters of the diagnosed network device, historical normal operating data, or a pre-set network operating threshold. Convergence conditions are used to characterize the conditions that must be met for the current network diagnostic task to stop iterative diagnosis and confirm the candidate fault cause as the root cause.

[0057] Furthermore, after the network diagnostic task is completed, key tool call information used to troubleshoot physical layer faults, identify network layer communication anomalies, locate ACL rejection rules, and confirm relevant network changes is extracted from the reasoning trajectory of the diagnostic session object. Valid tool call sequences formed by interface status queries, connectivity probes, configuration reads, system change queries, and historical diagnostic information retrieval are also extracted from the tool call history. Combined with verification information from the ERP system's recovery, structured knowledge entries are generated. These structured knowledge entries are then vectorized and written into a historical root cause analysis retrieval database, enabling the retrieval of relevant historical diagnostic reference information when similar ACL configuration faults occur subsequently. The source diagnostic session identifier corresponding to the structured knowledge entries can also be recorded to distinguish historical diagnostic knowledge generated by different diagnostic sessions.

[0058] After testing the above scenarios, the diagnostic process took approximately 5 minutes. The first-level permission tool was invoked twice, the second-level permission tool was invoked once, and cross-system information queries were completed through external tools accessed via MCP. The diagnostic information generated in each diagnostic round, the tool execution results, and changes in the diagnostic process were saved along with the diagnostic session object, thereby preserving the diagnostic information generated in the corresponding network diagnostic process.

[0059] In one specific deployment method, the server used to perform the aforementioned network root cause analysis process is implemented using Python, FastAPI, and PostgreSQL, with hardware resources including an 8-core processor, 32GB of memory, and 500GB of solid-state storage. The knowledge graph is implemented using the Neo4j Community 5.x graph database, with hardware resources including a 4-core processor, 16GB of memory, and 200GB of storage. The historical root cause analysis retrieval library is implemented using a Chroma or Milvus vector database, with hardware resources including a 4-core processor, 16GB of memory, and 100GB of storage. The inference module is implemented using an external inference interface or a local vLLM inference framework, with two A100 graphics processors used in local deployment. The MCP server cluster reuses the existing diagnostic application programming interface (API), configured with a 4-core processor and 8GB of memory, and different tool permission levels are configured for the corresponding diagnostic tools. The workflow orchestration of the diagnostic process is implemented using the LangGraph and LangChain frameworks, configured with a 2-core processor and 8GB of memory. All components are deployed in the enterprise intranet to complete network diagnostic processing and related diagnostic data processing within the enterprise.

[0060] In scenarios with multiple concurrent network diagnostic tasks, when multiple network diagnostic requests generate multiple active diagnostic session objects within a similar timeframe, common cause analysis is performed on these multiple diagnostic session objects. For example, every 30 seconds, the set of faulty devices and the diagnostic trigger time of each active diagnostic session object are extracted. Diagnostic session objects whose diagnostic trigger times fall within a 5-minute time window are divided into candidate aggregation groups, and the sets of faulty devices in the candidate aggregation groups are merged. Starting from the device node corresponding to each faulty device, a reverse traversal is performed in the knowledge graph along the upstream direction of the network topology according to the three-hop range. Candidate common upstream nodes are determined based on the common relationships between the upstream node sets corresponding to different device nodes. Then, network change events related to the candidate common upstream nodes within the time window are queried, and the candidate common upstream nodes and related change events are written into the corresponding diagnostic session objects for use in subsequent diagnostic rounds.

[0061] Furthermore, the aforementioned network root cause analysis methods can also be applied to network operation and maintenance of AI clusters in data centers, such as remote direct memory access (RDMA) faults, aggregated communication anomalies, and training task lag diagnosis for graphics processing unit (GPU) nodes; to multi-cloud network interconnection operation and maintenance, such as cross-cloud software-defined wide area network (SD-WAN), virtual private network (VPN), and peer-to-peer connection fault diagnosis; to industrial control network fault diagnosis and isolation in smart manufacturing networks; and to fault location of fifth-generation mobile communication networks and IP Multimedia Subsystem (IMS) in operator core networks.

[0062] As can be seen, this application proposes a network root cause analysis method based on persistent diagnostic sessions, characterized by the following steps: creating or restoring a diagnostic session object corresponding to a network diagnostic request; wherein, the diagnostic session object is used to record the diagnostic process state of the corresponding network diagnostic task; the diagnostic process state includes at least a set of hypotheses characterizing candidate fault causes and diagnostic confidence information corresponding to the set of hypotheses; constructing an inference context for the current diagnostic round based on the diagnostic process state of the diagnostic session object; generating diagnostic decision information based on the inference context; when the diagnostic decision information indicates that a diagnostic tool needs to be invoked, determining the currently allowed tool permission level based on the diagnostic confidence information in the diagnostic process state, and invoking a target diagnostic tool that matches the currently allowed tool permission level to obtain the tool execution result; wherein, the diagnostic tool is used to perform network operation status reading, active probing, or network configuration modification on the network device being diagnosed, and the tool permission level is divided according to the degree of impact of the diagnostic tool on the network device being diagnosed; updating the hypothesis set and diagnostic confidence information based on the tool execution result to obtain the updated diagnostic process state, and persisting the updated diagnostic session object so that the network diagnostic task can resume execution based on the persistent diagnostic process state after interruption. As can be seen, by creating or restoring a diagnostic session object corresponding to a network diagnostic request, and using the diagnostic session object to record the diagnostic process status of the corresponding network diagnostic task, the network diagnostic task can construct the inference context of the current diagnostic round based on the recorded hypothesis set and the diagnostic confidence information corresponding to the hypothesis set, and generate diagnostic decision information based on the inference context. When it is necessary to call a diagnostic tool, the currently allowed tool permission level is determined based on the diagnostic confidence information, and the target diagnostic tool that matches the currently allowed tool permission level is called, so that the network operation status reading, active detection, or network configuration modification are aligned with the current diagnostic confidence. Information is matched; simultaneously, the hypothesis set and diagnostic confidence information are updated based on the tool execution results, enabling subsequent diagnostic rounds to continue based on the updated diagnostic process state; furthermore, by persisting the updated diagnostic session object, network diagnostic tasks can resume execution based on the persisted diagnostic process state after interruption, thus allowing different diagnostic rounds to connect using existing diagnostic process states, reducing the need to re-execute parts of the diagnostic process after network diagnostic task interruption, improving the utilization of existing diagnostic states, and facilitating the preservation of diagnostic evidence for network diagnostic tasks, thereby improving the continuity and efficiency of the network root cause analysis process.

[0063] Building upon the above embodiments, this embodiment further provides an implementation method that combines persistent diagnostic sessions with predictive session preloading. The aforementioned embodiments primarily described the creation or recovery of diagnostic sessions after a network diagnostic request arrives, the updating of diagnostic process status, the invocation of diagnostic tools, and the persistence processing of diagnostic session objects. This embodiment further describes the process of writing the context information into the diagnostic session object, enabling the diagnostic session object to utilize the pre-acquired context information to enter the subsequent diagnostic reasoning process.

[0064] The context information is written into the diagnostic process state of the diagnostic session object corresponding to the network diagnostic request, and an inference context for the current diagnostic round is constructed based on the written diagnostic process state. After entering the diagnostic inference process, the corresponding network diagnostic task continues to be executed according to the aforementioned diagnostic session processing method. Specifically, the inference context for the current diagnostic round is constructed based on the diagnostic process state recorded in the diagnostic session object, and diagnostic decision information is generated based on the inference context; when the diagnostic decision information indicates that a diagnostic tool needs to be called, the currently allowed tool permission level is determined based on the diagnostic confidence information in the diagnostic process state, and the target diagnostic tool matching the currently allowed tool permission level is called to obtain the tool execution result; the hypothesis set and diagnostic confidence information are updated based on the tool execution result to obtain the updated diagnostic process state, and the updated diagnostic session object is persisted.

[0065] Accordingly, embodiments of this application also disclose a network root cause analysis device based on persistent diagnostic sessions, see [link to relevant documentation]. Figure 3 As shown, the device includes: The session management module 11 is used to create or restore a diagnostic session object corresponding to a network diagnostic request; wherein, the diagnostic session object is used to record the diagnostic process status of the corresponding network diagnostic task; the diagnostic process status includes at least a set of hypotheses characterizing the causes of candidate faults and diagnostic confidence information corresponding to the set of hypotheses; The context enhancement module 12 is used to construct a reasoning context for the current diagnostic round based on the diagnostic process state of the diagnostic session object. The intelligent diagnosis module 13 is used to generate diagnostic decision information based on the reasoning context; The hierarchical execution module 14 is used to determine the currently allowed tool permission level based on the diagnostic confidence information in the diagnostic process status when the diagnostic decision information indicates that a diagnostic tool needs to be invoked, and to invoke the target diagnostic tool that matches the currently allowed tool permission level to obtain the tool execution result; wherein, the diagnostic tool is used to perform network operation status reading, active detection, or network configuration modification on the network device being diagnosed, and the tool permission level is divided according to the degree of influence of the diagnostic tool on the network device being diagnosed; The session management module is further configured to update the hypothesis set and the diagnostic confidence information based on the tool execution results, obtain the updated diagnostic process state, and persist the updated diagnostic session object so that the network diagnostic task can resume execution based on the persisted diagnostic process state after interruption.

[0066] For more detailed information on the working process of each of the above modules, please refer to the relevant content disclosed in the foregoing embodiments, which will not be repeated here.

[0067] Furthermore, embodiments of this application also provide an electronic device. Figure 4 This is a structural diagram of an electronic device 20 according to an exemplary embodiment. The content of the diagram should not be construed as limiting the scope of this application.

[0068] Figure 4 This is a schematic diagram of the structure of an electronic device 20 provided in an embodiment of this application. Specifically, the electronic device 20 may include: at least one processor 21, at least one memory 22, a display screen 23, an input / output interface 24, a communication interface 25, a power supply 26, and a communication bus 27. The memory 22 stores a computer program, which is loaded and executed by the processor 21 to implement the relevant steps in the network root cause analysis method based on persistent diagnostic sessions disclosed in any of the foregoing embodiments. Alternatively, the electronic device 20 in this embodiment may specifically be a computer.

[0069] In this embodiment, the power supply 26 is used to provide operating voltage for each hardware device on the electronic device 20; the communication interface 25 can create a data transmission channel between the electronic device 20 and external devices, and the communication protocol it follows can be any communication protocol applicable to the technical solution of this application, and is not specifically limited here; the input / output interface 24 is used to acquire external input data or output data to the outside world, and its specific interface type can be selected according to specific application needs, and is not specifically limited here.

[0070] Furthermore, the memory 22, as a carrier for resource storage, can be a read-only memory, random access memory, disk, or optical disk, etc. The resources stored thereon may include computer programs 221, and the storage method may be temporary storage or permanent storage. The computer programs 221 may include, in addition to computer programs capable of performing the network root cause analysis method based on persistent diagnostic sessions executed by the electronic device 20 as disclosed in any of the foregoing embodiments, computer programs capable of performing other specific tasks.

[0071] Furthermore, embodiments of this application also disclose a computer-readable storage medium for storing a computer program; wherein, when the computer program is executed by a processor, it implements the aforementioned network root cause analysis method based on persistent diagnostic sessions.

[0072] For the specific steps of this method, please refer to the relevant content disclosed in the foregoing embodiments, which will not be repeated here.

[0073] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section.

[0074] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0075] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0076] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0077] The foregoing has provided a detailed description of a network root cause analysis method, apparatus, device, and storage medium based on persistent diagnostic sessions provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A network root cause analysis method based on persistent diagnostic sessions, characterized in that, include: Create or restore a diagnostic session object corresponding to a network diagnostic request; wherein, the diagnostic session object is used to record the diagnostic process status of the corresponding network diagnostic task; the diagnostic process status includes at least a set of hypotheses characterizing the causes of candidate faults and diagnostic confidence information corresponding to the set of hypotheses; Based on the diagnostic process state of the diagnostic session object, a reasoning context for the current diagnostic round is constructed; Diagnostic decision information is generated based on the reasoning context; When the diagnostic decision information indicates that a diagnostic tool needs to be invoked, the currently allowed tool permission level is determined based on the diagnostic confidence information in the diagnostic process status, and the target diagnostic tool that matches the currently allowed tool permission level is invoked to obtain the tool execution result; wherein, the diagnostic tool is used to perform network operation status reading, active detection, or network configuration modification on the network device being diagnosed, and the tool permission level is divided according to the degree of influence of the diagnostic tool on the network device being diagnosed; The hypothesis set and diagnostic confidence information are updated based on the execution results of the tool to obtain the updated diagnostic process state. The updated diagnostic session object is then persisted so that the network diagnostic task can resume execution based on the persisted diagnostic process state after an interruption.

2. The network root cause analysis method based on persistent diagnostic sessions according to claim 1, characterized in that, Also includes: Scan multiple active diagnostic session objects according to a preset scanning cycle, and extract the set of faulty devices and the diagnostic trigger time from each diagnostic session object; The diagnostic session objects whose diagnostic trigger times fall within a preset time window are divided into candidate aggregation groups, and the corresponding candidate common upstream nodes are determined based on the candidate aggregation groups; Query the change events related to the candidate public upstream node within the preset time window from the preset change management system; Based on the candidate common upstream node, the change event, and each diagnostic session object in the candidate aggregation group, common cause analysis information is generated; The common cause analysis information is written into each of the diagnostic session objects within the candidate aggregation group, so that each of the diagnostic session objects within the candidate aggregation group includes the common cause analysis information in the inference context of subsequent diagnostic rounds.

3. The network root cause analysis method based on persistent diagnostic sessions according to claim 2, characterized in that, The process of determining the candidate common upstream node includes: The sets of faulty devices corresponding to each diagnostic session object within the candidate aggregation group are merged to obtain the set of faulty devices within the group. Based on the device nodes in the set of faulty devices within the group, a reverse topology traversal is performed in the knowledge graph according to a preset number of hops to determine the candidate common upstream node.

4. The network root cause analysis method based on persistent diagnostic sessions according to claim 1, characterized in that, The reasoning context includes at least one of the following: topological subgraph information extracted from the knowledge graph, and historical diagnostic reference information obtained from the historical root cause analysis retrieval library.

5. The network root cause analysis method based on persistent diagnostic sessions according to claim 4, characterized in that, Also includes: When the current session state of the diagnostic session object is either root cause confirmation completed or transition to manual processing, target decision information is extracted from the reasoning trajectory of the diagnostic session object; wherein, the target decision information includes key tool call information for eliminating or confirming hypotheses in the hypothesis set; Extract effective tool combination patterns from the tool call history of the diagnostic session object; wherein, the effective tool combination patterns include tool call sequences related to the root cause analysis process; Based on the target decision information, the effective tool combination mode, and the target feedback information, structured knowledge entries are generated; wherein, the target feedback information includes at least one of the following: diagnostic results for the network diagnostic task, verification information of the diagnostic process or the tool execution results, supplementary information, or correction information; The structured knowledge entries are vectorized. The vectorized structured knowledge entries are written into the historical root cause analysis retrieval database.

6. The network root cause analysis method based on persistent diagnostic sessions according to claim 1, characterized in that, The process of determining the currently allowed tool permission level based on the diagnostic confidence information in the diagnostic process status, and invoking the target diagnostic tool that matches the currently allowed tool permission level to obtain the tool execution result includes: Based on the degree of impact of the diagnostic tool on the network device being diagnosed, the diagnostic tool is divided into multiple tool permission levels; wherein, the multiple tool permission levels include a first permission level for performing network operation status reading, a second permission level for performing active probing, and a third permission level for performing network configuration modification; Determine the confidence value represented by the diagnostic confidence information; When the confidence level is less than the first threshold, the first permission level is determined as the currently allowed tool permission level; When the confidence value is not less than the first threshold and less than the second threshold, the first permission level and the second permission level are determined as the currently allowed tool permission levels; When the confidence level is not lower than the second threshold, the first permission level, the second permission level, and the third permission level are determined as the currently allowed tool permission levels. Specifically, when the target diagnostic tool belongs to the third permission level, the current session state of the diagnostic session object is updated to the pending approval state; after receiving the approval information, the target diagnostic tool is invoked to obtain the tool execution result.

7. The network root cause analysis method based on persistent diagnostic sessions according to claim 6, characterized in that, Before invoking the target diagnostic tool belonging to the third permission level, the process also includes: A diagnostic intent lock with a validity period is set for the target network device on which the target diagnostic tool operates; wherein, the diagnostic intent lock is used to record the operation intent corresponding to the target network device, the diagnostic session object, and the target diagnostic tool; When other diagnostic session objects request to perform an operation on the target network device that conflicts with the operational intent and belongs to the third permission level within the validity period, the operation is rejected.

8. The network root cause analysis method based on persistent diagnostic sessions according to claim 7, characterized in that, Before invoking the target diagnostic tool belonging to the third permission level, the process also includes: Invoke the change simulation tool to simulate the impact of network configuration modifications corresponding to the target diagnostic tool on at least one of the network topology, access control list, or routing table, and obtain change prediction information; The change prediction information will be used as approval material for the target diagnostic tool.

9. The network root cause analysis method based on persistent diagnostic sessions according to claim 1, characterized in that, Also includes: Upon receiving a pause request, resume request, or transfer request for the diagnostic session object, the diagnostic session object is switched in session state or updated with collaboration information. Diagnostic process log information related to the session state switching or collaboration information update is written into the diagnostic session object to support the suspension, resumption or transfer of the network diagnostic task.

10. The network root cause analysis method based on persistent diagnostic sessions according to any one of claims 1 to 9, characterized in that, Also includes: External tools are accessed via open tool protocols, and corresponding tool permission levels are configured for the accessed external tools; wherein, the external tools include external diagnostic tools and / or external intelligent agents; The external tool is invoked to obtain the external execution result; The call records of the external tools, the permission levels of the tools, and the external execution results are written into the diagnostic process state of the diagnostic session object, and the updated diagnostic session object is persisted.

11. A network root cause analysis device based on persistent diagnostic sessions, characterized in that, include: The session management module is used to create or restore diagnostic session objects corresponding to network diagnostic requests; wherein, the diagnostic session object is used to record the diagnostic process status of the corresponding network diagnostic task; the diagnostic process status includes at least a set of hypotheses characterizing the causes of candidate faults and diagnostic confidence information corresponding to the set of hypotheses; The context enhancement module is used to construct an inference context for the current diagnostic round based on the diagnostic process state of the diagnostic session object. The intelligent diagnostic module is used to generate diagnostic decision information based on the reasoning context; The hierarchical execution module is used to determine the currently allowed tool permission level based on the diagnostic confidence information in the diagnostic process status when the diagnostic decision information indicates that a diagnostic tool needs to be invoked, and to invoke the target diagnostic tool that matches the currently allowed tool permission level to obtain the tool execution result; wherein, the diagnostic tool is used to perform network operation status reading, active detection, or network configuration modification on the network device being diagnosed, and the tool permission level is divided according to the degree of influence of the diagnostic tool on the network device being diagnosed; The session management module is further configured to update the hypothesis set and the diagnostic confidence information based on the tool execution results, obtain the updated diagnostic process state, and persist the updated diagnostic session object so that the network diagnostic task can resume execution based on the persisted diagnostic process state after interruption.

12. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the network root cause analysis method based on persistent diagnostic sessions as described in any one of claims 1-10.

13. A computer-readable storage medium, characterized in that, Used to store computer programs; wherein, when the computer programs are executed by a processor, they implement the network root cause analysis method based on persistent diagnostic sessions as described in any one of claims 1-10.

Images