Network link health degree intelligent diagnosis method and system
By constructing a graph structure using a large language model, the system automatically collects and analyzes performance data of network link devices, solving the problems of difficulty in root cause localization and low efficiency in traditional network monitoring systems. This enables intelligent diagnosis of network link health, improving operational efficiency and accuracy.
Patent Information
- Application Number
- CN202511744427.7
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-11-25
- Publication Date
- 2026-02-24
AI Technical Summary
Traditional network monitoring systems are prone to generating alarm storms when faced with network failures, making it difficult to pinpoint the root cause and lacking effective correlation analysis. This leads to low operational efficiency and misjudgments, and they are unable to adapt to dynamically changing network traffic patterns.
It employs a large language model to construct a graph structure, automatically collects key performance data of network link devices, and performs a comprehensive assessment and diagnosis of network link health through information integration and logical reasoning, outputting an intuitive conclusive report.
It reduces reliance on manual analysis, improves the efficiency and accuracy of network operations and maintenance, can discover hidden and deep-seated fault chains, outputs easily understandable health conclusions, and adapts to changes in the network environment.
Smart Images

Figure CN121567589A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of network monitoring system technology, and in particular to a method and system for intelligent diagnosis of network link health. Background Technology
[0002] The statements in this section are merely background information related to the present invention and do not necessarily constitute prior art.
[0003] As enterprise networks continue to expand and their topologies become increasingly complex, especially for large groups with numerous subsidiaries, their network links contain a large number of switches, routers, firewalls, servers, and terminal devices. Ensuring the smooth and healthy operation of the entire network link is crucial for stable business operations.
[0004] Traditional network monitoring systems can collect massive amounts of network device metrics data (such as CPU / memory utilization, port traffic, packet error rate, latency, firewall session count, etc.) via SNMP, ICMP, API, etc. Monitoring data is usually centrally displayed on a dashboard, supplemented by an alarm mechanism based on static thresholds. When a certain metric exceeds a preset threshold, an alarm is triggered.
[0005] However, when a network failure occurs, a single root cause (such as a core switch failure) can trigger dozens of related alarms from the network to the application layer, creating an alarm storm that forces operations and maintenance personnel to spend a significant amount of time manually screening and judging. Furthermore, a single link failure could be caused by problems with the physical line, switch port, routing policy, firewall rules, or the server itself. Locating the root cause requires knowledge across multiple technical fields and complex reasoning processes, heavily relying on human experts, making root cause identification difficult. Moreover, monitoring data is scattered across different systems and interfaces, lacking effective correlation analysis. Operations and maintenance personnel need to manually cross-reference network topology, device status, and application data, which is inefficient and prone to misjudgment. Traditional systems mostly trigger alarms based on static thresholds, which cannot adapt to dynamically changing network traffic patterns and business loads, potentially leading to false positives or false negatives. Summary of the Invention
[0006] To address the aforementioned issues, this invention proposes an intelligent diagnostic method and system for network link health. This system automatically collects key performance data from various devices within the network link, utilizes the information integration, contextual understanding, and logical reasoning capabilities of a large language model to comprehensively assess and diagnose the overall health status of the network link, and outputs an intuitive conclusive report. This reduces reliance on manual analysis and improves the efficiency and accuracy of network operation and maintenance.
[0007] To achieve the above objectives, the present invention adopts the following technical solution: In a first aspect, the present invention provides a method for intelligent diagnosis of network link health, comprising: The performance data of each device in the target network link is obtained and associated with network topology data, device asset data and historical baseline data to form a diagnostic context information set. A graph structure is constructed with devices as nodes and links as edges, and a large model is obtained after training using the pre-training paradigm of masked autoencoders. Using the diagnostic context information set as cue words for the large model, the range of anomalies is determined by calculating the state anomaly score of the current graph structure, and root cause inference is performed based on this to obtain the health assessment result.
[0008] As an alternative implementation, the device performance data includes: port status, inbound / outbound traffic, packet error / loss rate, CPU / memory utilization, and routing table status of network devices; session connection count, policy hit count, CPU load, and threat logs of security devices; system load, network connection status, critical service process status, and application logs of servers; network reachability and response latency of terminals; and end-to-end latency and path reachability of links.
[0009] As an alternative implementation, the process of associating network topology data, device asset data, and historical baseline data includes: Based on the device's address, obtain its location in the network topology; identify the specific port of the access switch to which the server is connected, and determine the specific port of the access switch uplink to the core switch, thereby reconstructing the end-to-end physical path; Extract the business attributes of the equipment and inject the equipment asset information; Obtain the average level of the same device and the same indicator over a set period of time, and then link it to historical baseline data.
[0010] As an alternative implementation, the process of constructing a diagnostic context information set includes: layering and encapsulating the associated data; wherein, the top-level metadata includes the diagnostic task ID, timestamp, and target link name; the background knowledge layer is embedded in the network topology data and device asset data; the real-time data layer is real-time device performance data; and the historical baseline layer is placed side by side with the historical baseline data corresponding to the real-time device performance data.
[0011] As an alternative implementation, the training process includes: randomly masking the features of some nodes or edges on normal historical data, so that the large model can reconstruct the masked features based on the context.
[0012] As an alternative implementation method, the root cause inference process includes: identifying the node or edge that contributes the most to the abnormal decision by calculating the attention weight in the large model or performing saliency analysis on the input features, which is the root cause; calculating the reconstruction error between the current state and the normal mode, quantifying it into a real-time health score, with different score intervals corresponding to different health dictionaries.
[0013] Secondly, the present invention provides a network link health intelligent diagnosis system, comprising: The data acquisition module is configured to acquire the performance data of each device in the target network link and associate it with network topology data, device asset data and historical baseline data to form a diagnostic context information set. The model building module is configured to construct a graph structure with devices as nodes and links as edges, and then trains the large model using the pre-training paradigm of masked autoencoders. The model processing module is configured to use the diagnostic context information set as prompts for the large model, determine the range of anomalies by calculating the state anomaly score of the current graph structure, and use this to perform root cause inference to obtain the health assessment result.
[0014] Thirdly, the present invention provides an electronic device including a memory and a processor, and computer instructions stored in the memory and running on the processor, wherein the computer instructions, when executed by the processor, perform the method described in the first aspect.
[0015] Fourthly, the present invention provides a computer-readable storage medium for storing computer instructions, which, when executed by a processor, perform the method described in the first aspect.
[0016] Fifthly, the present invention provides a computer program product, including a computer program that, when executed by a processor, implements the method described in the first aspect.
[0017] Compared with the prior art, the beneficial effects of the present invention are as follows: This invention proposes an intelligent diagnostic method and system for network link health. It automatically collects key performance data of various devices in the network link, and utilizes the information integration, contextual understanding, and logical reasoning capabilities of a large language model to comprehensively assess and diagnose the overall health status of the network link, and outputs an intuitive conclusive report, reducing reliance on manual analysis and improving the efficiency and accuracy of network operation and maintenance.
[0018] This invention's method collects data through standardized interfaces, exhibiting excellent universality and scalability. It leverages the powerful reasoning capabilities of large models to replace tedious manual data cross-analysis and root cause localization processes, avoiding alarm noise issues. Furthermore, it breaks down information silos in traditional monitoring tools, organically linking network, security, and computing-level indicators to uncover hidden and deep-seated fault chains. It outputs easily understandable health conclusions and natural language reports, rather than massive amounts of raw data, reducing the cognitive load on operations personnel. Finally, by introducing a human feedback loop, it can continuously learn and optimize diagnostic accuracy, adapting to constantly changing network environments.
[0019] Advantages of additional aspects of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. Attached Figure Description
[0020] 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.
[0021] Figure 1 This is a flowchart of the intelligent network link health diagnosis method provided in Embodiment 1 of the present invention. Detailed Implementation
[0022] The present invention will be further described below with reference to the accompanying drawings and embodiments.
[0023] It should be noted that the following detailed descriptions are exemplary and intended to provide further illustration of the invention. Unless otherwise specified, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains.
[0024] It should be noted that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the scope of exemplary embodiments according to the invention. As used herein, unless the context clearly indicates otherwise, the singular form is intended to include the plural form as well. Furthermore, it should be understood that the terms “comprising” and “including”, and any variations thereof, are intended to cover non-exclusive inclusion, for example, a process, method, system, product, or apparatus that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.
[0025] Where there is no conflict, the embodiments and features in the embodiments of the present invention can be combined with each other.
[0026] Example 1 This embodiment provides a method for intelligent diagnosis of network link health, including: The performance data of each device in the target network link is obtained and associated with network topology data, device asset data and historical baseline data to form a diagnostic context information set. A graph structure is constructed with devices as nodes and links as edges, and a large model is obtained after training using the pre-training paradigm of masked autoencoders. Using the diagnostic context information set as cue words for the large model, the range of anomalies is determined by calculating the state anomaly score of the current graph structure, and root cause inference is performed based on this to obtain the health assessment result.
[0027] The following is combined with Figure 1 The method of this embodiment will be described in detail.
[0028] S1: Data acquisition and interface calls.
[0029] Key performance data is collected periodically or triggered from devices in the target network link through various preset interfaces (such as SNMP, SSH, RESTful API, NetConf, etc.).
[0030] The equipment includes network devices (such as switches and routers), security devices (such as firewalls), servers, and terminals.
[0031] The equipment performance data includes, but is not limited to: Network devices (switches, routers): port status (Up / Down), inbound / outbound traffic, packet error / packet loss rate, CPU / memory utilization, and routing table status.
[0032] Security devices (firewalls): Session connection count, policy hit count, CPU load, and threat logs.
[0033] Server: System load (CPU, memory, disk I / O), network connectivity status, critical service process status, and application logs (such as error logs).
[0034] Terminal: Network reachability and response latency.
[0035] The link itself: end-to-end latency (Ping / Traceroute) and path reachability.
[0036] S2: Data preprocessing and context building.
[0037] The multi-source, heterogeneous raw data collected in step S1 is cleaned, standardized, and formatted, and converted into structured text or JSON data. Simultaneously, network topology data, device asset data (such as device roles and business importance), and historical baseline data are injected to jointly construct a diagnostic context information set containing current status and background knowledge.
[0038] Specifically, it includes: 1. Multi-source data collection and preliminary standardization.
[0039] Unit standardization: CPU utilization is converted from a decimal (0.85) to a percentage (85%), and network traffic is converted from bytes (1550000000) to a more readable unit (1.55 Gbps).
[0040] Status code conversion: Convert the port status code (such as 1) obtained from SNMP query into a semantically clear string ("up"), and convert the server service status to "active" / "inactive".
[0041] Outlier handling: Filter out extremely short-lived outlier data points caused by network interruptions, and fill or mark null values.
[0042] 2. Data association and static knowledge injection.
[0043] (1) Topological association: By querying the Network Management Platform (NMS) or Configuration Management Database (CMDB), the device's location in the global network topology can be obtained based on its IP address or hostname.
[0044] Key action: Identify the specific port (GigabitEthernet1 / 0 / 24) of the access switch (SW-ACCESS-01) to which the server DB-SRV-01 is connected, and further determine the specific port (Ethernet1 / 20) of the access switch uplink to the core switch (SW-CORE-NEXUS-01), thereby accurately reconstructing the end-to-end physical path.
[0045] (2) Asset information injection: Extract the business attributes of the device from the CMDB system.
[0046] For example, the server DB-SRV-01 was labeled with "role": "core database" and "business_criticality": "extremely high", providing a basis for subsequent priority determination.
[0047] (3) Historical baseline correlation: By querying a time-series database (such as Prometheus), the average level of the same device and the same indicator over a set period of time (such as the same time in the past 30 days) can be obtained, and historical baseline data can be generated.
[0048] For example, the historical average CPU utilization of server DB-SRV-01 is 55%.
[0049] 3. Structured assembly and semantic encapsulation: Encapsulate the associated data into machine-readable structured documents.
[0050] Specifically: (1) Selecting a data model: The hierarchical JSON Schema is adopted as the standard data model. The key-value pair structure of JSON is suitable for expressing attributes and values, and its nesting ability can clearly represent the hierarchical relationship between devices, interfaces, and metrics.
[0051] (2) Layered assembly: Top-level metadata: Includes the task ID, timestamp, target link name, etc. for this diagnosis.
[0052] Background knowledge layer: embedded in the acquired topology map and asset information.
[0053] Real-time data layer: Organizes cleaned real-time performance data by device or by path sequence. Each data point includes its source and timestamp.
[0054] Historical baseline layer: Historical baseline data corresponding to real-time data are placed side by side for easy comparison.
[0055] (3) Semantic tags: Store data and assign semantic meaning to the data through the name of the key.
[0056] For example, "oper_status" is more professional than just "status", and "historical_baseline" explicitly indicates the nature of the data.
[0057] 4. Quality verification and output: Before delivering to the large model, perform a final verification of the constructed context information set.
[0058] Specifically: (1) Integrity check: Check whether the data of the key equipment has been successfully collected and whether there are large segments of missing data; if the core equipment data is missing, trigger an alarm or re-collect data.
[0059] (2) Consistency check: Verify whether the topology information is consistent with the collected device IP address to prevent context confusion due to configuration errors.
[0060] (3) Output as final file: The validated, structured JSON object is persisted and used as the main part of the prompt to be input into the large model.
[0061] S3: Large-scale model inference analysis and health status diagnosis.
[0062] The diagnostic context information set is fed as prompts into a trained Large Language Model (LLM). The LLM uses a Graph Neural Network (GNN) as its core architecture and incorporates a pre-trained masked autoencoder paradigm.
[0063] The network topology is abstracted as a graph structure, with network devices (such as routers and switches) as nodes and links as edges. Node features include CPU load and memory utilization, while edge features include traffic, latency, and packet loss rate. Through information transmission and aggregation between neighboring nodes, the system efficiently learns the global state representation of the entire network and captures the complex dependencies between devices and links.
[0064] On a large amount of normal historical data, the characteristics of some nodes or edges are randomly masked (e.g., the traffic of a certain link is set to 0), allowing the model to reconstruct the masked characteristics based on its context (topology and the state of surrounding devices). This enables the model to learn the inherent, robust operating rules of the network, rather than simply memorizing them.
[0065] Finally, the diagnostic context information set is used as cue words for the large model. The abnormal range is determined by calculating the state abnormality score of the current graph structure, and root cause inference is performed based on this to obtain the health assessment result.
[0066] Specifically: Data correlation analysis: Through the message passing mechanism of GNN, the fault propagation path is learned. When an anomaly occurs, the model calculates the anomaly score of the current graph state based on the learned "normal pattern". Subgraphs with high anomaly scores exceeding the threshold are identified as the affected areas, thus realizing correlation analysis.
[0067] Root cause inference: By calculating the attention weights in the model or performing saliency analysis on the input features (such as Grad-CAM), the node or edge that contributes the most to the final anomalous decision is identified as the root cause.
[0068] Comprehensive Health Assessment: The pre-trained model learns a baseline state of "normal". In online applications, the model calculates the reconstruction error or prediction error between the current state and the learned normal pattern, quantifying it as a real-time health score between 0 and 100. Different score ranges correspond to different health dictionaries. For example, below 30 points indicates a malfunction, 30-60 points indicates moderate abnormality, 60-80 points indicates sub-health, and 80-100 points indicates excellent health, thus achieving continuous health assessment.
[0069] Detailed output and explanation: Generates a structured natural language report that clearly indicates the device problem, the possible causes of the problem, and repair suggestions.
[0070] For example: Diagnostic conclusion: Link health [Sub-healthy]. A small number of persistent packet errors exist on the GigabitEthernet0 / 1 port of the core switch, possibly caused by a faulty network cable or optical module. Although service is not interrupted, there is a risk. Hardware replacement is recommended as a priority.
[0071] S4: Results Presentation and Feedback.
[0072] The diagnostic conclusions and reports generated by the large model are presented to the operations and maintenance personnel through graphical user interface (GUI), push notifications (such as email, DingTalk, Slack), or API callbacks. At the same time, a human feedback interface is provided, allowing the operations and maintenance personnel to evaluate and correct the accuracy of the diagnostic results. This feedback data is used to optimize the prompts of the large model or to fine-tune the model, so as to achieve closed-loop learning and continuous improvement.
[0073] The above method will be described in detail below through an example.
[0074] Implementation environment: A large enterprise group is monitoring the core business links of a subsidiary's data center.
[0075] Data Acquisition: Port status and CPU load of the core switch (Cisco Nexus) are collected via SNMP; policy logs and session counts are obtained from the firewall (Palo Alto) via API; CPU and memory usage and application service status are obtained by connecting to the Linux server via SSH; and end-to-end continuity testing is performed via ICMP.
[0076] Context building: Integrate the above data into a JSON object and attach the topology information of the link (e.g., server-access switch-core switch-firewall-router) and key device labels (e.g., the server is the "core database").
[0077] Large model analysis: The constructed JSON context is input into a large model (such as GPT-4, ChatGLM, or a locally tuned model) via a designed Prompt (e.g., "You are a senior network expert. Please analyze the health status of the 'core database access link' based on the following network monitoring data...").
[0078] Results Generation and Presentation: After large-scale model analysis, the following report was returned: "Diagnosis Conclusion: Health Status [Fault]. Root Cause Location: Interrupted connection between the core database server network port and the access switch (physical layer fault). Evidence: The server's network card status is DOWN, and the corresponding port status on the access switch is DOWN. Recommendation: Immediately check the physical network cables and modules between the server and the switch." This report was pushed to the operations and maintenance team's monitoring dashboard and mobile devices.
[0079] Feedback Learning: After on-site verification, the maintenance personnel confirmed that the problem was indeed a loose network cable. After resolving the issue, they marked the diagnosis as "accurate" through the system interface. This positive feedback was recorded by the system for use in optimizing the analysis of similar scenarios in the future.
[0080] An example of a diagnostic context information set is shown below: { / / --- 1. Diagnostic Task Meta--- "task_metadata": { "task_id": "DC-DIAG-20240524-0330", "target_path_name": "Core database access path", "focus_device": "DB-SRV-01 (Core Database)", "analysis_timestamp": "2024-05-24T03:30:15Z" }, / / --- 2. Network Topology and Asset Background (Static Knowledge) --- "contextual_background": { "path_topology": [ "End user", "->Group Core Router", Subsidiary Firewall (FW-SUB-01) " -> Subsidiary Core Switch (SW-CORE-NEXUS-01)", " ->Access Switch (SW-ACCESS-01)", -> Core Database Server (DB-SRV-01) ], "device_criticality": { "DB-SRV-01": "Extremely High", "SW-CORE-NEXUS-01": "High", "FW-SUB-01": "High", "SW-ACCESS-01": "Medium" } }, / / --- 3. Real-time collected performance data (dynamic data) --- "collected_metrics": { / / 3.1 End-to-End Connectivity (ICMP) "end_to_end_connectivity": { "source": "monitoring node", "destination": "DB-SRV-01 (10.10.50.100)", "packet_loss_percent": 100, "avg_rtt_ms": "Timeout", "status": "Failed" }, / / 3.2 Core Switch Data (SNMP) "core_switch_sw_nexus_01": { "management_ip": "10.10.10.1", "cpu_utilization": "12%", "memory_utilization": "45%", "interfaces": { "Ethernet1 / 10": { / / Port for connecting to the firewall "admin_status": "up", "oper_status": "up", "input_errors": 0, "output_errors": 0 }, "Ethernet1 / 20": { / / Connect to the port on the access switch - key point! "admin_status": "up", "oper_status": "down", / / The port operation status is DOWN! "input_errors": 0, "output_errors": 0 } } }, / / 3.3 Firewall Data (API) "firewall_fw_sub_01": { "management_ip": "10.10.20.1", "cpu_utilization": "30%", "memory_utilization": "50%", "session_count": 15000, "policy_hits": { "DB-Access-Policy": 0 / / Policy hit count is 0, no traffic matching. } }, / / 3.4 Server Data (SSH) "server_db_srv_01": { "management_ip": "10.10.50.100", "system_health": { "cpu_utilization": "5%", / / CPU idle "memory_utilization": "40%", "load_average": "0.1" }, "network_health": { "interface_eth0": { "operstate": "down", / / The server's network card status is DOWN! "ip_address": "10.10.50.100 / 24" } }, "application_health": { "oracle_db_service": "inactive (dead)" / / The database service is not running due to network unavailability. } } }, / / --- 4. Historical baseline data (for comparison) --- "historical_baseline": { "end_to_end_connectivity": { "avg_rtt_ms": 25, "avg_packet_loss_percent": 0 }, "server_db_srv_01": { "cpu_utilization": "55%", "memory_utilization": "70%" }, "core_switch_port_eth1_20": { "avg_oper_status": "up" } } } The reason why structured JSON objects can accurately pinpoint the "loose network cable" in a large model is because they contain the following key information points and reveal their inherent connections: 1. Topological Context: "path_topology" explicitly indicates the traffic path: -> core switch -> access switch -> server, guiding the large model to investigate segment by segment along the path, rather than looking at each device in isolation.
[0081] 2. State Consistency: The network interface card (NIC) of server DB-SRV-01 is in the state "operstate": "down". The Ethernet1 / 20 port of core switch SW-CORE-NEXUS-01, which connects to this server, is in the state "oper_status": "down". The simultaneous downtime of these two port states on upstream and downstream devices along the path is strong evidence of a physical layer failure.
[0082] 3. The causal chain between phenomena and root causes: Cause: Physical link interruption (port DOWN).
[0083] Result 1: End-to-end Ping test "status": "failed".
[0084] Result 2: Firewall policy "DB-Access-Policy": 0, because no traffic arrived.
[0085] Result 3: The server CPU usage is very low ("5%), and the database service is "inactive" because it cannot be accessed over the network and may be in a dormant state. The larger model traces these results back to the same cause.
[0086] 4. Exculpatory Evidence: The Ethernet1 / 10 ports connecting the core switch to the firewall are in an up state, and the CPU and memory are normal, ruling out a core switch failure. The firewall itself has normal CPU and session count, ruling out the possibility that the firewall is a bottleneck. This helps the large model narrow down the fault scope to the link between the core switch, access switches, and the server.
[0087] 5. Historical Baseline Comparison: "historical_baseline" shows that the switch port is usually "up" but is now "down", confirming that this is an abnormal state change.
[0088] Conclusion: The diagnostic contextual information set is not merely a data report, but a complete knowledge package containing facts, relationships, states, and history. This enables large models to perform logically clear chain-like reasoning, much like human experts, without guessing or making assumptions, ultimately leading to accurate and interpretable conclusions.
[0089] Example 2 This embodiment provides a network link health intelligent diagnosis system, including: The data acquisition module is configured to acquire the performance data of each device in the target network link and associate it with network topology data, device asset data and historical baseline data to form a diagnostic context information set. The model building module is configured to construct a graph structure with devices as nodes and links as edges, and then trains the large model using the pre-training paradigm of masked autoencoders. The model processing module is configured to use the diagnostic context information set as prompts for the large model, determine the range of anomalies by calculating the state anomaly score of the current graph structure, and use this to perform root cause inference to obtain the health assessment result.
[0090] It should be noted that the above modules correspond to the steps described in Embodiment 1, and the examples and application scenarios implemented by the above modules and the corresponding steps are the same, but are not limited to the content disclosed in Embodiment 1. It should also be noted that the above modules, as part of the system, can be executed in a computer system such as a set of computer-executable instructions.
[0091] In further embodiments, the following is also provided: An electronic device includes a memory and a processor, as well as computer instructions stored in the memory and running on the processor, wherein the computer instructions, when executed by the processor, perform the method described in Embodiment 1. For brevity, further details are omitted here.
[0092] It should be understood that in this embodiment, the processor can be a central processing unit (CPU), or it can be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor, etc.
[0093] Memory may include read-only memory and random access memory, and provides instructions and data to the processor. A portion of memory may also include non-volatile random access memory. For example, memory may also store information about the device type.
[0094] A computer-readable storage medium for storing computer instructions, which, when executed by a processor, perform the method described in Embodiment 1.
[0095] The method in Example 1 can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor. The software modules can reside in readily available storage media in the field, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. This storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method. To avoid repetition, a detailed description is not provided here.
[0096] A computer program product includes a computer program that, when executed by a processor, implements the method described in Embodiment 1.
[0097] The present invention also provides at least one computer program product tangibly stored on a non-transitory computer-readable storage medium. The computer program product includes computer-executable instructions, such as instructions included in program modules, which execute in a device on a target real or virtual processor to perform the processes / methods described above. Typically, program modules include routines, programs, libraries, objects, classes, components, data structures, etc., that perform specific tasks or implement specific abstract data types. In various embodiments, the functionality of program modules can be combined or divided among program modules as needed. The machine-executable instructions for the program modules can execute within a local or distributed device. In a distributed device, the program modules can reside in both local and remote storage media.
[0098] The computer program code used to implement the methods of the present invention may be written in one or more programming languages. This computer program code may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the computer or other programmable data processing device, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a computer, partially on a computer, as a stand-alone software package, partially on a computer and partially on a remote computer, or entirely on a remote computer or server.
[0099] In the context of this invention, computer program code or related data may be carried by any suitable carrier to enable a device, apparatus, or processor to perform the various processes and operations described above. Examples of carriers include signals, computer-readable media, and the like. Examples of signals may include electrical, optical, radio, sound, or other forms of propagation signals, such as carrier waves, infrared signals, etc.
[0100] Those skilled in the art will recognize that the units and algorithm steps described in connection with the various examples of this embodiment can be implemented in electronic hardware or a combination of computer software and electronic hardware. 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 invention.
[0101] While the specific embodiments of the present invention have been described above in conjunction with the accompanying drawings, this is not intended to limit the scope of protection of the present invention. Those skilled in the art should understand that various modifications or variations that can be made by those skilled in the art without creative effort based on the technical solutions of the present invention are still within the scope of protection of the present invention.
Claims
1. A method for intelligent diagnosis of network link health, characterized in that, include: The performance data of each device in the target network link is obtained and associated with network topology data, device asset data and historical baseline data to form a diagnostic context information set. A graph structure is constructed with devices as nodes and links as edges, and a large model is obtained after training using the pre-training paradigm of masked autoencoders. Using the diagnostic context information set as cue words for the large model, the range of anomalies is determined by calculating the state anomaly score of the current graph structure, and root cause inference is performed based on this to obtain the health assessment result.
2. The intelligent network link health diagnosis method as described in claim 1, characterized in that, The device's performance data includes: port status, inbound / outbound traffic, packet error / loss rate, CPU / memory utilization, and routing table status of network devices; session connection count, policy hit count, CPU load, and threat logs of security devices; system load, network connection status, critical service process status, and application logs of servers; network reachability and response latency of terminals; and end-to-end latency and path reachability of links.
3. The intelligent network link health diagnosis method as described in claim 1, characterized in that, The process of associating network topology data, device asset data, and historical baseline data includes: Based on the device's address, obtain its location in the network topology; identify the specific port of the access switch to which the server is connected, and determine the specific port of the access switch uplink to the core switch, thereby reconstructing the end-to-end physical path; Extract the business attributes of the equipment and inject the equipment asset information; Obtain the average level of the same device and the same indicator over a set period of time, and then link it to historical baseline data.
4. The intelligent network link health diagnosis method as described in claim 3, characterized in that, The process of constructing the diagnostic context information set includes: layering and encapsulating the associated data; the top-level metadata includes the diagnostic task ID, timestamp, and target link name; the background knowledge layer is embedded in the network topology data and device asset data; the real-time data layer is the real-time device performance data; and the historical baseline layer is placed side by side with the historical baseline data corresponding to the real-time device performance data.
5. The intelligent network link health diagnosis method as described in claim 1, characterized in that, The training process includes: randomly masking the features of some nodes or edges on normal historical data, so that the large model can reconstruct the masked features based on the context.
6. The intelligent network link health diagnosis method as described in claim 1, characterized in that, The root cause inference process includes: identifying the nodes or edges that contribute the most to abnormal decisions by calculating the attention weights in the large model or by performing saliency analysis on the input features, which are the root causes; calculating the reconstruction error between the current state and the normal mode, and quantifying it into a real-time health score, with different score ranges corresponding to different health dictionaries.
7. A network link health intelligent diagnosis system, characterized in that, include: The data acquisition module is configured to acquire the performance data of each device in the target network link and associate it with network topology data, device asset data and historical baseline data to form a diagnostic context information set. The model building module is configured to construct a graph structure with devices as nodes and links as edges, and then trains the large model using the pre-training paradigm of masked autoencoders. The model processing module is configured to use the diagnostic context information set as prompts for the large model, determine the range of anomalies by calculating the state anomaly score of the current graph structure, and use this to perform root cause inference to obtain the health assessment result.
8. An electronic device, characterized in that, It includes a memory and a processor, as well as computer instructions stored in the memory and running on the processor, which, when executed by the processor, perform the method according to any one of claims 1-6.
9. A computer-readable storage medium, characterized in that, Used to store computer instructions, which, when executed by a processor, perform the method described in any one of claims 1-6.
10. A computer program product, characterized in that, Includes a computer program, which, when executed by a processor, implements the method described in any one of claims 1-6.