A network fault perception processing method and device, electronic equipment and storage medium

Abstract

The application discloses a network fault awareness processing method and device, electronic equipment and a storage medium. The method comprises the following steps: acquiring alarm information, converting the alarm information into a script language for network fault awareness processing to obtain fault information, performing fault diagnosis and analysis processing on the fault information based on a heterogeneous interface arrangement mode to obtain a fault cause, generating a corresponding treatment decision according to the fault cause, and performing parameter verification and instruction rollback detection processing on the treatment decision, and executing the instructions that pass the detection. The embodiment of the application can improve the network fault awareness processing efficiency and can be widely applied to the computer technology field.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a network fault perception and processing method, apparatus, electronic device and storage medium. Background Technology

[0002] In the field of network operations and maintenance, network fault diagnosis commonly uses partially autonomous networks, meaning that apart from the system's automatic execution, other capabilities require manual operation and interaction. This results in low automation levels, failing to meet the demands of increasingly intelligent scenarios requiring rapid iteration. Furthermore, the system's use of hard-coded implementation of automatic execution functions hinders rapid response capabilities, impacting operational efficiency. In summary, the technical issues in these technologies need to be addressed. Summary of the Invention

[0003] The main objective of this application is to provide a network fault perception and processing method, device, electronic device, and storage medium, which can improve the efficiency of network fault perception and operation and maintenance.

[0004] To achieve the above objectives, one aspect of this application proposes a network fault perception processing method, the method comprising:

[0005] Obtain alarm information;

[0006] The alarm information is converted into a scripting language for network fault detection processing to obtain fault information;

[0007] The fault information is analyzed and processed based on a heterogeneous interface orchestration method to obtain the cause of the fault.

[0008] Based on the cause of the fault, a corresponding handling decision is generated, and the handling decision is subjected to parameter verification and instruction rollback detection processing. Instructions that pass the detection are then executed.

[0009] In some embodiments, converting the alarm information into a scripting language for network fault detection processing to obtain fault information includes the following steps:

[0010] The alarm information is configured and parsed using scripting language code to obtain a parsing script;

[0011] The parsing script is processed to create a scenario arrangement, resulting in a fault scenario;

[0012] The fault scenario input model generator is subjected to fault type analysis and processing to output the fault information.

[0013] In some embodiments, the process of performing scenario orchestration on the parsing script to obtain a fault scenario includes the following steps:

[0014] The parsing script is subjected to application capability analysis and serial arrangement processing to obtain virtual instructions;

[0015] The virtual instructions are uniformly arranged and processed according to the functional application to obtain the fault scenario.

[0016] In some embodiments, the fault diagnosis and analysis processing of the fault information based on the heterogeneous interface orchestration method to obtain the fault cause includes the following steps:

[0017] Based on the manufacturer's instruction model, the fault information is processed by configuration lookup to obtain configuration information;

[0018] The configuration information is encapsulated to obtain a heterogeneous interface;

[0019] The heterogeneous interface is processed by parameter orchestration to obtain a parameter orchestration interface;

[0020] The parameter orchestration interface is processed by rule orchestration and process orchestration to obtain the cause of the fault.

[0021] In some embodiments, the parameter orchestration process of the heterogeneous interface to obtain a parameter orchestration interface includes the following steps:

[0022] Obtain the network topology of the communication network;

[0023] The communication network structure is divided into topologies to obtain the network topology.

[0024] The parameter orchestration interface is obtained by defining parameters of the heterogeneous interface according to the network topology.

[0025] In some embodiments, the parameter verification and instruction rollback detection processing for the decision-making process includes the following steps:

[0026] The configuration parameters and configuration instructions are determined based on the aforementioned decision-making process;

[0027] The configuration parameters are compared based on the network link to obtain the verification result.

[0028] The configuration command is issued based on the verification result, and anomaly detection is performed on the issued command. When an anomaly is detected, the issued command is rolled back.

[0029] In some embodiments, the step of detecting anomalies in the issued instructions and performing instruction rollback processing when an anomaly is detected includes the following steps:

[0030] The issued command is processed by setting a tag to obtain a rollback tag;

[0031] The issued instructions are processed according to the preset trial operation time, and the issued instructions are detected according to the network operation status and network performance indicators to obtain the detection results;

[0032] When the detection result indicates an abnormal delivery, the delivery command is rolled back according to the rollback tag.

[0033] To achieve the above objectives, another aspect of this application provides a network fault perception and processing device, the device comprising:

[0034] The first module is configured to acquire alarm information;

[0035] The second module is configured to convert the alarm information into a scripting language for network fault detection processing to obtain fault information.

[0036] The third module is configured to perform fault diagnosis and analysis on the fault information based on a heterogeneous interface orchestration method to obtain the cause of the fault.

[0037] The fourth module is configured to generate a corresponding handling decision based on the cause of the fault, and to perform parameter verification and instruction rollback detection processing on the handling decision, and to execute the instructions that pass the detection.

[0038] To achieve the above objectives, another aspect of this application provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the method described above.

[0039] To achieve the above objectives, another aspect of the embodiments of this application proposes a computer-readable storage medium storing a computer program that, when executed by a processor, implements the methods described above.

[0040] The embodiments of this application include at least the following beneficial effects: This application provides a network fault perception and processing method, apparatus, electronic device, and storage medium. This solution obtains alarm information, converts the alarm information into a scripting language for network fault perception processing to obtain fault information. It can autonomously perceive network faults in a scripting language manner, improving the system's flexibility. Furthermore, this solution uses a heterogeneous interface orchestration method to perform fault diagnosis and analysis processing on fault information to obtain the fault cause, enabling configuration and orchestration of the diagnostic process, thus improving the efficiency of network fault diagnosis. In addition, this solution generates corresponding handling decisions based on the fault cause, performs parameter verification and instruction rollback detection processing on the handling decisions, and executes instructions that pass the detection. It can verify and roll back configuration decisions, improving the efficiency of network fault perception and processing. Attached Figure Description

[0041] Figure 1 This is a flowchart of a network fault perception and processing method provided in an embodiment of this application;

[0042] Figure 2 yes Figure 1 The flowchart of step S102 in the document;

[0043] Figure 3 This is a schematic diagram of a network fault autonomous perception model provided in an embodiment of this application;

[0044] Figure 4 yes Figure 1 The flowchart of step S103 in the process;

[0045] Figure 5 This is a schematic diagram of a network fault autonomous diagnosis and analysis model provided in an embodiment of this application;

[0046] Figure 6 This is a schematic diagram of a network structure provided in an embodiment of this application;

[0047] Figure 7 yes Figure 1 The flowchart of step S104 in the process;

[0048] Figure 8 This is a schematic diagram of a fault autonomous handling decision-making process provided in an embodiment of this application;

[0049] Figure 9 This is a schematic diagram of the structure of a network fault perception and processing device provided in an embodiment of this application;

[0050] Figure 10 This is a schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0051] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of this application and are not intended to limit it. In the following description, when referring to the accompanying drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with those of this application; they are merely examples of apparatuses and methods consistent with some aspects of the embodiments of this application as detailed in the appended claims.

[0052] It is understood that the terms “first,” “second,” etc., used in this application may be used herein to describe various concepts, but unless otherwise stated, these concepts are not limited by these terms. These terms are only used to distinguish one concept from another. For example, without departing from the scope of the embodiments of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the words “if,” “when,” or “in response to a determination” as used herein may be interpreted as “when…” or “when…” or “in response to a determination.”

[0053] As used in this application, the terms "at least one", "multiple", "each", "any", etc., "at least one" includes one, two or more, "multiple" includes two or more, "each" refers to each of the corresponding multiples, and "any" refers to any one of the multiples.

[0054] Unless otherwise defined, 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 application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0055] Before providing a detailed description of the embodiments of this application, some of the nouns and terms involved in the embodiments of this application will be explained first. The nouns and terms involved in the embodiments of this application are subject to the following interpretations.

[0056] 1) Internet Protocol (IP): A network protocol used for data packet transmission and address allocation in computer networks. It defines how data is packetized, addressed, and routed in a network.

[0057] 2) Internet Protocol Radio Access Network (IPRAN): A wireless access network architecture based on the Internet protocol, used to realize the transmission and exchange of mobile communication and data services.

[0058] 3) Representational State Transfer Application Programming Interface (RESTful API): A design style and architectural principle for building web services and application interfaces based on the HTTP (Hypertext Transfer Protocol) protocol. Through a RESTful API, clients can use a unified interface to communicate with the server, requesting and transferring representations of resources.

[0059] As artificial intelligence (AI) continues to evolve, the operation and maintenance of communication networks are gradually entering a deeper phase of intelligence. The TM Forum has defined six levels of intelligent networks, from L0 to L5, to guide the automation and intelligence of networks and services, assess the value and advantages of intelligent network services, and build "self-configuration, self-repair, and self-optimization" digitalized operation and maintenance capabilities. Specifically: L0 represents manual operation and maintenance: the system provides auxiliary monitoring capabilities, but all dynamic tasks require manual execution. L1 represents assisted operation and maintenance: the system can execute specific repetitive sub-tasks based on pre-configuration to improve efficiency. L2 represents partially intelligent networks: in specific external environments, the system can enable automated closed-loop operation and maintenance for specific units based on predefined rules / policies. L3 represents conditional intelligent networks: building on L2, the system can perceive environmental changes in real time and perform self-optimization and self-adjustment in specific network specialties to adapt to the external environment. L4 represents highly intelligent networks: building on L3, the system can achieve predictive or proactive closed-loop management of business and customer experience-driven networks in more complex cross-network environments, thereby performing analysis and making decisions. L5 stands for Fully Autonomous Network: This level is the ultimate goal of telecommunications network evolution, and the system has closed-loop autonomous capabilities for multiple services, multiple domains, and the entire lifecycle.

[0060] In the current network operations and maintenance field, the prevailing level is L2 (partially autonomous network), meaning that apart from "execution" which is automated by the system, all other capabilities require manual operation and interaction. This level has significant drawbacks, primarily including: low automation, making it unable to meet the growing demand for rapidly iterating intelligent scenarios; the use of hard-coded implementation of automated functions necessitates code modifications and system upgrades to accommodate changes in network scenarios, equipment manufacturers and models, configuration scripts, and service types, hindering rapid response capabilities; and high coupling between the front-end and back-end, preventing heterogeneous decoupling and thus hindering the development of "autonomous perception," "autonomous analysis," and "autonomous decision-making" capabilities.

[0061] In view of this, this application provides a network fault perception and processing method, apparatus, electronic device, and storage medium. This solution acquires alarm information, converts it into a scripting language, and performs network fault perception processing to obtain fault information. It enables autonomous network fault perception using a scripting language, improving system flexibility. Furthermore, this solution uses a heterogeneous interface orchestration approach to perform fault diagnosis and analysis to obtain the fault cause, allowing for configuration and orchestration of the diagnostic process, thus improving the efficiency of network fault diagnosis. Additionally, this solution generates corresponding handling decisions based on the fault cause, performs parameter verification and instruction rollback detection processing on the handling decisions, and executes instructions that pass the detection. This allows for verification and rollback recovery processing of configuration decisions, further improving the efficiency of network fault perception and processing.

[0062] This application provides a network fault perception and processing method, relating to the field of computer technology. This method can be applied to a terminal, a server, or software running on either a terminal or a server. In some embodiments, the terminal can be a smartphone, tablet, laptop, desktop computer, smart speaker, smartwatch, or in-vehicle terminal, but is not limited thereto. The server can be configured as an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. The server can also be a node server in a blockchain network. The software can be an application implementing a network fault perception and processing method, but is not limited to the above forms.

[0063] This application can be used in a wide variety of general-purpose or special-purpose computer system environments or configurations. Examples include: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, and distributed computing environments including any of the above systems or devices. This application can be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform specific tasks or implement specific abstract data types. This application can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0064] Figure 1 This is an optional flowchart of a network fault perception and processing method provided in an embodiment of this application. Figure 1 The method may include, but is not limited to, steps S101 to S104.

[0065] Step S101: Obtain alarm information;

[0066] Step S102: Convert the alarm information into a scripting language for network fault detection processing to obtain fault information;

[0067] Step S103: Perform fault diagnosis and analysis on the fault information based on the heterogeneous interface orchestration method to obtain the fault cause;

[0068] Step S104: Generate a corresponding handling decision based on the cause of the fault, and perform parameter verification and instruction rollback detection processing on the handling decision, and execute the instructions that pass the detection.

[0069] Steps S101 to S104, as illustrated in this embodiment, involve acquiring alarm information and converting it into a scripting language to input into a network fault autonomous perception model for network fault perception, thereby obtaining fault information. The alarm information is uploaded by the device and can be sent using different device manufacturer instruction sets. The message content depends on the alarm reporting method, device manufacturer, model, version, alarm message type, etc. The alarm information is then converted into a scripting language. By parsing and configuring the message content using regular expressions, Python, or other scripting languages, corresponding alarm and potential problem scenarios can be designed and orchestrated using scripting languages. This allows for flexible, modular customization of generators for different types of alarms and potential problems, enabling configurable code, rules, processes, and tasks. Corresponding fault information is generated through configuration. Then, fault information is analyzed and processed through a heterogeneous interface orchestration approach. The core of this self-diagnostic fault analysis process is a RESTful API with heterogeneous interaction capabilities. Parameters, rules, conclusions, and commands within the process can all be configured and orchestrated. This reshapes the traditional black-box, segmented, and manual operation and maintenance model, transforming it into a proactive, pre-emptive, and development-oriented model. Fault diagnosis and analysis are then performed according to the corresponding orchestration process to identify the cause of the fault. Finally, corresponding handling decisions are generated based on the fault cause, and parameter verification and command rollback checks are performed on these decisions. Commands that pass the checks are executed, ensuring the security and reliability of the autonomous network fault handling decision-making process. This solution, through real-time parameter verification and automatic command rollback capabilities, automatically verifies the accuracy of parameters before configuration and deployment, and automatically sets rollback points to enable recovery in case of any anomalies during handling.

[0070] In step S101 of some embodiments, alarm information can be obtained through data interaction commands such as SNMP Trap, Syslog, and Telemetry from various device manufacturers, but this is not limited to these. SNMP Trap is an important component of the Simple Network Management Protocol (SNMP), which allows managed devices to proactively send messages to the Network Management System (NMS) when specific events occur. This mechanism eliminates the need for network administrators to constantly poll devices, thus saving computing resources. Syslog is a standard for transmitting log messages over the Internet Protocol (TCP / IP). It allows devices, such as servers, routers, and firewalls, to send event messages to a designated log collection server for centralized management and analysis. Telemetry is a technology for remotely collecting data at high speed from physical or virtual devices. Devices periodically and proactively send information such as interface traffic statistics, CPU or memory data to the collector via push mode.

[0071] Please see Figure 2 In step S102 of some embodiments, the step of converting the alarm information into a scripting language for network fault detection processing to obtain fault information includes the following steps:

[0072] Step S201: Configure and parse the alarm information using scripting language code to obtain a parsing script;

[0073] Step S202: Perform scenario arrangement processing on the parsing script to obtain the fault scenario;

[0074] Step S203: Perform fault type analysis processing on the fault scenario input model generator and output the fault information.

[0075] In step S201 of some embodiments, a scripting language for parsing is developed for different alarm messages. Python scripting can be used for parsing configuration, or regular expressions can be used to parse and configure Syslog log messages to obtain the parsing script. It is conceivable that by configuring and parsing the alarm information using scripting language code, the parsing script can be directly configured into the system, thereby achieving "white-box" and "customized" functionality. This solves the tight coupling problem of traditional software systems, achieving complete decoupling and making it easier for the system to respond quickly to changes in network type, network structure, business scenarios, and parameter variations, thus improving the efficiency of network fault perception and processing.

[0076] In step S202 of some embodiments, the system can provide multi-level orchestration capabilities to process actual instructions generated by scripting language to obtain fault scenarios. These fault scenarios can be orchestrated for multiple devices and multiple instruction sets to obtain a process. The orchestration process can be a parallel process or a serial process, and can be applied to network devices from different manufacturers, different versions, and different versions.

[0077] In step S203 of some embodiments, the fault scenario input model generator performs fault type analysis and outputs fault information. The model generator is an automated model configured by the system according to a scripted language and scenario settings. It can include two main categories: alarms and potential problems. Alarms refer to network faults that have become apparent, such as power outages, fiber optic cable interruptions, and protocol interruptions, which generate corresponding alarms in real time. Potential problems refer to network faults that have not yet become apparent, such as fiber optic cable quality degradation, which, although still usable, will lead to increasingly poor network quality. Another example is network link traffic congestion, which, although services on the link can still be used, has already affected user download speeds and application interaction latency. Potential problems are more numerous, and the judgment rules are more flexible and complex. Therefore, the system divides the model generator into alarm model generators and potential problem model generators, but the real-time requirements for the two differ. It is conceivable that embodiments of this application configure different model generators according to the task. Different models can be used for different network types, introduce different orchestration scenarios, and set different execution cycles. Alarms can be set in more real-time intervals, such as real-time, 5 minutes, 10 minutes, or 20 minutes. Potential hazard warnings can generally have longer intervals, such as 1 hour or 1 day. Through the configuration of alarm and hazard model generators, the system can autonomously and flexibly detect network-side faults, and output corresponding fault information by analyzing fault scenarios.

[0078] Please see Figure 3 In this embodiment of the application, a network fault autonomous perception model can be pre-trained by inputting instruction sets from various device manufacturers into the model for training. The model is then used to evaluate the instruction sets (F1-F2). n The scripting language is processed to obtain a parsed script, and the parsed script is combined with the instruction parameters to design and arrange the scene (S1-S). m Then, input the alarm model generator M1 or the hidden danger model generator M2 for classification and output to obtain different alarm class models and hidden danger class models. After training, the real-time acquired alarm information can be input into the network fault autonomous perception model to perceive network faults and obtain fault information.

[0079] One of the above technical solutions has the following advantages or beneficial effects: The embodiments of this application realize the autonomous perception capability of network faults based on scripting language. It can be adapted to the data interaction commands such as SNMP Trap, Syslog, and Telemetry of major network equipment manufacturers. The corresponding alarm and hidden danger scenarios are designed and arranged in the form of scripting language. Different types of alarm and hidden danger generators are flexibly customized in a modular way, realizing the configurability of code, rules, processes, and tasks, and finally achieving the "perception" capability of L3 level intelligent network.

[0080] In step S202 of some embodiments, the process of performing scene orchestration on the parsing script to obtain a fault scene includes the following steps:

[0081] The parsing script is subjected to application capability analysis and serial arrangement processing to obtain virtual instructions;

[0082] The virtual instructions are uniformly arranged and processed according to the functional application to obtain the fault scenario.

[0083] In this embodiment, by performing application function analysis on the parsing script, the ability of the parsing script to implement a certain type of micro-application can be orchestrated into virtual instructions. That is, a virtual instruction defines a capability for implementing a certain type of micro-application. Real instructions consist of specific device-side instructions and a scripting language. One or more real instructions can be orchestrated into virtual instructions serially. Then, the virtual instructions are orchestrated into a virtual instruction set. A virtual instruction set is a collection of orchestrated virtual instructions, often used to unify virtual instructions from different manufacturers, models, and versions into a single virtual instruction set, facilitating autonomous invocation by upper-layer applications. In other words, a virtual instruction set is equivalent to an atomic capability that can mask differences in manufacturer, model, and version. Finally, the virtual instruction set is orchestrated into a scenario. When a functional application needs to perform complex orchestration of multiple virtual instruction sets to form a unified capability, scenario-based process orchestration can be performed. A scenario can orchestrate multiple devices and multiple virtual instruction sets. The orchestration process can be parallel or serial. Therefore, a scenario is equivalent to a molecular capability that autonomously encloses atomic capabilities, enabling the unified implementation of a certain functional application. In one feasible embodiment, the system uniformly orchestrates an "IPRAN trunk poor quality alarm" scenario to achieve autonomous detection capability for trunk poor quality alarms. This scenario consists of multiple virtual instruction sets, virtual instructions, and real instructions, and can be applied to network devices from different manufacturers, versions, and models.

[0084] One of the above technical solutions has the following advantages or beneficial effects: By analyzing the application capabilities of the parsing script to arrange fault scenarios, the arrangement of scenarios can be applied to different network devices, thereby enabling the fault information to be quickly found based on the corresponding fault scenario, thus improving data processing efficiency.

[0085] Please see Figure 4 In step S103 of some embodiments, the fault diagnosis and analysis processing of the fault information based on the heterogeneous interface orchestration method to obtain the fault cause includes the following steps:

[0086] Step S401: Perform configuration lookup processing on the fault information according to the manufacturer's instruction model to obtain configuration information;

[0087] Step S402: The configuration information is encapsulated to obtain a heterogeneous interface;

[0088] Step S403: Perform parameter orchestration processing on the heterogeneous interface to obtain a parameter orchestration interface;

[0089] Step S404: Perform rule arrangement and process arrangement processing on the parameter arrangement interface to obtain the cause of the fault.

[0090] In step S401 of some embodiments, fault information is processed for configuration lookup according to the manufacturer's instruction model. This manufacturer's instruction model can include CLI instruction model, Netconf instruction model, and Config instruction model. Specifically, CLI instructions are the most common instruction method for network devices. Users can typically log in to the communication device via SSH and view various device information, such as status, traffic, rate, packet loss, and relationships, according to the instruction sets defined by each manufacturer. Netconf is a new communication and interaction protocol between software systems and devices. Network management software systems can achieve local management through the Netconf protocol, performing operations such as installing, modifying, and deleting configurations of remote devices. Furthermore, device configuration information can be restored, and new configuration data can be loaded through protocol-defined operations, facilitating the collection of various data status and configuration information stored on network devices. Netconf is a network configuration and management protocol based on Extensible Markup Language (XML) and uses a simple RPC (Remote Procedure Call) mechanism to achieve communication between clients and servers. The Config instruction model is another traditional instruction method. All network devices have their own device configuration files. When an external system modifies the device configuration based on CLI or Netconf instructions, the changes are stored in the device's own configuration file. Therefore, by using the device's Config instruction model, the device's configuration information can be quickly obtained, thereby diagnosing various faults such as protocol configuration errors, IP address configuration errors, and BGP Peer configuration errors.

[0091] In step S402 of some embodiments, since the CLI commands, Netconf commands, and Config commands input by devices of different manufacturers, models, and versions have completely different return results, this embodiment of the application needs to develop corresponding virtual commands to encapsulate the return results of these device-side real commands into a unified JSON output parameter result, thereby obtaining a heterogeneous interface. The development based on virtual commands, using scripting languages ​​and configuring through the software system's front-end page to obtain the heterogeneous interface, facilitates rapid system configuration, flexible loading, and unified scheduling. There is a one-to-one correspondence between real commands and virtual commands, while there is a many-to-one relationship between virtual commands and virtual command sets. This is mainly to avoid differences between different manufacturers, models, and versions. Taking viewing device optical port information as an example, the command return results from different manufacturers are completely different. Therefore, to uniformly encapsulate them into an OPENAPI, i.e., a heterogeneous interface, it is necessary to normalize the commands from different manufacturers at the virtual command level according to unified input and output parameters. These virtual instructions are then merged into a unified "Device Optical Port Query" virtual instruction set, namely Restful OPENAPI, to construct a heterogeneous interface. For example, "RES_STN_IfTxPower_Query_API" corresponds to the output parameters of the OPENAPI encapsulation of the CLI command for viewing device optical port information. The output parameters include the most crucial data from the CLI command's return result, such as received optical power and transmitted optical power. This allows for direct cross-system and cross-platform heterogeneous calls during optical path fault diagnosis.

[0092] In step S403 of some embodiments, if configuration modeling is to be performed through a unified RESTful API in a complex communication network, it is necessary to uniformly define and arrange the input and output parameters involved in the API to obtain a parameter arrangement interface.

[0093] In step S404 of some embodiments, rule orchestration is performed on the parameter orchestration interface, i.e., specific judgment rules are added. Taking "RES_STN_IfTxPower_Query_API" as an example, it is determined whether the optical path is normal. This involves the judgment between multiple output parameters in the returned output parameters of the Restful API. By orchestrating rules such as "the received optical power is between the lower and upper thresholds of the received optical power, and the transmitted optical power is also between the lower and upper thresholds of the transmitted optical power," the interface can be uniformly orchestrated on the front-end page of the software system, thereby ensuring flexible configuration and modification of the rules. After the parameter orchestration and rule orchestration are completed, the process of various complex scenarios can be flexibly orchestrated. In the embodiments of this application, parameter orchestration is performed on the virtual instruction set. The arrows of each virtual instruction set result involve the orchestration of "rules." All fork positions either lead to the next virtual instruction set or directly obtain the diagnostic conclusion, which can be flexibly orchestrated. After the process orchestration, the final designed conclusions are the output of the fault autonomous diagnosis analysis. In one feasible embodiment, an example of a diagnostic analysis is shown. This diagnosis is automatically initiated by the system when a "Status Down" fault occurs, and the fault cause conclusion after automatic diagnostic analysis is "optical path error" (highlighted in red). Please refer to [link to relevant documentation]. Figure 5 In this application embodiment, a network fault autonomous diagnosis and analysis model can be pre-trained. The input of the model is different manufacturer instruction models. By converting different inputs into virtual instructions and virtual instruction sets, and then by automatically designing parameter substitution, parameter arrangement, rule arrangement and process coding are performed, and the corresponding diagnostic conclusions are output, such as optical path degradation, link congestion, etc.

[0094] One of the above technical solutions has the following advantages or beneficial effects: This application embodiment uses a heterogeneous RESTful API to achieve autonomous network fault diagnosis and analysis, enabling heterogeneous interaction between different software systems. It also supports different network device manufacturers, models, versions, command types, and capability sets. Through a rich capability set, the system can achieve autonomous diagnostic analysis capabilities based on flexible scheduling using automated rules.

[0095] In step S403 of some embodiments, the parameter orchestration processing of the heterogeneous interface to obtain the parameter orchestration interface includes the following steps:

[0096] Obtain the network topology of the communication network;

[0097] The communication network structure is divided into topologies to obtain the network topology.

[0098] The parameter orchestration interface is obtained by defining parameters of the heterogeneous interface according to the network topology.

[0099] In this embodiment, the communication network topology is divided in detail, including four types: ring network, multi-uplink, U-shaped uplink, and double-cross-uplink. Specifically: Ring network: refers to a group of devices interconnected in pairs, such as a device ring network; Multi-uplink (including single uplink): refers to the interconnection between a single device and multiple devices, such as a dual uplink between a Broadband Access Server (BAS) and an Optical Line Terminal (OLT); U-shaped uplink: refers to the interconnection of one pair of devices with another pair of devices, such as a U-shaped uplink between core devices and aggregation devices; Double-cross-uplink: refers to the interconnection of one pair of devices with another pair of devices, such as the Spine-Leaf network architecture of a new metropolitan area network. After defining these network topologies, the main parameters in the network can be defined. Please refer to... Figure 6 , Figure 6 The diagram illustrates an IPRAN / STN network structure involving ring networks and U-shaped uplink configurations, comprising ten devices from 601 to 610. When device 605 (circled in red) fails (e.g., due to poor link relay quality), this failed device becomes the starting device for the specified object, i.e., the "local device." Based on this, device 603 can be quickly defined as the peer device and uplink device, device 606 as the parallel device, and device 607 as the downlink device, along with the corresponding local port, uplink port, parallel port, and downlink port on the link. This definition allows for design and configuration during process orchestration, using parameter variables to ensure the validity and accuracy of RESTful API calls. In one feasible embodiment, the parameter "RES_STN_IfTxPower_Query_API" is configured. The login device is designated as the "uplink device," meaning that if the fault is a Class B device, the query will target the uplink device. The general parameter "Uplink device downlink port" is selected, indicating that the API call will query the downlink port of the city-level ER device. All RESTful APIs have input parameters, the most commonly used of which are device IP and device port. Therefore, these parameters need to be accurately designed and configured to ensure the rationality and accuracy of the entire self-diagnostic process orchestration.

[0100] One of the above technical solutions has the following advantages or beneficial effects: By arranging parameters for heterogeneous interfaces, the embodiments of this application can ensure the effectiveness and accuracy of heterogeneous interface calls through parameter variables, thereby improving the rationality and accuracy of the entire self-diagnosis process arrangement.

[0101] Please see Figure 7 In step S104 of some embodiments, the parameter verification and instruction rollback detection processing of the disposal decision includes the following steps:

[0102] Step S701: Determine configuration parameters and configuration instructions based on the disposal decision;

[0103] Step S702: Perform parameter comparison processing on the configuration parameters according to the network link to obtain the verification result;

[0104] Step S703: The configuration command is issued according to the verification result, and anomaly detection is performed on the issued command. When an anomaly is detected, the issued command is rolled back.

[0105] In this embodiment, the handling decision can be implemented through the orchestration of heterogeneous interfaces (including parameter orchestration, rule orchestration, and process orchestration). However, the fault handling process is a write operation on the device side. If errors are found in the handling instructions or parameters, they may affect the network and services. Therefore, this embodiment analyzes the handling decision to obtain configuration parameters and configuration instructions. Before issuing the configuration instructions, the configuration parameters are verified by comparing the parameters according to the network links to obtain the verification results. In one feasible embodiment, taking the modification of the link Cost value as an example, it is necessary to query the Cost value of the target link before modification, the Cost values ​​of links with the same source and destination as the target link, and the Cost values ​​of other links with Equal-Cost Multi-Path Routing (ECMP) with the target link. These Cost values ​​are then compared to confirm the parameter value to be modified. After the verification is passed, the configuration instructions are issued, and anomaly detection is performed on the issued instructions. When an anomaly is detected, the issued instructions are rolled back.

[0106] In step S703 of some embodiments, the step of detecting anomalies in the issued command and performing command rollback processing when an anomaly is detected includes the following steps:

[0107] The issued command is processed by setting a tag to obtain a rollback tag;

[0108] The issued instructions are processed according to the preset trial operation time, and the issued instructions are detected according to the network operation status and network performance indicators to obtain the detection results;

[0109] When the detection result indicates an abnormal delivery, the delivery command is rolled back according to the rollback tag.

[0110] In this embodiment, a rollback tag can be set for the device before configuration changes or command issuance, supporting configuration rollback capabilities after configuration command issuance. In case of configuration issuance anomalies, previously executed configurations will be automatically rolled back, preventing redundant data. Similarly, this embodiment supports setting the device trial run time: after configuring the trial run time, network operation status and network performance indicators can be observed during this period. In case of anomalies, manual rollback or automatic rollback after timeout is possible. Please refer to [link to relevant documentation]. Figure 8 This application embodiment sets rollback indicators, then performs first-order configuration data distribution, performs anomaly detection on the configuration distribution, and rolls back the configuration data when an anomaly is found, regenerating the configuration data and returning to the step of setting rollback indicators. When no anomalies are found, second-order commit processing is performed. In trial operation mode, if configuration data timeout occurs, configuration data regression is performed. If the configuration is applied and running on the live network in immediate execution mode, rollback to the corresponding tag point can be performed according to actual needs. Actual needs can be determined by observing the network operation status and network performance indicators.

[0111] The solutions of this application embodiment will be described in detail and explained below with reference to specific application examples:

[0112] Please see Figure 8 This application's embodiments achieve autonomous network fault detection based on a scripting language. By designing and arranging corresponding alarm and potential problem scenarios using a scripting language for data interaction commands, different types of alarm and potential problem generators can be flexibly customized in a modular fashion, enabling configurability of code, rules, processes, and tasks. Then, autonomous network fault diagnosis and analysis is achieved based on a heterogeneous RESTful API. The core of the autonomous fault diagnosis and analysis process is a heterogeneous interactive RESTful API (virtual instruction set), allowing configuration and arrangement of parameters, rules, conclusions, and commands within the process. Finally, autonomous network fault handling decisions are achieved based on a self-protection mechanism, including real-time parameter verification and automatic command rollback capabilities. By automatically verifying the accuracy of parameters before configuring and issuing operations, and automatically setting rollback points, recovery can be achieved if an error occurs during handling.

[0113] Please see Figure 9 This application also provides a network fault detection and processing device that can implement the above-described network fault detection and processing method. The device includes:

[0114] The first module 901 is configured to acquire alarm information;

[0115] The second module 902 is configured to convert the alarm information into a scripting language for network fault perception processing to obtain fault information.

[0116] The third module 903 is configured to perform fault diagnosis and analysis on the fault information based on a heterogeneous interface orchestration method to obtain the cause of the fault.

[0117] The fourth module 904 is configured to generate a corresponding handling decision based on the cause of the fault, and to perform parameter verification and instruction rollback detection processing on the handling decision, and to execute the instructions that pass the detection.

[0118] It is understood that the content of the above method embodiments is applicable to the present device embodiments. The specific functions implemented by the present device embodiments are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0119] This application also provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the aforementioned network fault perception and processing method. This electronic device can be any smart terminal, including tablet computers, in-vehicle computers, etc.

[0120] It is understood that the content of the above method embodiments is applicable to this device embodiment. The specific functions implemented by this device embodiment are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0121] Please see Figure 10 , Figure 10 The hardware structure of an electronic device according to another embodiment is illustrated. The electronic device includes:

[0122] The processor 1001 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this application.

[0123] The memory 1002 can be implemented as a read-only memory (ROM), static storage device, dynamic storage device, or random access memory (RAM). The memory 1002 can store the operating system and other applications. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 1002 and is called and executed by the processor 1001 to execute a network fault perception processing method according to an embodiment of this application.

[0124] Input / output interface 1003 is used to implement information input and output;

[0125] The communication interface 1004 is used to enable communication and interaction between this device and other devices. Communication can be achieved through wired means (such as USB, network cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.).

[0126] Bus 1005 transmits information between various components of the device (e.g., processor 1001, memory 1002, input / output interface 1003, and communication interface 1004);

[0127] The processor 1001, memory 1002, input / output interface 1003 and communication interface 1004 are connected to each other within the device via bus 1005.

[0128] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the aforementioned network fault perception and processing method.

[0129] It is understood that the content of the above method embodiments is applicable to this storage medium embodiment. The specific functions implemented in this storage medium embodiment are the same as those in the above method embodiments, and the beneficial effects achieved are also the same as those achieved in the above method embodiments.

[0130] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory may optionally include memory remotely located relative to the processor, and these remote memories can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0131] This application provides a network fault perception and processing method, apparatus, electronic device, and storage medium. This solution acquires alarm information, converts it into a scripting language, and performs network fault perception processing to obtain fault information. It enables autonomous network fault perception using a scripting language, improving system flexibility. Furthermore, this solution uses a heterogeneous interface orchestration approach to perform fault diagnosis and analysis to obtain the fault cause, allowing for configuration and orchestration of the diagnostic process, thus improving the efficiency of network fault diagnosis. Additionally, this solution generates corresponding handling decisions based on the fault cause, performs parameter verification and instruction rollback detection processing on the handling decisions, and executes instructions that pass the detection. This allows for verification and rollback recovery processing of configuration decisions, further improving the efficiency of network fault perception and processing.

[0132] The embodiments described in this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided by the embodiments of this application. As those skilled in the art will know, with the evolution of technology and the emergence of new application scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems.

[0133] Those skilled in the art will understand that the technical solutions shown in the figures do not constitute a limitation on the embodiments of this application, and may include more or fewer steps than shown, or combine certain steps, or different steps.

[0134] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0135] Those skilled in the art will understand that all or some of the steps in the methods disclosed above, as well as the functional modules / units in the systems and devices, can be implemented as software, firmware, hardware, or suitable combinations thereof.

[0136] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises 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.

[0137] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0138] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of the units described above is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0139] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0140] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0141] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes multiple instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing programs, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0142] The preferred embodiments of the present application have been described above with reference to the accompanying drawings, but this does not limit the scope of the claims of the present application. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and substance of the embodiments of the present application shall be within the scope of the claims of the present application.

Claims

1. A network fault detection and processing method, characterized in that, The method includes the following steps: Obtain alarm information; The alarm information is converted into a scripting language for network fault detection processing to obtain fault information; The fault information is analyzed and processed based on a heterogeneous interface orchestration method to obtain the cause of the fault. Based on the cause of the fault, a corresponding handling decision is generated, and the handling decision is subjected to parameter verification and instruction rollback detection processing. Instructions that pass the detection are executed. The fault diagnosis and analysis processing based on the heterogeneous interface orchestration method to obtain the fault cause includes the following steps: Based on the manufacturer's instruction model, the fault information is processed by configuration lookup to obtain configuration information; The configuration information is encapsulated to obtain a heterogeneous interface; The heterogeneous interface is processed by parameter orchestration to obtain a parameter orchestration interface; The parameter orchestration interface is processed by rule orchestration and process orchestration to obtain the cause of the fault; The parameter orchestration process for the heterogeneous interface to obtain the parameter orchestration interface includes the following steps: Obtain the network topology of the communication network; The communication network structure is divided into topologies to obtain the network topology. The parameter orchestration interface is obtained by defining parameters of the heterogeneous interface according to the network topology.

2. The method according to claim 1, characterized in that, The process of converting the alarm information into a scripting language for network fault detection processing to obtain fault information includes the following steps: The alarm information is configured and parsed using scripting language code to obtain a parsing script; The parsing script is processed to create a scenario arrangement, resulting in a fault scenario; The fault scenario input model generator is subjected to fault type analysis and processing to output the fault information.

3. The method according to claim 2, characterized in that, The process of arranging the parsing script to obtain the fault scenario includes the following steps: The parsing script is subjected to application capability analysis and serial arrangement processing to obtain virtual instructions; The virtual instructions are uniformly arranged and processed according to the functional application to obtain the fault scenario.

4. The method according to any one of claims 1 to 3, characterized in that, The parameter verification and instruction rollback detection process for the decision-making process includes the following steps: The configuration parameters and configuration instructions are determined based on the aforementioned decision-making process; The configuration parameters are compared based on the network link to obtain the verification result. The configuration command is issued based on the verification result, and anomaly detection is performed on the issued command. When an anomaly is detected, the issued command is rolled back.

5. The method according to claim 4, characterized in that, The step of detecting anomalies in issued commands and rolling back the issued commands when an anomaly is detected includes the following steps: The issued command is processed to set a tag, resulting in a rollback tag; The issued instructions are processed according to the preset trial operation time, and the issued instructions are detected according to the network operation status and network performance indicators to obtain the detection results; When the detection result indicates an abnormal delivery, the delivery command is rolled back according to the rollback tag.

6. A network fault detection and processing device, characterized in that, The device includes: The first module is configured to acquire alarm information; The second module is configured to convert the alarm information into a scripting language for network fault detection processing to obtain fault information. The third module is configured to perform fault diagnosis and analysis on the fault information based on a heterogeneous interface orchestration method to obtain the cause of the fault. The fourth module is configured to generate a corresponding handling decision based on the cause of the fault, and to perform parameter verification and instruction rollback detection processing on the handling decision, and to execute the instructions that pass the detection. The third module is configured to perform fault diagnosis and analysis on the fault information based on a heterogeneous interface orchestration method to obtain the cause of the fault, including: Based on the manufacturer's instruction model, the fault information is processed by configuration lookup to obtain configuration information; The configuration information is encapsulated to obtain a heterogeneous interface; The heterogeneous interface is processed by parameter orchestration to obtain a parameter orchestration interface; The parameter orchestration interface is processed by rule orchestration and process orchestration to obtain the cause of the fault; The parameter orchestration process for the heterogeneous interface to obtain a parameter orchestration interface includes: Obtain the network topology of the communication network; The communication network structure is divided into topologies to obtain the network topology. The parameter orchestration interface is obtained by defining parameters of the heterogeneous interface according to the network topology.

7. An electronic device, characterized in that, The electronic device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the method according to any one of claims 1 to 5.

8. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1 to 5.

Images