Alarm processing method and apparatus, device and computer-readable storage medium

Abstract

The present application relates to the technical field of network management, and discloses an alarm processing method and apparatus, a device, and a computer-readable storage medium. The method comprises: receiving alarm information sent by a network device; obtaining an alarm level of the alarm information, wherein the alarm level is determined on the basis of intent information, and the intent information is used for constructing or maintaining an operation and maintenance system where the network device is located; and processing the alarm information on the basis of the alarm level. The intent information reflects the maintenance intent or the construction intent of the operation and maintenance system, that is, the alarm level is determined on the basis of the maintenance intent or the construction intent, and the alarm information is processed subsequently on the basis of the alarm level, so that the alarm information is identified and processed on the basis of the maintenance intent or the construction intent, the processing process is more flexible, and the precision is high. The received alarm information is processed on the basis of the alarm level, ensuring that the processed alarm information can be processed instantly, avoiding alarm omission, and achieving high accuracy.

Description

Alarm handling methods, devices, equipment and computer-readable storage media

[0001] This application claims priority to Chinese Patent Application No. 202410667390.1, filed on May 27, 2024, entitled "Alarm Processing Method, Apparatus, Device and Computer-Readable Storage Medium", the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of network management technology, and in particular to alarm processing methods, apparatus, devices and computer-readable storage media. Background Technology

[0003] In the field of network management technology, monitoring equipment monitors the operation and maintenance system and handles alarms within the system. Taking network devices in the operation and maintenance system as an example, when a network device triggers an alarm, it sends the alarm information to the monitoring equipment, which then processes the alarm information.

[0004] In related technologies, when the orchestration or control equipment in the operation and maintenance system distributes configurations, it manually marks the network devices being configured. Based on these markings, when the monitoring equipment subsequently receives alarm information from the network devices, if it determines that the network device is a marked network device, regardless of whether the network device triggered the alarm due to the distributed configuration, the monitoring equipment will assume that the network device's alarm was triggered by the distributed configuration and ignore the received alarm information.

[0005] The above method ignores all alarm information sent by the tagged network device, which may lead to missed alarms and low accuracy in alarm processing. Summary of the Invention

[0006] This application provides an alarm processing method, apparatus, device, and computer-readable storage medium to solve the problems existing in the related technologies. The technical solution is as follows.

[0007] Firstly, an alarm processing method is provided, comprising: receiving alarm information sent by a network device; obtaining the alarm level of the alarm information, wherein the alarm level is determined based on intent information, and the intent information is used to build or maintain the operation and maintenance system in which the network device is located; and processing the alarm information according to the alarm level.

[0008] The alarm level obtained in this application is determined based on intent information. Since intent information reflects the maintenance or construction intent of the operation and maintenance system, the alarm level is determined based on the maintenance or construction intent. Subsequent processing of alarm information according to the alarm level enables the identification and processing of alarm information based on the maintenance or construction intent, resulting in a more flexible and accurate processing process. Furthermore, because the received alarm information is processed based on the alarm level, even alarms not triggered by intent information can be processed, avoiding missed alarms and ensuring high accuracy in alarm processing.

[0009] In one possible implementation, the alarm information includes an alarm level, which is determined by the network device based on device maintenance information in the intent information. This device maintenance information describes the corresponding change operation performed on the network device. Since the alarm information includes the alarm level, it means that the network device has already determined the alarm level during the alarm information transmission process. Therefore, the alarm level can be obtained simply by extracting the alarm level from the alarm information, making the alarm level acquisition process simple and efficient.

[0010] In one possible implementation, before obtaining the alarm level of the alarm information, the process further includes: obtaining intent information; determining at least one device maintenance information based on the intent information, whereby the device maintenance information describes the change operations of network devices in the operation and maintenance system; and obtaining the alarm level of the alarm information, which includes: determining the alarm level based on at least one device maintenance information and the alarm information. The alarm level can be determined using only the device maintenance information and the alarm information, involving less data and having lower complexity.

[0011] Furthermore, this application does not limit the method of obtaining alarm levels. It can extract alarm levels already included in alarm information, or the monitoring equipment can determine them based on equipment maintenance information, which is highly flexible.

[0012] In one possible implementation, determining the alarm level based on at least one device maintenance information and alarm information includes: determining at least one of a first matching result, a second matching result, or a third matching result based on at least one device maintenance information and alarm information; the first matching result indicates whether the occurrence time included in the alarm information falls within the maintenance period included in the device maintenance information; the second matching result indicates whether the abnormal event caused by the change operation includes the fault event included in the alarm information; and the third matching result indicates whether the faulty device where the abnormal event occurred includes the network device indicated by the alarm information; and determining the alarm level based on at least one of the first matching result, the second matching result, or the third matching result. The abnormal event and the faulty device can be determined based on the change operation included in the device maintenance information. This application does not limit the process for determining the alarm level; it can be determined based on one or more of the first matching result, the second matching result, and the third matching result, thus having broad applicability.

[0013] In one possible implementation, determining the alarm level based on at least one of a first matching result, a second matching result, or a third matching result includes: determining the alarm level as a first level when the first matching result indicates that the occurrence time is not during a maintenance period, or the second matching result indicates that the abnormal event does not include a fault event, or the third matching result indicates that the faulty device does not include a network device; or, determining the alarm level as a second level when the first matching result indicates that the occurrence time is during a maintenance period, the second matching result indicates that the abnormal event includes a fault event, and the third matching result indicates that the faulty device includes a network device, wherein the fault severity indicated by the second level is lower than the fault severity indicated by the first level.

[0014] The alarm level can be determined by comparing the matching results (first matching result, second matching result, and third matching result), and the determination process is simple. When all three matching results are successful, it indicates that the fault event was caused by a change operation. This fault event is a normal situation in the maintenance or construction and operation system, and the alarm information of the fault event is an invalid alarm. The identification process for invalid alarms is also simple. Furthermore, when the alarm information is invalid, its alarm level is lower than the first level (level two). Invalid alarms are suppressed by reducing the alarm level. The suppression process and the alarm level determination process are carried out simultaneously, resulting in high efficiency.

[0015] In one possible implementation, the alarm information also includes a first level. The first level can be extracted from the alarm information; the acquisition process is simple and has low operational complexity.

[0016] In one possible implementation, the faulty device includes at least one of a change device or an associated device, wherein the change device is a device that performs a change operation based on device maintenance information. Because the faulty device can include one or more of the change device or associated devices, it is not limited to a single faulty device and has broad applicability.

[0017] In one possible implementation, the intent information includes at least one of the following: device name, component name, link name, or instance name of the network device to be changed. At least one of the device name, component name, link name, or instance name is summary information, used to summarize the device, component, link, or instance to be changed during the maintenance or construction of the operation and maintenance system. Since the data volume of the summary information is smaller than that of the intent information, using the summary information instead of the intent information reduces data processing costs.

[0018] In one possible implementation, there are multiple alarm messages, and the alarm messages are processed according to their alarm levels. This includes: determining the processing priority of each alarm message based on its alarm level; and fixing the events triggered by each alarm message according to its processing priority. Determining the processing priority by alarm level clarifies the processing order of each alarm message, ensuring the logical consistency of the processing even when there are multiple alarm messages to be processed.

[0019] Secondly, an alarm processing method is provided, which includes: determining the alarm level based on the device maintenance information in the intent information, wherein the device maintenance information is used to describe the change operation corresponding to the network device, and the intent information is used to build or maintain the operation and maintenance system where the network device is located; obtaining alarm information including the alarm level; and sending the alarm information to the monitoring device, wherein the alarm level included in the alarm information is used by the monitoring device to process the alarm information.

[0020] The alarm level obtained in this application is determined based on intent information. Since the intent information reflects the maintenance intent or construction intent of the operation and maintenance system, the alarm level is determined based on the maintenance intent or construction intent. Subsequently, alarm information is processed according to the alarm level, realizing the identification and processing of alarm information based on the maintenance intent or construction intent. The processing process is more flexible and accurate.

[0021] In one possible implementation, determining the alarm level based on equipment maintenance information includes: determining at least one of a fourth matching result or a fifth matching result based on the equipment maintenance information, wherein the fourth matching result indicates whether the maintenance period included in the equipment maintenance information includes the occurrence time of the fault event that triggered the alarm, and the fifth matching result indicates whether the abnormal event caused by the change operation includes the fault event; and determining the alarm level based on at least one of the fourth matching result or the fifth matching result. This application does not limit the process for determining the alarm level; it can be determined based on one or more of the fourth and fifth matching results, thus having broad applicability.

[0022] In one possible implementation, the alarm level is determined based on at least one of the fourth or fifth matching results, including: determining the alarm level as Level 1 if the fourth matching result indicates that the occurrence time is not during a maintenance period, or if the fifth matching result indicates that the abnormal event does not include a fault event; or, determining the alarm level as Level 2 if the fourth matching result indicates that the occurrence time is during a maintenance period, and the fifth matching result indicates that the abnormal event includes a fault event, where the severity of the fault indicated by Level 2 is lower than that indicated by Level 1. The alarm level can be determined by comparing the matching results (fourth and fifth matching results), a simple and efficient process. When both matching results are successful, it indicates that the fault event was caused by a change operation, which is a normal situation in the maintenance or construction operation system, and the alarm information for the fault event is an invalid alarm. During the process of determining the fault level, the alarm level is also lowered to suppress invalid alarms; the suppression process and the alarm level determination process are performed simultaneously, resulting in high efficiency.

[0023] In one possible implementation, the device maintenance information includes at least one of first maintenance information or second maintenance information. The first maintenance information is used to control the network device to perform a change operation, and the second maintenance information is used to control the associated devices of the network device to perform a change operation. The device maintenance information received by the network device is not limited to one or more of the first and second maintenance information, thus having broad applicability.

[0024] Thirdly, an alarm processing device is provided, comprising: a receiving module for receiving alarm information sent by a network device; an acquisition module for acquiring the alarm level of the alarm information, wherein the alarm level is determined based on intent information, and the intent information is used to build or maintain the operation and maintenance system in which the network device is located; and a processing module for processing the alarm information according to the alarm level.

[0025] In one possible implementation, the alarm information includes an alarm level, which is determined by the network device based on device maintenance information in the intent information. The device maintenance information describes the corresponding change operation of the network device.

[0026] In one possible implementation, the acquisition module is further configured to acquire intent information; determine at least one device maintenance information based on the intent information, the device maintenance information being used to describe the change operations of network devices in the operation and maintenance system; and determine an alarm level based on at least one device maintenance information and alarm information.

[0027] In one possible implementation, the acquisition module is configured to determine at least one of a first matching result, a second matching result, or a third matching result based on at least one device maintenance information and alarm information. The first matching result indicates whether the occurrence time included in the alarm information is within the maintenance period included in the device maintenance information. The second matching result indicates whether the abnormal event caused by the change operation includes the fault event included in the alarm information. The third matching result indicates whether the faulty device where the abnormal event occurred includes the network device indicated by the alarm information. The alarm level is determined based on at least one of the first matching result, the second matching result, or the third matching result.

[0028] In one possible implementation, the acquisition module is configured to determine the alarm level as a first level when at least one of the following conditions is met: the first matching result indicates that the occurrence time is not during a maintenance period; the second matching result indicates that the abnormal event does not include a fault event; or the third matching result indicates that the faulty device does not include a network device. Alternatively, when the first matching result indicates that the occurrence time is during a maintenance period, the second matching result indicates that the abnormal event includes a fault event, and the third matching result indicates that the faulty device includes a network device, the alarm level is determined as a second level, wherein the fault severity indicated by the second level is lower than the fault severity indicated by the first level.

[0029] In one possible implementation, the alarm information also includes a first level.

[0030] In one possible implementation, the faulty device includes at least one of a change device or an associated device, wherein the change device is a device that performs a change operation based on device maintenance information.

[0031] In one possible implementation, the intent information includes at least one of the device name, component name, link name, or instance name of the network device to be changed.

[0032] In one possible implementation, there are multiple alarm messages. The processing module is used to determine the processing priority of each alarm message based on its alarm level, and to repair the events triggered by each alarm message according to its processing priority.

[0033] Fourthly, an alarm processing device is provided, comprising: a determining module, used to determine the alarm level based on device maintenance information in intent information, wherein the device maintenance information describes the change operation corresponding to the network device, and the intent information is used to build or maintain the operation and maintenance system where the network device is located; an acquiring module, used to acquire alarm information including the alarm level; and a sending module, used to send the alarm information to the monitoring device, wherein the alarm level included in the alarm information is used by the monitoring device to process the alarm information.

[0034] In one possible implementation, a determining module is configured to determine at least one of a fourth matching result or a fifth matching result based on equipment maintenance information, wherein the fourth matching result indicates whether the maintenance period included in the equipment maintenance information includes the occurrence time of the fault event that triggered the alarm, and the fifth matching result indicates whether the abnormal event caused by the change operation includes the fault event; and to determine the alarm level based on at least one of the fourth matching result or the fifth matching result.

[0035] In one possible implementation, the determining module is configured to determine the alarm level as a first level if the occurrence time of the fourth matching result indication is not during a maintenance period, or if the fifth matching result indication abnormal event does not include a fault event; or, if the occurrence time of the fourth matching result indication is during a maintenance period, and the fifth matching result indication abnormal event includes a fault event, the alarm level is determined as a second level, wherein the fault severity indicated by the second level is lower than the fault severity indicated by the first level.

[0036] In one possible implementation, the device maintenance information includes at least one of first maintenance information or second maintenance information, wherein the first maintenance information is used to control the network device to perform a change operation, and the second maintenance information is used to control the associated device of the network device to perform a change operation.

[0037] Fifthly, an alarm processing device is provided, the device including a processor for loading and executing at least one instruction to cause the alarm processing device to perform the method of the first aspect or any possible implementation of the first aspect, or to perform the method of the second aspect or any possible implementation of the second aspect.

[0038] In one possible implementation, the device includes a memory coupled to a processor, the memory storing at least one instruction.

[0039] In a sixth aspect, an alarm processing system is provided, comprising a monitoring device and a network device, wherein the monitoring device is used to perform the method of the first aspect or any possible implementation thereof, and the network device is used to perform the method of the second aspect or any possible implementation thereof.

[0040] In a seventh aspect, a computer-readable storage medium is provided, wherein at least one instruction is stored in the computer-readable storage medium, the instruction being loaded and executed by a processor to implement the alarm handling method in the first aspect or any possible implementation of the first aspect, or to implement the alarm handling method in the second aspect or any possible implementation of the second aspect.

[0041] Eighthly, a computer program (product) is provided, comprising computer program / instructions, which are executed by a processor to enable a computer to implement the alarm handling method in the first aspect or any possible implementation of the first aspect, or to implement the alarm handling method in the second aspect or any possible implementation of the second aspect.

[0042] A ninth aspect provides a communication device comprising: a transceiver, a memory, and a processor. The transceiver, the memory, and the processor communicate with each other via an internal connection path. The memory stores instructions, and the processor executes the instructions stored in the memory to control the transceiver to receive and transmit signals. When the processor executes the instructions stored in the memory, it causes the processor to perform the method of the first aspect or any possible implementation thereof, or to perform the method of the second aspect or any possible implementation thereof. Optionally, the communication device may be a chip.

[0043] Optionally, there may be one or more processors and one or more memories.

[0044] Alternatively, the memory can be integrated with the processor, or the memory can be set up separately from the processor.

[0045] In the specific implementation process, the memory can be a non-transitory memory, such as read-only memory (ROM), which can be integrated with the processor on the same chip or set on different chips. This application does not limit the type of memory or the way the memory and processor are set.

[0046] In a tenth aspect, a chip is provided, including a processor for retrieving and executing program instructions or code stored in a memory, causing a communication device equipped with the chip to perform the methods described in the foregoing aspects.

[0047] Eleventhly, another chip is provided, comprising: an input interface, an output interface, a processor, and a memory, wherein the input interface, the output interface, the processor, and the memory are connected by an internal connection path, the processor being used to execute code in the memory, and when the code is executed, the processor being used to perform the methods in the above aspects.

[0048] It should be understood that the alarm processing device mentioned in the third and fourth aspects above can be the device mentioned in the fifth aspect, or the chip mentioned in the tenth or eleventh aspect. The beneficial effects achieved by the technical solutions and corresponding possible implementations of the third to eleventh aspects of this application can be found in the above description of the technical effects of the first aspect and its corresponding possible implementations or the second aspect and its corresponding possible implementations, and will not be repeated here. Attached Figure Description

[0049] Figure 1 is a schematic diagram of an implementation environment provided in an embodiment of this application;

[0050] Figure 2 is a schematic diagram of the structure of an operation and maintenance system provided in an embodiment of this application;

[0051] Figure 3 is a flowchart of an alarm processing method provided in an embodiment of this application;

[0052] Figure 4 is a schematic diagram of an alarm processing procedure provided in an embodiment of this application;

[0053] Figure 5 is a schematic diagram of the connection of a network device provided in an embodiment of this application;

[0054] Figure 6 is a schematic diagram of another alarm processing procedure provided in an embodiment of this application;

[0055] Figure 7 is an interactive schematic diagram of an alarm processing embodiment provided in this application;

[0056] Figure 8 is a schematic diagram of an alarm processing device provided in an embodiment of this application;

[0057] Figure 9 is a schematic diagram of another alarm processing device provided in an embodiment of this application;

[0058] Figure 10 is a schematic diagram of the structure of a network device provided in an embodiment of this application;

[0059] Figure 11 is a schematic diagram of another network device provided in an embodiment of this application. Detailed Implementation

[0060] The terminology used in the embodiments section of this application is only for explaining specific embodiments of this application and is not intended to limit this application. To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be further described in detail below with reference to the accompanying drawings.

[0061] In network management technology, alarms are a crucial function. Taking alarms for fault repair as an example, when a device in the network malfunctions, it promptly generates an alarm message and notifies the monitoring equipment. The monitoring equipment then processes the alarm information, locates and diagnoses the fault event, and supports corresponding maintenance operations to achieve fault repair. The accuracy, real-time performance, and effectiveness of alarm information are paramount to ensuring timely fault detection, early warning, and resolution.

[0062] In related technology one, network device alarm information is uniformly classified statically. The alarm level is determined based on the correspondence between the triggering event and the alarm level, and alarm information is sent based on the alarm level. When the monitoring device receives an alarm, it will ignore the alarm if it identifies that the event was caused by manual maintenance or configuration operations issued by the orchestration / control equipment. Since the monitoring device and the equipment used for managing configuration operations / network maintenance are independent devices, the monitoring device cannot obtain maintenance information for configuration operations or network maintenance, requiring manual identification, which is costly and inefficient.

[0063] In related technology two, orchestration or control equipment manually marks the network devices being configured during configuration distribution. Monitoring equipment obtains the marking results. If the alarm information received by the monitoring equipment originates from a marked network device, it will ignore the received alarm information regardless of whether the network device sent the alarm information due to the distributed configuration. During manual operation, control and network devices cannot detect human intervention. When maintenance personnel distribute configurations based on network maintenance intentions, they often only focus on the specific configuration and typically do not mark the network devices involved in the maintenance. Monitoring equipment cannot identify or suppress alarm information caused by network maintenance and uniformly ignores alarm information sent by marked network devices, easily leading to missed alarms.

[0064] This application provides an alarm processing method. Referring to Figure 1, which illustrates the implementation environment of the alarm processing method provided in this application, the environment includes a monitoring device 01 and a network device 02. The monitoring device 01 and the network device 02 can establish a communication connection via a wired or wireless network. The network device 02 acquires alarm information and sends it to the monitoring device 01. The monitoring device 01 obtains the alarm level based on the alarm information. The alarm level is determined according to intent information, which reflects the intention to maintain or build the operation and maintenance system. The alarm information is processed according to the alarm level to reflect the intention to maintain or build the operation and maintenance system.

[0065] For example, monitoring device 01 can be connected to a network device 02 as shown in Figure 1, and monitoring device 01 can also be connected to multiple network devices 02. In one possible scenario, the operation and maintenance system where network device 02 is located is a software-defined network (SDN) system, which is managed based on SDN technology. SDN technology is a network management method that supports dynamically programmable network configuration, improving network flexibility and management efficiency. Figure 2 shows a schematic diagram of an SDN system, which includes an orchestrator, a controller, and network devices. The orchestrator can be connected to one or more controllers, and the controllers can also be connected to one or more network devices. Optionally, network device 02 may be referred to as a network element device in some cases.

[0066] In SDN systems, orchestration devices can use network configuration models to instruct control devices how to configure various parts of the network. When multi-vendor or multi-domain management exists, the orchestration device has a broader view of the entire or partial network. The orchestration device's northbound interface (NBI) can be configured based on a specific service model. Protocols used between the orchestration device and control devices include, for example, the network configuration protocol (NETCONF), the representational state transfer configuration protocol (RESTCONF), and the representational state transfer (RESTful) protocol. NETCONF and RESTCONF are both network management protocols driven by the yet another next generation (YANG) model.

[0067] Optionally, the control device distributes configurations to network devices via RESTCONF, NETCONF, or other configuration protocols, such as using a device configuration model to set configuration parameters on a single network device. The network device can then perform operations based on the configuration parameters distributed by the control device. In SDN systems comprising multiple network devices, such as the four network devices in Figure 2, these devices can be managed by a single monitoring device, meaning one monitoring device connects to multiple network devices. Alternatively, multiple monitoring devices can manage the same or different numbers of network devices connected to and managed by different monitoring devices. In one possible scenario, the SDN system may also include monitoring devices, meaning that in addition to defining network configurations, the SDN system can also provide functions such as fault operation and maintenance and performance monitoring.

[0068] For example, network device 02 can be a switch, router, firewall, optical transmission equipment, or access point (AP), etc., while monitoring device 01 can be any network device with communication capabilities. Monitoring device 01 can be a network device, desktop computer, laptop computer, smartphone, or Internet of Things (IoT) terminal device, or a server deployed in any location, such as a central cloud server, edge cloud server, or local server in a local data center. The server can be a physical server or a cloud server providing cloud computing services. Optionally, monitoring device 01 and network device 02 can be independent devices or components within devices, such as transceivers, processors, or chips.

[0069] This application provides an alarm processing method that can be applied to the implementation environment shown in Figure 1. Taking the method as an example where the monitoring device and the network device interact to execute the method, the flowchart of the method is shown in Figure 3, including S301-S306.

[0070] S301, the network device determines the alarm level based on the device maintenance information in the intent information.

[0071] In one possible implementation, network devices are configured within an operations and maintenance (O&M) system. The O&M system refers to a system used for network operations and maintenance. It can include the SDN system shown in Figure 2, or other network topologies. In some cases, the O&M system may also be called an O&M network system. In some situations, there is a need to build or maintain the O&M system. Building the O&M system includes constructing hardware systems, installing software systems, and establishing a network application environment. Constructing hardware systems includes, for example, laying network cabling and installing network hardware devices. After constructing the hardware system, it will be tested, such as checking the connectivity between hardware systems. Optionally, installing software systems may involve installing a network operating system. During the software installation process, network parameters, such as routing protocols, will be set. Establishing a network application environment includes installing application systems, establishing a security architecture, configuring reliability facilities, and starting network services. After constructing the O&M system, O&M personnel will also maintain it to check its health and security. For example, upgrading and updating the software of network devices in the O&M system to enhance their resistance to attacks, or maintaining the hardware of network devices to avoid potential faults.

[0072] For example, operations and maintenance (O&M) personnel can set intent information to convey their intent to build or maintain the O&M system. Referring to Figure 4, O&M personnel can input intent information through any of the following devices: Operation Support Systems (OSS), Network Operations Center (NOC), or Orchestration Device. This intent information is used to build or maintain the O&M system. After obtaining the intent information through interaction with the O&M personnel, any of the OSS, NOC, or Orchestration Device can send the intent information to the control device. The control device then determines the necessary changes that each network device needs to perform to complete the maintenance or build intent indicated by the intent information, thus obtaining device maintenance information.

[0073] This application's embodiments do not limit the content of the intent information. The intent information may include device maintenance information for multiple network devices, with each device maintenance information indicating a change operation for a single network device. For example, maintenance personnel determine that the maintenance intent is to install or maintain the hardware components of network devices A, B, and C. Therefore, they need to remove the hardware components of network devices A, B, and C, clean or test the non-faulty hardware components, and replace the faulty hardware components. Since both cleaning and replacing hardware components require removing them from the network devices, the maintenance personnel thus determine that the intent information includes removing the hardware components of network devices A, B, and C. This intent information includes three device maintenance information entries, each indicating a change operation for network devices A, B, and C.

[0074] In some possible cases, code examples of intent information are as follows:

[0075] Optionally, the intent information may include maintenance intent or construction intent, as shown in the above embodiments, and other information such as device description information. The maintenance intent indicates the purpose of maintaining the operation and maintenance system, while the construction intent indicates the purpose of building the operation and maintenance system. The construction intent or maintenance intent includes at least one of the following: the device name, component name, and link name of the network device to be changed, and the change operation thereof. The construction intent or maintenance intent corresponds to the 'identity document (id)', 'operation', 'start-time', and 'duration' in the first segment of the code example above. In some cases, the construction intent or maintenance intent may also be referred to as summary information, or network maintenance and service change context summary information. Other information such as device description information corresponds to other codes such as object-type, name, and site in the code example above. Optionally, the intent information may also include only the maintenance intent or construction intent. For example, if the maintenance personnel determine that the maintenance intention for the maintenance system is to check the interface board of the network device, the maintenance personnel input the maintenance intention as "check the interface board of the network device" into the orchestration device and obtain the intention information that only includes the maintenance intention.

[0076] Regardless of the intent information acquired by the control device, it can determine the device maintenance information based on the intent information, thereby obtaining the change operations required for each network device during the maintenance or construction of the operation and maintenance system. When the intent information includes device maintenance information for multiple network devices, the control device can separate these multiple device maintenance information entries. Continuing with the example in the above embodiment where the intent information includes unplugging the hardware components of network device A, network device B, and network device C, the control device separates the intent information to obtain three device maintenance information entries: Device maintenance information 1 includes unplugging the hardware components of network device A, Device maintenance information 2 includes unplugging the hardware components of network device B, and Device maintenance information 3 includes unplugging the hardware components of network device C.

[0077] When the intent information includes maintenance or construction intents, the control device, after acquiring the intent information, determines the change operations required for each network device to fulfill the maintenance or construction intent, thus obtaining at least one device maintenance information. For example, if the intent information is to inspect the optical module of the interface board of a network device in the operation and maintenance system, the optical module to be inspected must be removed from the network device. The control device selects some or all of the connected network devices as the network devices to be inspected for the optical module, and determines the device maintenance information of the selected network devices as the optical module with the interface board removed. Alternatively, if the intent information is to inspect the interface board of a network device, the interface board operation needs to be changed or replaced during the inspection process. The control device selects some or all of the connected network devices as the network devices to be inspected for the interface board, and determines the device maintenance information of the selected network devices as the operation change or replacement for the interface board. This operation change or replacement can be a manual operation, such as manually removing the module, or it can use a management state shutdown or lock. When the interface board has a router interface, since the router interface supports enabling / disabling, the operation change and replacement can also be changed from enabling to disabling.

[0078] Alternatively, the control equipment, based on the network's periodic inspection requirements, identifies the network devices or components to be changed and determines the equipment maintenance information for each device based on its historical change history. Periodic inspections are used to prevent system failures and eliminate potential problems. Periodic inspections can be either routine checks or tests. Routine checks detect abnormalities in software functionality or security patches, device boards, ports, fans, etc., while tests check link connectivity within the system. Since the software functionality of network device A is checked during system management, the control equipment determines network device A's equipment maintenance information as "check software." Alternatively, the optical ports of network device A are periodically tested during system management; since any test operation on the optical port disconnects the link from the network device, the control equipment determines the equipment maintenance information as "disconnect link."

[0079] Based on the intent information, the control device can determine the change operations to be performed by network devices in the operation and maintenance system during the construction or maintenance of the system. For example, in the process of building a hardware system within the operation and maintenance system, the change operation performed by the network device might be establishing a connection path with newly installed network hardware. Alternatively, in the process of installing a software system within the operation and maintenance system, the change operation performed by the network device might be adjusting routing protocols. Regardless of how the control device obtains the device maintenance information, this information can be used to describe the change operations to be performed by the network device, and the content of the change operations can be described using strings. In some cases, the device maintenance information can also be called a maintenance operation list; a code example of a maintenance operation list is shown below.

[0080] In the maintenance operation list above, "operation" indicates a change operation performed on the network device, including but not limited to at least one of the following: reset, upgrade, add, remove, patch, or test. "Start-time" indicates the moment the network device begins executing the change operation, "end-time" indicates the moment the network device ends executing the change operation, and "operation-duration" indicates the duration of the change operation performed by the network device. Since the operation duration is equal to the difference between the end time and the start time, the maintenance operation list may include only the end time and the start time, or it may include the operation duration in addition to the end time and the start time, as shown in the above embodiment. Optionally, the object type of the network object in the maintenance operation list indicates which resource of the network device is subject to the change operation; examples of object types can be found in Table 1.

[0081] Table 1

[0082] In Table 1, the types correspond to object-type, and the function indicates the network function, such as BGP, VPN, etc.

[0083] After acquiring equipment maintenance information, the control device can send the equipment maintenance information to the corresponding network device. The corresponding network device includes the device to be modified as indicated by the equipment maintenance information. For example, the equipment maintenance information also includes a first device identifier of the modified device. The first device identifier can be any information capable of distinguishing different network devices, including but not limited to the Internet Protocol (IP) in the above embodiments, and can also be a device name, device identity document (ID), etc. The control device sends the equipment maintenance information to the modified device indicated by the first device identifier to control the modified device to execute the modification operation included in the equipment maintenance information, thereby realizing the construction or maintenance of the operation and maintenance system.

[0084] In some cases, the network device corresponding to the equipment maintenance information can also be an associated device related to the changed device. Associated devices can be neighboring devices or service-related network devices. In some situations, when the changed device performs a change operation, its associated devices will also be affected. Referring to Figure 5, network device C establishes connections with network devices A and B, using Ethernet as the interface technology. This Ethernet can be Flexible Ethernet (FLEXE). In Figure 5, network device C is the changed device performing the change operation, and network devices A and B are both neighbors of network device C. When network device C performs a change operation to disconnect the link, link anomalies will also occur on network devices A and B. In this case, although network device C performs the change operation based on equipment maintenance information, the change operation occurring on network device C will also cause anomalies in network devices A and B, thus triggering alarms. Since associated devices also have a probability of being affected by the change operation of the changed device, the control device can choose to send equipment maintenance information to associated devices so that when an alarm is triggered by an associated device, it can determine whether it was triggered by the change operation performed by the changed device.

[0085] Based on the scenario where the control device sends device maintenance information to the changing device and associated devices, for any network device, the received device maintenance information may include at least one of first maintenance information or second maintenance information. The first maintenance information is used to control the network device to perform a change operation, and the second maintenance information is used to control the associated devices of the network device to perform a change operation. Continuing with the example of network device C performing the change operation as shown in Figure 5, network device C receives the first maintenance information, while network devices A and B receive the second maintenance information. Regardless of whether the device maintenance information received by the network device is the first or second maintenance information, the operations performed by the network device when an alarm is triggered are similar. The following will use the network device performing the change operation as an example to illustrate the operations performed by the network device.

[0086] Optionally, if the device maintenance information received by the network device is the first maintenance information, the network device can execute the change operation indicated by the first maintenance information. For example, the network device parses the device maintenance information to determine the resource to be changed. The resource can be the entire network device, or a hardware component or software component. Hardware components include, but are not limited to, boards, daughter cards, ports, optical modules, fans, and power supplies. Software components include, for example, software, a basic input / output system (BIOS), and firmware. The network device can determine the resource to be changed through the database node path of the component-extensible markup language path (component-xpath). Database node paths include, for example, board component, optical module component, and interface name.

[0087] Furthermore, network devices can determine the change operations and maintenance periods included in the device maintenance information. Change operations indicate actions performed on resources; depending on whether the resource is a hardware or software component, change operations can include hardware or software changes. Hardware changes include removal, insertion, addition, change, shutdown, hibernation, etc., where "change" can be, for example, replacement or update. Software changes include upgrades, patches, updates, licenses, etc. Maintenance periods indicate the time when the change is performed and its duration; in some cases, maintenance periods may also be referred to as maintenance windows.

[0088] After determining the resources, change operations, and maintenance periods, network devices can further determine whether the change operations can be executed automatically. For example, if the change operation is a software or firmware upgrade, hibernation, or restart, the network device determines that it supports automatic execution of the change operation. Alternatively, if the change operation involves manual operation of hardware boards / port optical modules / fans, the network device determines that it cannot be executed automatically; manual operation includes, for example, unplugging, inserting, or replacing. If the network device determines that the change operation cannot be executed automatically and requires manual execution, it waits for the manual change and records the determined resources, change operations, and maintenance periods. If the change operation can be executed automatically, the network device can perform the change operation on the resources during the maintenance period. In one possible implementation, the network device can utilize a maintenance operation model to perform change operations based on device maintenance information. An example of a maintenance operation model is shown below.

[0089] In the above maintenance operation model, the component name indicates the resource to be modified, the operation indicates the modification operation performed on the resource, and the start time, end time, and operation duration indicate the maintenance period during which the modification operation is performed. Optionally, the maintenance operation model can be in YANG or other languages. Through the maintenance operation model, the modification operation indicated by the operation performed on the component name by the network device can be controlled during the maintenance period.

[0090] In one possible implementation, the network device can also use a resource configuration template to modify the resources based on the template, thereby enabling node expansion. Table 2 shows a configuration template provided in an embodiment of this application.

[0091] Table 2

[0092] The examples in Table 2 illustrate the optional content for each field. Taking the "operation" field as an example, this field can include at least one of the following: Device reset, Device upgrade, Add board, Remove, Patch, Device sleep, Interface down test, Virtual private network tunnel disconnected test (VPN tunnel disconnected test), and Border Gateway Protocol link down test (BGP link down test). The "operation" field can include one or more items, meaning a network device can perform one or more change operations.

[0093] Optionally, the network device can also configure a model on the device hardware components, and modify the hardware components through the model. The model code is as follows:

[0094] Regardless of the method used by network devices to perform change operations based on initial maintenance information, alarms may be triggered during operation in some cases. Alarms may be triggered by fault events; for example, after detecting a fault event, the network device can obtain alarm information describing the fault event and issue a fault alarm. Optionally, the network device can monitor the operational status of each resource and determine that the fault event is a resource anomaly when an abnormality occurs. Taking a link as an example, if the link is normally connected, the link interface will show as "up"; if the network device detects that the link interface is no longer "up", it determines that the link is faulty. Alternatively, the network device can obtain the software's operation logs and determine whether the software is malfunctioning based on the data in the logs.

[0095] The fault event can be an alarm or an incident. An incident refers to an unexpected interruption of network services, a decline in network service quality, or a suboptimal network service caused by an alarm or fault event. An incident can be a root cause alarm generated by the aggregation of multiple alarms. That is, in the embodiments of this application, the fault event refers to any abnormal situation triggered by a change in the state of a resource, including but not limited to alarms and incidents.

[0096] For example, alarms can also be triggered based on other conditions. For instance, a network device's board management status attribute may have multiple values, including test, install, running, and maintenance. Even if the board's management status attribute is not "running," such as "test," a board alarm will still be triggered. Since the alarm process for a network device is similar regardless of the triggering condition, we will use a fault event in the network device as an example to illustrate the alarm process. For alarm processes triggered by other conditions, please refer to the following embodiments, which will not be repeated here.

[0097] In one possible implementation, the network device first identifies the fault event, which includes the alarm object that triggers the alarm and the state change of the alarm object. The alarm object can be the network device as a whole or its individual components. Since network devices may perform change operations based on device maintenance information, these operations can lead to fault events. For example, plugging or unplugging a network device's board, interface optical module, or deleting an interface may trigger the failure of the board, interface optical module, or interface itself, or the failure of related services running on that board. The change operations indicated by the device maintenance information represent the intention of the operations and maintenance personnel in building or maintaining the system; such fault events are of little value to the personnel and have low severity. Alarm information for these types of fault events can be considered invalid alarms. Therefore, after identifying the fault event, it is further determined whether the fault event was triggered by a change operation. The result of this determination is used to process the alarm, thereby achieving alarm suppression through intent perception.

[0098] Optionally, alarm levels can be used to indicate whether a fault event was triggered by a change operation. The alarm level indicates the severity of the fault event and is determined based on device maintenance information and the fault event; that is, the alarm level is associated with whether the fault event was caused by a change operation. Based on the alarm level obtained during the handling of the fault event, the network device can obtain the alarm level and report alarms accordingly.

[0099] In one possible implementation, the network device can determine at least one of a fourth matching result or a fifth matching result based on device maintenance information. The fourth matching result indicates whether the maintenance period included in the device maintenance information includes the time of occurrence of the fault event, and the fifth matching result indicates whether the abnormal event caused by the change operation includes the fault event. An alarm level is then determined based on at least one of the fourth or fifth matching results. Determining the alarm level based on at least one of the fourth or fifth matching results can be achieved through several methods, including but not limited to the following.

[0100] Method 1: Obtain the fourth matching result; determine the alarm level based on the fourth matching result.

[0101] When a network device selects the fourth matching result to determine the alarm level, the network device can first obtain the fourth matching result. Since the device maintenance information includes the maintenance period, the network device can extract the maintenance period from the device maintenance information, then compare the occurrence time with the maintenance period to determine whether the occurrence time is within the maintenance period, thus obtaining the fourth matching result. Taking a maintenance period of 23:00 to 23:30 as an example, if the fault event occurs at 23:15, 23:15 is a time between 23:00 and 23:30, and the fourth matching result of the occurrence time and the maintenance period indicates that the occurrence time is within the maintenance period. Alternatively, if the fault event occurs at 22:39, 22:39 is a time before 23:00, and the fourth matching result of the occurrence time and the maintenance period indicates that the occurrence time is not within the maintenance period.

[0102] If the event occurs during a maintenance period, it indicates that the fault occurred during the execution of a change operation, and the fault event may have been triggered by the change operation. If the event does not occur during a maintenance period, it indicates that the fault did not occur during the execution of a change operation, and the fault event was not triggered by the change operation. For example, in the above embodiment, the fault event occurred at 22:39, which occurred before the network device performed the change operation; therefore, the network device's fault event was not triggered by the change operation. The fourth matching result is used to determine whether the fault event was triggered by the change operation, thereby determining the alarm level of the fault event.

[0103] If the fourth matching result indicates that the change occurred outside of a maintenance period and the fault event was not caused by the change operation, the network device determines the alarm level as Level 1. Level 1 can be set based on experience; for example, the network device obtains the correspondence between various fault events and Level 1s. This correspondence can be pre-configured by maintenance personnel, such as hardware removal corresponding to a severe Level 1, and device restart corresponding to a major Level 1. The network device queries the correspondence to determine the Level 1 corresponding to the fault event. Taking interface board removal as an example, the network device retrieves a severe Level 1.

[0104] If the fourth matching result indicates that the change occurred during a maintenance period and the fault event was caused by the change operation, the network device determines that the fault event was caused by the change operation, and the alarm level is Level 2. The Level 2 level indicates a lower fault severity than the Level 1 level. Optionally, the Level 2 can be obtained by lowering the Level 1. Continuing with the example of the fault event being an interface board being unplugged, the first level obtained from the query is "severe," and the network device lowers "severe" to obtain "major," which becomes the Level 2. For cases where the alarm level includes multiple levels, such as alarm levels divided into severe, major, and minor based on fault severity, lowering the Level 1 to obtain the Level 2 can be done by lowering it by one level or multiple levels. The number of levels lowered can be determined based on experience or the number of fault events caused by the change operation.

[0105] For example, the network device counts the first number of failure events caused by a change operation and compares this first number with a threshold value, which is determined based on experience and implementation environment settings. If the first number is greater than the threshold value, it indicates that the impact of the change operation is widespread. Although the change operation is intended to build or maintain the system, it has resulted in an excessive number of failure events in the system, requiring timely remediation. Therefore, the network device determines to lower the initial level by one level, resulting in a second level. If the first number is not greater than the threshold value, it indicates that the impact of the change operation is limited. Since the change operation is intended for maintenance or construction, it determines to lower the initial level by two levels, resulting in a second level.

[0106] Optionally, different alarm levels can be distinguished by different degrees of severity, as shown in the above embodiments, such as severe, major, and minor. Alarm levels can also be distinguished by numbers, such as level 1, level 2, and level 3. The numerical value is related to the severity of the indicated fault. The numerical value and fault severity can be positively correlated; in this case, level 2 indicates a greater fault severity than level 1. Alternatively, the numerical value can be negatively correlated with fault severity, meaning that level 2 indicates a less severe fault than level 1.

[0107] Method 2: Obtain the fifth matching result; determine the alarm level based on the fifth matching result.

[0108] For example, the network device can also determine the alarm level based on the fifth matching result using determination method two. In this case, the network device will first obtain the fifth matching result, and the network device can determine the abnormal event caused by the change operation based on the change operation in the device maintenance information, compare whether the abnormal event includes a fault event, and obtain the fifth matching result.

[0109] In one possible scenario, network devices acquire a mapping between change operations and abnormal events. This mapping indicates which change operations on the network device might trigger what kind of abnormal event. Taking a network device port as an example, changing the port's operation status from "unplugged" to "out of service" might trigger an abnormal event of the port being unplugged, and it might also trigger abnormal events for other protocols / services bound to this interface.

[0110] In one possible implementation, the network device, based on the resource indicated by the device maintenance information, identifies the components or services associated with that resource. Based on changes to the resource, it determines potential abnormal events that may occur in the components or services. Taking a link as an example, the link connects two interfaces: interface A of network device A and interface B of network device B. Interfaces A and B are the components associated with the link. Furthermore, the link is also used to transmit service packets for services A and B; therefore, the services associated with the link include services A and B. If network device A disconnects the link based on device maintenance information, interfaces A and B will experience a link connection interruption abnormal event. Moreover, in the event of a link interruption, network device A cannot transmit service packets for services A and B through the interrupted link, resulting in service failure abnormal events for services A and B.

[0111] Regardless of the method used by the network device to determine the abnormal event caused by the change operation, a fifth matching result between the abnormal event and the fault event can be determined. For example, the network device matches the abnormal event and the fault event to determine whether at least one abnormal event caused by the change operation includes a fault event, thus obtaining the fifth matching result. Taking the change operation as a change in the operating state of interface A to failure as an example, the abnormal events caused by the change operation include interface failure of interface A, service failure of service A bound to interface A, and link interruption of link A connected to interface A. The network device's fault event is interface A failure, therefore the network device determines the fifth matching result as abnormal events including fault events. Alternatively, if the network device's fault event is link B interruption, since link B is not bound to interface A, the network device determines the fifth matching result as abnormal events not including fault events.

[0112] After determining the fifth matching result, the network device can determine whether the fault event was caused by the change operation, and thus obtain the alarm level. For example, if the fifth matching result indicates that the abnormal event does not include the fault event, it is determined that the change operation did not cause the fault event; or, if the fifth matching result indicates that the abnormal event includes the fault event, it is determined that the change operation caused the fault event.

[0113] In addition to determining whether a fault event is caused by a change operation based on abnormal and fault events, network devices can also determine the root cause operation of a fault event and match the root cause operation with the change operation. For example, if a fault occurs in the network device as service A fails, and service A sends service packets based on link B connected to physical port A of the network device, the network device detects the operating status of physical port A and the link B connected to physical port A. If link B is disconnected but physical port A is normal, the root cause operation of the fault event is determined to be a link disconnection. After determining the root cause operation, the network device determines whether the root cause operation is included in the change operation, and then determines whether the fault event is caused by the change operation. If the change operation includes the root cause operation, and the root cause operation is executed based on device maintenance information, the fault event is caused by the change operation included in the device maintenance information. After determining whether the fault event is caused by the change operation, the network device can obtain the alarm level based on the determination result. The process of determining the alarm level based on whether the change operation caused the fault event is similar to the process of determining the alarm level based on the fourth matching result, and can be found in the relevant content of the above embodiments, which will not be repeated here.

[0114] Optionally, the network device can choose to use either determination method one or determination method two to determine the alarm level based on either the fourth or fifth matching result, or it can combine determination methods one and two to determine the alarm level based on both the fourth and fifth matching results. In this case, if either the fourth or fifth matching result fails to match, i.e., if the time indicated by the fourth matching result is not during a maintenance period, or if the fifth matching result indicates that the abnormal event does not include at least one of the fault events, the alarm level is determined to be level one. If both the fourth and fifth matching results match successfully, for example, if the time indicated by the fourth matching result is during a maintenance period, and the fifth matching result indicates that the abnormal event includes a fault event, the alarm level is determined to be level two.

[0115] Furthermore, network devices can choose to determine the fourth and fifth matching results synchronously or asynchronously. Asynchronous determination can involve determining the fourth matching result first, followed by the fifth, or vice versa. Regardless of whether the fourth or fifth matching result is determined first, the network device can determine whether to proceed with the next matching operation based on the first determined result. Taking the case where the fourth matching result is determined first, followed by the fifth, the network device will only proceed to determine the fifth matching result if the fourth matching result indicates that the maintenance period includes the time of occurrence. If the fourth matching result indicates that the maintenance period does not include the time of occurrence, the network device's failure event did not occur during the network device's change operation. For example, if the network device's failure event occurred before the maintenance period, and the network device had not yet started performing the change operation when the failure event occurred, then the network device's failure event was not caused by the change operation, and the network device does not need to compare the fifth matching result of the abnormal event and the failure event.

[0116] In one possible implementation, the network device may not receive device maintenance information, meaning the network device does not need to perform any changes for maintaining or building an operations and maintenance system, or the changes performed will not affect the network device. In this case, the fault events occurring on the network device are not caused by the changes and are unrelated to maintaining or building an operations and maintenance system. The network device can then set the alarm level to Level 1.

[0117] S302, the network device obtains alarm information including alarm level.

[0118] In this embodiment, the network device can directly generate alarm information after determining the alarm level. Alternatively, it can determine whether to report an alarm based on the alarm level. For example, if the alarm level is below a first threshold, alarm reporting can be suppressed; or, if the alarm level is not below the first threshold, alarm information can be generated. The first threshold can be a value set based on experience or the implementation environment. An alarm level below the first threshold indicates that the severity of the fault event is low and belongs to a tolerable fault in the maintenance or construction of the operation and maintenance system, so no reporting is required.

[0119] Optionally, alarm suppression can also be determined based on the fault event. For example, for fault events caused by a change operation, the network device suppresses alarms. If a component is removed based on a change operation, alarms for fault events of other components that depend on that component should also be suppressed. For instance, in the device interface model, port-component-references are extended to connect hardware components with interface maintenance-related intents. If the interface detects that an alarm was triggered by this device, it automatically ignores the alarm. An example code for associating an interface with a port component is shown below:

[0120] When a network device determines that it needs to obtain alarm information, it can generate alarm information describing the fault event based on the fault event. The alarm information generated by the network device will vary depending on the operations performed by the network device before obtaining the alarm information.

[0121] Scenario 1: Before obtaining alarm information, the network device performs the operation of determining the alarm level in S301, and the alarm information obtained by the network device carries the alarm level.

[0122] Optionally, in scenario one, the alarm message 1 generated by the network device, carrying the alarm level, is for example: ("dev:hardware / dev:components / dev:component[dev:name='Fan0'(XPATH),2023-03-01T02:00:10.00Z,major,Fan0 Invalid"). Here, "Fan0 Invalid" indicates a fault event, specifically an invalid component named Fan0; "2023-03-01T02:00:10.00" indicates the time of the fault event; and "major" is the alarm level. Optionally, the alarm message 2 generated by the network device can also be:

[0123] The fault event in the above alarm information is interface down named ethernet1 / 0 / 0, the time of the fault event is 2023-10-08T00:01:00, and the alarm level is minor.

[0124] Scenario 2: Before obtaining alarm information, the network device did not perform the operation of determining the alarm level in S301, and the alarm information obtained by the network device did not carry the alarm level.

[0125] In scenario two, the alarm level is subsequently determined by the monitoring equipment receiving the alarm information based on the alarm and intent information. Therefore, network devices do not need to include the alarm level in the alarm information; they can directly generate alarm information based on the occurrence of the fault event. The generated alarm information includes, but is not limited to, the fault event and the time of occurrence. In scenario two, network devices do not need to perform the S301 operation; obtaining alarm information is simple and efficient. By efficiently obtaining and reporting alarm information, the timeliness of network device alarms is improved.

[0126] Optionally, in scenario two, the network device may also include a first level in the alarm information. This first level indicates the severity of the fault event if it was not triggered by a change operation. The process of determining the first level is similar to the process of determining the alarm level as first level based on the fourth matching result in the above embodiments, and can be found in the relevant descriptions of the above embodiments, which will not be repeated here.

[0127] Optionally, the network device generates an alarm message 3 carrying the first level of error code, for example, as ("dev:hardware / dev:components / dev:component[dev:name='Fan0',2023-03-01T02:00:10.00Z,severe,Fan0Invalid"). The fault event reported by alarm message 3 is the same as that reported by alarm message 1, both indicating that the component named Fan0 is invalid. The difference lies in the level carried in the alarm message. The level in alarm message 1 is the second level, "major," obtained by lowering the first level, while the level in alarm message 2 is the first level, "severe."

[0128] In addition, alarm message 4 generated by the network device can also be:

[0129] The fault event reported in alarm message 4 is the same as that reported in alarm message 2, both indicating that the interface named ethernet1 / 0 / 0 is down. The difference is that alarm message 2 carries a second-level minor fault, while alarm message 4 carries a first-level severe fault.

[0130] S303, the network device sends alarm information to the monitoring device.

[0131] After receiving alarm information, network devices can send the alarm information to monitoring devices. Referring to Figure 4, both network devices 1 and 2 have fault events that trigger alarms. Network devices 1 and 2 respectively send alarm information to the monitoring devices to prompt the monitoring devices to process the alarm information and promptly repair the local fault events.

[0132] S304, the monitoring equipment receives alarm information sent by the network equipment.

[0133] For example, based on the communication connection with the network device, the monitoring device can receive alarm information from the network device, determine the pending events existing on the network device based on the alarm information, and process the events. This application embodiment does not limit the number of alarm messages received by the monitoring device; it can be one or more. Multiple alarm messages can be sent by one network device or multiple network devices, and the number of alarm messages sent by different network devices can be the same or different.

[0134] S305, the alarm level at which monitoring equipment obtains alarm information.

[0135] Since network devices can acquire alarm information using different methods, monitoring devices can also acquire alarm levels based on alarm information using different methods. For network devices that first determine the alarm level as shown in S301, and then execute step S302 to acquire alarm information including the alarm level, the monitoring device can directly extract the alarm level from the alarm information. Optionally, the monitoring device can also verify the alarm level after extraction.

[0136] For example, the monitoring device determines a new alarm level based on the acquired intent information and alarm information, and compares the new alarm level with the initial alarm level carried in the alarm information. If the new alarm level and the initial alarm level are the same, the initial alarm level is deemed verified, and alarm processing can be performed based on the initial alarm level. If the new alarm level and the initial alarm level are different, the initial alarm level is deemed to have failed verification, and alarm processing can be performed based on the new alarm level.

[0137] In cases where the alarm information obtained by network devices in S302 does not carry the alarm level determined based on device maintenance information, or where it is necessary to verify the alarm level determined based on device maintenance information carried in the alarm information, the monitoring device can determine the alarm level based on the intent information and the alarm information. In one possible scenario, the monitoring device may also acquire intent information. Referring to Figure 4, during the process of sending intent information to the control device, the orchestration device will also send intent information to the monitoring device, enabling the monitoring device to perceive the maintenance personnel's intention to maintain or build the system. Optionally, the intent information can also be sent from the control device to the monitoring device.

[0138] In addition, when the orchestration or control device sends intent information to the monitoring device, it can choose to send the overall intent information or the summary information. That is, the interface between the orchestration / control device and the monitoring device exchanges summary information. The summary information is used to summarize the maintenance information of each device. The summary information includes at least one of the following: device name, component name, link name, or instance name of the network device to be changed.

[0139] Since summary information can also reflect the maintenance or construction intentions of the operation and maintenance system, and the data volume of summary information is smaller than that of intention information, transmitting summary information reduces the amount of data transmitted and improves transmission efficiency. In one possible implementation, monitoring and control devices can periodically synchronize existing intention information, thereby simplifying the intention interface used by the monitoring device to obtain intention information.

[0140] After acquiring intent information, the monitoring device can determine at least one device maintenance information based on the intent information. The device maintenance information is used to describe the change operation of network devices in the operation and maintenance system. The process by which the monitoring device determines device maintenance information is similar to that of the control device. Please refer to the description in S301 regarding the control device determining device maintenance information based on intent information, which will not be repeated here.

[0141] In one possible scenario, when the control device interacts with the monitoring device, the control device can choose to send intent information to the monitoring device. For example, upon receiving intent information, the control device can immediately send it to the monitoring device. The control device can also send device maintenance information to the monitoring device. For instance, after determining the maintenance information for each device based on the intent information, the control device can send the determined maintenance information to the monitoring device. In this case, the monitoring device no longer needs to perform the operation of determining device maintenance information, simplifying its operation. Furthermore, the device maintenance information sent from the control device to the monitoring device and the device maintenance information sent from the control device to the network device can reflect the actual status of the device maintenance information received by the network device. The acquired device maintenance information can more accurately reflect the maintenance or construction operations of the operation and maintenance system, with high accuracy.

[0142] After acquiring equipment maintenance information, the monitoring equipment can determine the alarm level based on the alarm information and the equipment maintenance information. In one possible scenario, the monitoring equipment can determine whether the fault event indicated by the alarm information was triggered by a change operation based on the equipment maintenance information. This determination process can be performed based on at least one of a first matching result, a second matching result, or a third matching result. Specifically, the first matching result indicates whether the fault event occurred during the maintenance period; the second matching result indicates whether the abnormal event caused by the change operation includes the fault event; and the third matching result indicates whether the faulty device where the abnormal event occurred includes network devices. The following sections describe the process of determining whether a fault event was triggered by a change operation using different matching results.

[0143] Judgment Process 1: If the time when the first matching result occurs does not fall within a maintenance period, determine that the fault event was caused by a change operation; or, if the time when the first matching result occurs falls within a maintenance period, determine that the fault event was not caused by a change operation.

[0144] Optionally, the equipment maintenance information includes maintenance periods, and the alarm information includes the occurrence time. The monitoring equipment can extract each maintenance period from the maintenance information of each device to obtain at least one maintenance period. Furthermore, the monitoring equipment can also extract the occurrence time from the alarm information, compare the matching results of each maintenance period and the occurrence time, and if any maintenance period includes the occurrence time, determine that the first matching result indicates that the occurrence time is within a maintenance period, and the change operation caused a fault event. If at least one maintenance period does not include the occurrence time, determine that the first matching result indicates that the occurrence time is not within a maintenance period, and the change operation did not cause a fault event.

[0145] Judgment Process 2: If the second matching result indicates that the abnormal event includes a fault event, determine that the change operation caused a fault event; or, if the second matching result indicates that the abnormal event does not include a fault event, determine that the change operation did not cause a fault event.

[0146] In one possible scenario, monitoring equipment can determine the abnormal events that a change operation may trigger based on the change operation included in the equipment maintenance information. The determination process is similar to that of network equipment in determining abnormal events based on change operations; see the relevant content in S301 for details, which will not be repeated here. In some cases, the abnormal events caused by the change operation can be referred to as the fault propagation relationship of the change operation. Fault propagation relationships can be created using machine learning (ML) / artificial intelligence (AI). In this case, the monitoring equipment can obtain the fault propagation relationship created by ML / AI to obtain the abnormal events that the change operation may cause. For example, abnormal events caused by removing a single board include management alarms corresponding to daughter cards and ports / optical modules; abnormal events caused by the maintenance of node / net element (NE) devices include Interior Gateway Protocol (IGP) instance alarms, or alarms from tunnels or VPNs that rely on IGP. In some cases, based on the hierarchical relationship of the network digital map, physical layer alarms may extend to the network layer, path layer, VPN layer, etc.

[0147] The monitoring equipment identifies at least one abnormal event caused by a change operation in the maintenance information of each device. It then determines whether this abnormal event includes a fault event, obtaining a second matching result. Based on this second matching result, the monitoring equipment can then determine whether the fault event was triggered by the change operation.

[0148] In the third judgment process, if the third matching result indicates that the faulty device where the abnormal event occurred does not include the network device, it is determined that the change operation did not trigger the fault event; or, if the third matching result indicates that the faulty device includes the network device, it is determined that the change operation triggered the fault event.

[0149] Because the monitoring equipment acquires maintenance information from multiple devices, this information may or may not include maintenance details to be sent to network devices. Therefore, the monitoring equipment can determine a third-party matching result between the faulty device and the network device. Based on the faulty device that the change operation may affect, it can determine whether the network device will be affected by the change operation, and thus determine whether the change operation will trigger a fault event in the network device.

[0150] Optionally, the monitoring device can determine the faulty device that experienced the abnormal event by finding the mapping relationship between the change operation and the faulty device based on the change operation included in the equipment maintenance information. Alternatively, the monitoring device can determine the faulty device based on the resource that performed the change operation. The determined faulty device includes at least one of the change device or its associated device, where the change device is the device that performed the change operation based on the equipment maintenance information. Since the change device configures the resource to be changed, the change of the resource will affect the change device, and the change device may experience abnormal events; therefore, the change device may be a faulty device. The associated device is a device that depends on the changed resource for operation. The dependency can be a business dependency or a hardware dependency. For example, the associated device may be a neighboring device of the change device, the resource to be changed may be an interface of the change device, and a connection relationship may be established between the associated device and the interface of the change device. Since the associated device depends on the change device, the change operation on the change device may also cause a faulty event in the associated device, and the associated device may also be a faulty device.

[0151] After identifying a faulty device, the monitoring equipment compares whether the faulty device includes a network device. For example, the monitoring equipment obtains the second device identifier of each of the at least one faulty device, and compares the obtained second device identifier with the first device identifier of the network device. If there is a second device identifier that is the same as the first device identifier of the network device, it is determined that the faulty device includes a network device. If none of the at least one second device identifier includes the first device identifier, it is determined that the faulty device does not include a network device.

[0152] Optionally, the monitoring equipment can choose any one of judgment methods—method one, method two, or method three—to determine whether the fault event was caused by the change operation. It can also choose to use multiple judgment methods, such as combining method one and method two to determine whether the fault event was caused by the change operation. Similar to the process of determining whether the fault event was caused by the change operation based on the fourth and fifth matching results, in the process of using multiple judgment methods and combining multiple matching results, if any matching result, including the first, second, and third matching results, indicates a matching failure, the monitoring equipment can determine that the change operation did not trigger the fault event. Alternatively, when multiple matching results are all successful, the monitoring equipment determines that the change operation triggered the fault event.

[0153] Taking judgment method one, judgment method two, and judgment method three as examples, the monitoring device determination process includes, but is not limited to, determining that the change operation did not trigger a fault event when at least one of the following conditions is met: the first matching result indication occurred during a maintenance period, the second matching result indication did not include a fault event, or the third matching result indication did not include a network device; or, determining that the change operation triggered a fault event when the first matching result indication occurred during a maintenance period, the second matching result indication included a fault event, and the third matching result indication included a network device.

[0154] Regardless of the method used by the monitoring equipment to determine whether a change operation triggers a fault event, the alarm level can be determined as Level 2 if the change operation triggers a fault event, and as Level 1 if the change operation does not trigger a fault event. Level 2 indicates a lower fault severity than Level 1. The process for determining the alarm level as Level 1 or Level 2 is similar to the process in S301 where the network device determines the alarm level as Level 1 or Level 2; please refer to the above embodiments, and it will not be repeated here. Regarding the case in S302 where the network device carries Level 1 in the alarm information, the monitoring equipment can parse the alarm information to obtain Level 1, and reduce the Level 1 carried in the alarm message to obtain Level 2.

[0155] In one possible scenario, the alarm message sent by a network device might carry either an alarm level or a first-level warning. Since both alarm levels and first-level warnings are located in the same code but differ in their specific values, the monitoring device also needs to determine whether the alarm message carries an alarm level or a first-level warning. Optionally, the monitoring device can determine how the network device acquires the alarm message. For example, if the maintenance personnel configure the alarm handling method to send alarm levels from the network device, the monitoring device, based on this configuration, defaults to the alarm level being carried in the alarm message sent by the network device. Alternatively, the network device might also carry an acquisition identifier when sending the alarm message. This identifier indicates whether the alarm message in the network device is an alarm level or a first-level warning. The monitoring device determines whether the alarm message carries an alarm level or a first-level warning based on the acquisition identifier, allowing it to select different methods to acquire the alarm level.

[0156] S306, the monitoring equipment processes alarm information according to the alarm level.

[0157] After determining the alarm level, the monitoring equipment can repair the alarm information indicating a fault event based on the alarm level. In one possible scenario, the monitoring equipment receives multiple alarm messages. In this case, the monitoring equipment can repeat steps S304-S305 to determine the alarm level of each alarm message. Then, based on the alarm level of each alarm message, the monitoring equipment can determine the processing priority of each alarm message; and repair the events indicated by each alarm message, such as fault events, according to the processing priority.

[0158] Optionally, the alarm level can be positively correlated with the processing priority; the higher the severity of the fault indicated by the alarm level, the higher the processing priority. Taking alarm information including alarm information A, alarm information B, and alarm information C as an example, where alarm information A has a severe alarm level, alarm information B has a major alarm level, and alarm information C has a minor alarm level, then the processing priority of alarm information A is higher than that of alarm information B, and the processing priority of alarm information B is higher than that of alarm information C. In one possible implementation, the monitoring device can also determine the alarm object of the alarm information and determine the processing priority of the alarm information based on the alarm object and the alarm level.

[0159] After determining the processing priority of each alarm message, the monitoring equipment can repair the fault events reported by each alarm message according to the processing priority order. When the monitoring equipment needs to rely on other equipment or systems for fault repair, it can send alarm messages to other equipment or systems sequentially based on the processing priority of each alarm message for fault repair. Optionally, other equipment or systems can be equipment or systems used for fault analysis and repair. When fault repair requires manual operation by maintenance personnel, other equipment can also be equipment used by the maintenance personnel. Alarm messages are sent to the equipment used by the maintenance personnel to prompt them to perform fault repair. For example, as shown in Figure 4, the equipment used by the maintenance personnel includes, but is not limited to, orchestration equipment, OSS, or NOC. Based on the processing priority, the monitoring equipment first reports the fault event of network device 1 to the equipment used by the maintenance personnel, and the maintenance personnel repair the fault of network device 1. Alternatively, the monitoring equipment can parse the alarm information, determine the root cause of the fault event, and send the root cause to the equipment used by the maintenance personnel to assist them in determining a repair strategy based on the root cause and performing fault repair. Alternatively, the monitoring equipment can determine a repair strategy to address the root cause of the fault and then perform the repair according to the strategy.

[0160] In one possible implementation, the monitoring device can also select whether to process the alarm information based on the alarm level. For example, if the alarm level is below a second threshold, the alarm information is ignored; or, if the alarm level is not lower than the second threshold, the alarm information is processed. The process of determining the second threshold is similar to that of determining the first threshold, and can be found in the relevant content of determining the first threshold in S302. Optionally, the first threshold and the second threshold can be the same or different. An alarm level below the second threshold indicates that the severity of the reported fault is low, belonging to a tolerable fault in the maintenance or construction of the operation and maintenance system, and does not require processing.

[0161] For example, in addition to processing alarm information based on alarm level, monitoring equipment can also record alarm processing status, such as recording the alarm object, alarm level and alarm repair process determined based on alarm information, to obtain alarm logs, which can be provided to maintenance personnel later.

[0162] In summary, in this embodiment, the alarm level acquired by the monitoring device is determined based on intent information. Since the intent information reflects maintenance or construction intent, the alarm level is flexibly determined based on the maintenance or construction intent. Subsequently, alarm information is processed according to the alarm level, achieving more flexible and accurate alarm processing by identifying and processing alarm information based on maintenance or construction intent. Furthermore, for the same alarm information, the alarm level triggered by intent information differs from that not triggered by intent information. The process of processing alarm information based on different alarm levels also differs, enabling targeted processing through alarm level, resulting in high accuracy. Compared to the situation shown in Figure 6, where the orchestration device / OSS / NOC only sends intent information to the control device, and the monitoring device only receives alarm information and reports faults based on the alarm information, the monitoring device in this embodiment can acquire intent information. The monitoring device can understand the maintenance or construction intent without escalating to the OSS / NOC / orchestration device, thus achieving intent-based alarm processing on the monitoring device side. Furthermore, the process of determining whether an alarm is triggered by a change operation based on intent information can be performed by monitoring or network devices without manual intervention, resulting in low labor costs and high efficiency.

[0163] Figure 7 is an interactive schematic diagram of alarm processing provided in an embodiment of this application. The user in Figure 7 refers to the device used by the user, including but not limited to the orchestration device, OSS or NOC in Figure 4.

[0164] S701, monitoring devices subscribe to message queues.

[0165] In Figure 7, the interaction interface between the monitoring device and the control device is transmitted through a third-party message queue / data storage such as an open-source stream processing platform (Kafka). An interaction relationship is established between the monitoring device and the control device by subscribing to the message queue, enabling subsequent information retrieval based on the message queue. In some cases, the interaction interface between the monitoring device and the control device can also be a protocol interface such as NETCONF / RESTCONF / RESTFUL application programming interface (API).

[0166] S702, the user injects an intention into the control device.

[0167] For example, the intent injected by the user corresponds to the intent information in the embodiment shown in FIG3, which can also be referred to as user intent information as shown in FIG7.

[0168] S703, the control device returns the result response after the intent verification to the user.

[0169] In one possible scenario, the control device possesses a verification function. Upon receiving user intent information, it can verify this intent. For example, the control device analyzes the impact of changes to the operation and maintenance system based on the user intent information, obtains the analysis results, and sends these results as a response to the user. The user then decides whether to continue executing the user intent information based on the analysis results. Alternatively, after obtaining the user intent information, the control device generates a confirmation message, such as "Please confirm whether to execute," and sends this confirmation message as a response to the user. By returning a verified response, the device prevents the user's input of the intent information from being a erroneous operation.

[0170] S704, the control device sends user intent information to the message queue.

[0171] After the control device interacts with the user to confirm the user's intent information, it sends the user intent information to a message queue to transmit it to the monitoring device. Through the message queue, even if the control device and the monitoring device are decoupled, they can still smoothly exchange user intent information. Optionally, similar to the situation in S305 where the monitoring device obtains intent information, the control device can send either the entire user intent information or a summary of the user intent information; this embodiment does not limit this.

[0172] S705, the message queue pushes messages to the monitoring device.

[0173] After the control device writes user intent information, the message queue can push the user intent information to the monitoring device. For example, the message queue can periodically perform message push operations, pushing at least one user intent information accumulated within the current time period. Alternatively, the message queue can immediately push the received user intent information to the monitoring device upon receiving it.

[0174] S706 allows users to send approved device maintenance information to network devices, such as hardware and software maintenance, fan component replacement, etc.

[0175] Optionally, users can send equipment maintenance information to network devices layer by layer through orchestration and control devices. For example, the approved equipment maintenance information can be sent to the control device, which then forwards it to the network device. Users can also interact directly with the network device, for example, by sending equipment maintenance information directly to the network device.

[0176] S707: Network devices perform change operations based on equipment maintenance information and report alarms to monitoring equipment, such as optical module removal.

[0177] In one possible scenario, a change operation performed by a network device may lead to a fault event. Upon detecting this fault event, the network device can report an alarm. The alarm information is then acquired and sent to the monitoring device. The process of acquiring and sending alarm information is described in sections S301-S303 and will not be repeated here. Besides OpticalRemoved as shown in Figure 7, fault events can also include fan removal. Upon receiving the alarm information, the monitoring device, based on the fact that the alarm was triggered by a change operation, lowers the alarm level from the first level to the second level and performs alarm suppression accordingly.

[0178] The alarm processing method of this application embodiment has been described above. Corresponding to the above method, this application embodiment also provides an alarm processing device. Figure 8 is a schematic diagram of the structure of an alarm processing device provided in this application embodiment. Based on the following multiple modules shown in Figure 8, the alarm processing device shown in Figure 8 can perform all or part of the operations of the monitoring device shown in Figure 3. It should be understood that the device may include more additional modules than the modules shown or omit some of the modules shown, and this application embodiment does not limit this. As shown in Figure 8, the device includes:

[0179] The receiving module 801 is used to receive alarm information sent by network devices;

[0180] The acquisition module 802 is used to acquire the alarm level of alarm information. The alarm level is determined based on the intent information, which is used to build or maintain the operation and maintenance system where the network device is located.

[0181] The processing module 803 is used to process alarm information according to the alarm level.

[0182] In one possible implementation, the alarm information includes an alarm level, which is determined by the network device based on device maintenance information in the intent information. The device maintenance information describes the corresponding change operation of the network device.

[0183] In one possible implementation, the acquisition module 802 is further configured to acquire intent information; determine at least one device maintenance information based on the intent information, the device maintenance information being used to describe the change operation of network devices in the operation and maintenance system; and the acquisition module 802 is configured to determine an alarm level based on at least one device maintenance information and alarm information.

[0184] In one possible implementation, the acquisition module 802 is configured to determine at least one of a first matching result, a second matching result, or a third matching result based on at least one device maintenance information and alarm information. The first matching result indicates whether the occurrence time included in the alarm information is within the maintenance period included in the device maintenance information. The second matching result indicates whether the abnormal event caused by the change operation includes the fault event included in the alarm information. The third matching result indicates whether the faulty device where the abnormal event occurred includes the network device indicated by the alarm information. The alarm level is determined based on at least one of the first matching result, the second matching result, or the third matching result.

[0185] In one possible implementation, the acquisition module 802 is configured to determine the alarm level as a first level when at least one of the following conditions is met: the first matching result indicates that the occurrence time is not during a maintenance period; the second matching result indicates that the abnormal event does not include a fault event; or the third matching result indicates that the faulty device does not include a network device. Alternatively, when the first matching result indicates that the occurrence time is during a maintenance period, the second matching result indicates that the abnormal event includes a fault event, and the third matching result indicates that the faulty device includes a network device, the alarm level is determined as a second level, wherein the fault severity indicated by the second level is lower than the fault severity indicated by the first level.

[0186] In one possible implementation, the alarm information also includes a first level.

[0187] In one possible implementation, the faulty device includes at least one of a change device or an associated device, wherein the change device is a device that performs a change operation based on device maintenance information.

[0188] In one possible implementation, the intent information includes at least one of the device name, component name, link name, or instance name of the network device to be changed.

[0189] In one possible implementation, there are multiple alarm messages. The processing module 803 is used to determine the processing priority of each alarm message based on its alarm level and to repair the events triggered by each alarm message according to its processing priority.

[0190] The alarm level obtained by the above device is determined based on intent information. Since the intent information reflects the intention to maintain or build the operation and maintenance system, the alarm level is determined based on the maintenance intention or construction intention. Subsequently, the alarm information is processed according to the alarm level, so as to realize the identification and processing of alarm information according to the maintenance or construction intention of the operation and maintenance system. The processing process is more flexible and more accurate.

[0191] This application also provides another alarm processing device. Figure 9 is a schematic diagram of the structure of an alarm processing device provided in this application embodiment. Based on the following modules shown in Figure 9, the alarm processing device shown in Figure 9 can perform all or part of the operations of the network device shown in Figure 3. It should be understood that the device may include more additional modules than the modules shown or omit some of the modules shown, and this application embodiment does not limit this. As shown in Figure 9, the device includes:

[0192] The determination module 901 is used to determine the alarm level based on the device maintenance information in the intent information. The device maintenance information is used to describe the change operation corresponding to the network device, and the intent information is used to build or maintain the operation and maintenance system where the network device is located.

[0193] The acquisition module 902 is used to acquire alarm information, including alarm levels.

[0194] The sending module 903 is used to send alarm information to the monitoring equipment. The alarm information includes the alarm level for the monitoring equipment to process the alarm information.

[0195] In one possible implementation, the determining module 901 is configured to determine at least one of a fourth matching result or a fifth matching result based on the equipment maintenance information. The fourth matching result indicates whether the maintenance period included in the equipment maintenance information includes the occurrence time of the fault event that triggered the alarm, and the fifth matching result indicates whether the abnormal event caused by the change operation includes the fault event. The alarm level is determined based on at least one of the fourth matching result or the fifth matching result.

[0196] In one possible implementation, the determining module 901 is configured to determine the alarm level as a first level when the fourth matching result indication occurs outside of a maintenance period or when the fifth matching result indication abnormal event does not include a fault event; or, when the fourth matching result indication occurs outside of a maintenance period and the fifth matching result indication abnormal event includes a fault event, the alarm level is determined as a second level, wherein the fault severity indicated by the second level is lower than the fault severity indicated by the first level.

[0197] In one possible implementation, the device maintenance information includes at least one of first maintenance information or second maintenance information, wherein the first maintenance information is used to control the network device to perform a change operation, and the second maintenance information is used to control the associated device of the network device to perform a change operation.

[0198] The alarm level obtained by the above device is determined based on intent information. Since the intent information reflects the intention to maintain or build the operation and maintenance system, the alarm level is determined based on the maintenance intention or construction intention. Subsequently, the alarm information is processed according to the alarm level, so as to realize the identification and processing of alarm information according to the maintenance or construction intention of the operation and maintenance system. The processing process is more flexible and more accurate.

[0199] It should be understood that the devices provided in Figures 8 and 9 are only illustrated by the division of the functional modules described above. In practical applications, the functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. Furthermore, the devices and methods provided in the above embodiments belong to the same concept, and their specific implementation process is detailed in the method embodiments, which will not be repeated here. In addition, the alarm processing device provided in Figures 8 and 9 can be a chip or a communication device; for example, the alarm processing device can be the network device described below.

[0200] Referring to Figure 10, Figure 10 shows a schematic diagram of the structure of a network device 1000 provided in an exemplary embodiment of this application. The network device 1000 shown in Figure 10 is used to perform the operations involved in the alarm processing method shown in Figure 3 above. The network device 1000 is, for example, a switch, a router, etc., and can be implemented by a general bus architecture.

[0201] As shown in Figure 10, the network device 1000 includes at least one processor 1001, a memory 1003, and at least one communication interface 1004.

[0202] Processor 1001 may be, for example, a general-purpose central processing unit (CPU), a digital signal processor (DSP), a network processor (NP), a graphics processing unit (GPU), a neural-network processing unit (NPU), a data processing unit (DPU), a microprocessor, or one or more integrated circuits for implementing the solutions of this application. For example, processor 1001 includes application-specific integrated circuits (ASICs), programmable logic devices (PLDs), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. A PLD may be, for example, a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), generic array logic (GAL), or any combination thereof. It can implement or execute the various logic blocks, modules, and circuits described in connection with the embodiments of this application. A processor may also be a combination that implements computational functions, such as including one or more microprocessor combinations, a combination of a DSP and a microprocessor, etc.

[0203] Optionally, the network device 1000 also includes a bus. The bus is used to transmit information between the components of the network device 1000. The bus can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. The bus can be categorized as an address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used in Figure 10, but this does not indicate that there is only one bus or one type of bus.

[0204] Memory 1003 may be, for example, read-only memory (ROM) or other types of static storage devices capable of storing static information and instructions; random access memory (RAM) or other types of dynamic storage devices capable of storing information and instructions; electrically erasable programmable read-only memory (EEPROM); compact disc read-only memory (CD-ROM) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital versatile optical discs, Blu-ray discs, etc.); magnetic disk storage media or other magnetic storage devices; or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but not limited thereto. Memory 1003 may exist independently and be connected to processor 1001 via a bus. Memory 1003 may also be integrated with processor 1001.

[0205] The communication interface 1004 uses any transceiver-like device for communicating with other devices or communication networks, such as Ethernet, Radio Access Network (RAN), or Wireless Local Area Network (WLAN). The communication interface 1004 may include wired and wireless communication interfaces. Specifically, the communication interface 1004 may be an Ethernet interface, a Fast Ethernet (FE) interface, a Gigabit Ethernet (GE) interface, an Asynchronous Transfer Mode (ATM) interface, a WLAN interface, a cellular network communication interface, or a combination thereof. The Ethernet interface may be an optical interface, an electrical interface, or a combination thereof. In this embodiment, the communication interface 1004 can be used by the network device 1000 to communicate with other devices.

[0206] In a specific implementation, as one embodiment, processor 1001 may include one or more CPUs, such as CPU0 and CPU1 shown in FIG10. Each of these processors may be a single-core processor or a multi-core processor. Here, processor may refer to one or more devices, circuits, and / or processing cores for processing data (e.g., computer program instructions).

[0207] In a specific implementation, as one embodiment, network device 1000 may include multiple processors, such as processor 1001 and processor 1005 shown in FIG10. Each of these processors may be a single-core processor (single-CPU) or a multi-core processor (multi-CPU). Here, a processor may refer to one or more devices, circuits, and / or processing cores used to process data (such as computer program instructions).

[0208] In a specific implementation, as one embodiment, the network device 1000 may further include output devices and input devices. The output device communicates with the processor 1001 and can display information in various ways. For example, the output device may be a liquid crystal display (LCD), a light-emitting diode (LED) display device, a cathode ray tube (CRT) display device, or a projector, etc. The input device communicates with the processor 1001 and can receive user input in various ways. For example, the input device may be a mouse, keyboard, touchscreen device, or sensing device, etc.

[0209] In some embodiments, the memory 1003 stores program code 1010 for executing the solution of this application, and the processor 1001 can execute the program code 1010 stored in the memory 1003. That is, the network device 1000 can implement the alarm processing method provided in the method embodiment through the processor 1001 and the program code 1010 in the memory 1003. The program code 1010 may include one or more software modules. Optionally, the processor 1001 itself may also store program code or instructions for executing the solution of this application.

[0210] In a specific embodiment, the network device 1000 of this application embodiment may correspond to the computing device in the above-described method embodiments.

[0211] In the alarm processing method shown in Figure 3, each step is completed through the integrated logic circuitry of the processor in the network device 1000 or through software instructions. The steps of the method disclosed in this application can be directly implemented by the hardware processor, or by a combination of hardware and software modules within the processor. The software modules can reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. Since the storage medium is located in memory, the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method; to avoid repetition, these will not be described in detail here.

[0212] Referring to Figure 11, which shows a schematic diagram of a network device 1100 provided in another exemplary embodiment of this application, the network device 1100 shown in Figure 11 is used to perform all or part of the operations involved in the alarm processing method shown in Figure 3 above. The network device 1100 is, for example, a switch, a router, etc., and can be implemented by a general bus architecture.

[0213] As shown in Figure 11, the network device 1100 includes a main control board 1110 and an interface board 1130.

[0214] The main control board, also known as the main processing unit (MPU) or route processor card, is used to control and manage the various components in the network device 1100, including route calculation, device management, device maintenance, and protocol processing functions. The main control board 1110 includes a central processing unit 1111 and a memory 1112.

[0215] Interface board 1130 is also called a line processing unit (LPU), line card, or service board. Interface board 1130 provides various service interfaces and implements packet forwarding. Service interfaces include, but are not limited to, Ethernet interfaces, POS (Packet over SONET / SDH) interfaces, etc., with Ethernet interfaces including, for example, Flexible Ethernet Clients (FlexE Clients). Interface board 1130 includes: a central processing unit 1131, a network processor 1132, a forwarding table entry memory 1134, and a physical interface card (PIC) 1133.

[0216] The central processing unit 1131 on the interface board 1130 is used to control and manage the interface board 1130 and communicate with the central processing unit 1111 on the main control board 1110.

[0217] Network processor 1132 is used to implement packet forwarding processing. Network processor 1132 can be in the form of a forwarding chip. The forwarding chip can be a network processor (NP). In some embodiments, the forwarding chip can be implemented using an application-specific integrated circuit (ASIC) or a field-programmable gate array (FPGA). Specifically, network processor 1132 forwards received packets based on the forwarding table stored in forwarding table entry memory 1134. If the destination address of the packet is the address of network device 1100, the packet is sent to the CPU (such as central processing unit 1131) for processing; if the destination address of the packet is not the address of network device 1100, the next hop and outgoing interface corresponding to the destination address are looked up in the forwarding table according to the destination address, and the packet is forwarded to the outgoing interface corresponding to the destination address. Uplink packet processing may include: packet ingress interface processing, forwarding table lookup; downlink packet processing may include: forwarding table lookup, etc. In some embodiments, the central processing unit can also perform the functions of the forwarding chip, such as implementing software forwarding based on a general-purpose CPU, thus eliminating the need for a forwarding chip on the interface board.

[0218] The physical interface card 1133 is used to implement physical layer interfacing functions. Raw traffic enters the interface board 1130 through this card, and processed packets are sent out from the physical interface card 1133. The physical interface card 1133, also called a daughter card, can be installed on the interface board 1130. It is responsible for converting photoelectric signals into packets, performing validity checks on the packets, and forwarding them to the network processor 1132 for processing. In some embodiments, the central processing unit 1131 can also perform the functions of the network processor 1132, such as implementing software forwarding based on a general-purpose CPU, thus eliminating the need for the network processor 1132 in the physical interface card 1133.

[0219] Optionally, network device 1100 includes multiple interface boards. For example, network device 1100 also includes interface board 1140, which includes: a central processing unit 1141, a network processor 1142, a forwarding table entry memory 1144, and a physical interface card 1143. The functions and implementation methods of each component in interface board 1140 are the same as or similar to those in interface board 1130, and will not be described again here.

[0220] Optionally, network device 1100 also includes a switching fabric board 1120. The switching fabric board 1120 can also be referred to as a switch fabric unit (SFU). When network device 1100 has multiple interface boards, the switching fabric board 1120 is used to complete data exchange between the interface boards. For example, interface boards 1130 and 1140 can communicate through the switching fabric board 1120.

[0221] The main control board 1110 and the interface boards are coupled. For example, the main control board 1110, interface boards 1130 and 1140, and the switching network board 1120 are interconnected via a system bus and the system backplane. In one possible implementation, an inter-process communication (IPC) channel is established between the main control board 1110 and interface boards 1130 and 1140, and communication between the main control board 1110 and interface boards 1130 and 1140 is achieved through the IPC channel.

[0222] Logically, network device 1100 includes a control plane and a forwarding plane. The control plane includes a main control board 1110 and a central processing unit 1111, while the forwarding plane includes various components that perform forwarding, such as a forwarding table entry memory 1134, a physical interface card 1133, and a network processor 1132. The control plane performs functions such as router operation, generating forwarding tables, processing signaling and protocol messages, and configuring and maintaining the status of network devices. The control plane distributes the generated forwarding tables to the forwarding plane. In the forwarding plane, the network processor 1132 looks up and forwards messages received by the physical interface card 1133 based on the forwarding tables distributed by the control plane. The forwarding tables distributed by the control plane can be stored in the forwarding table entry memory 1134. In some embodiments, the control plane and the forwarding plane can be completely separated and not on the same network device.

[0223] It's worth noting that a network device may have one or more main control boards, including a primary and a backup main control board. It may also have one or more interface boards; the more powerful the network device's data processing capabilities, the more interface boards it provides. Each interface board may also have one or more physical interface cards. A switching board may or may not exist; multiple boards can share the load and provide redundancy. In a centralized forwarding architecture, the network device may not need a switching board, as the interface boards handle the entire system's business data processing. In a distributed forwarding architecture, the network device can have at least one switching board, which enables data exchange between multiple interface boards, providing high-capacity data exchange and processing capabilities. Therefore, the data access and processing capabilities of a distributed architecture network device are greater than those of a centralized architecture network device. Alternatively, the network device can also be a single board, without a switching board. The functions of the interface board and the main control board are integrated on this one board. In this case, the central processing unit (CPU) on the interface board and the CPU on the main control board can be combined into a single CPU to perform the combined functions. This type of network device has lower data exchange and processing capabilities (e.g., low-end switches or routers). The specific architecture adopted depends on the specific network deployment scenario, and no restrictions are imposed here.

[0224] In a specific embodiment, network device 1100 corresponds to the alarm processing apparatus shown in FIG8 or FIG9 above. In some embodiments, the processing module 803 in the alarm processing apparatus shown in FIG8 is equivalent to the central processing unit 1111 or network processor 1132 in network device 1100.

[0225] This application also provides a communication device, which includes a transceiver, a memory, and a processor. The transceiver, the memory, and the processor communicate with each other via an internal connection path. The memory stores instructions, and the processor executes the instructions stored in the memory to control the transceiver to receive and transmit signals. Furthermore, when the processor executes the instructions stored in the memory, it causes the processor to perform an alarm processing method.

[0226] It should be understood that the aforementioned processor can be a CPU, or other general-purpose processors, DSPs, ASICs, FPGAs, or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. General-purpose processors can be microprocessors or any conventional processor. It is worth noting that the processor can be a processor supporting the Advanced Reduced Instruction Set Computing (RISC) machine (ARM) architecture.

[0227] Furthermore, in an alternative embodiment, the memory described above may include read-only memory and random access memory, and provide instructions and data to the processor. The memory may also include non-volatile random access memory. For example, the memory may also store device type information.

[0228] The memory can be volatile or non-volatile, or may include both. Non-volatile memory can be ROM, programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), EEPROM, or flash memory. Volatile memory can be RAM, used as an external cache. Many forms of RAM are available by way of example, but not limitation. Examples include static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous linked dynamic random access memory (SLDRAM), and direct rambus RAM (DR RAM).

[0229] This application embodiment also provides an alarm processing device, which includes a processor for loading and executing at least one instruction to enable the alarm processing device to implement the alarm processing method shown in FIG3. Optionally, the device further includes a memory coupled to the processor for storing at least one instruction.

[0230] This application embodiment also provides an alarm processing system, which includes a network device and a monitoring device, and the network device and the monitoring device are used to interactively execute the alarm processing method shown in Figure 3.

[0231] This application also provides a computer-readable storage medium storing at least one instruction, which is loaded and executed by a processor to enable the computer to implement the alarm processing method shown in FIG3.

[0232] This application also provides a computer program (product) that, when executed by a computer, causes the processor or computer to perform the corresponding steps and / or processes in the above method embodiments.

[0233] This application also provides a chip, which includes a processor for calling and running instructions stored in a memory, causing a communication device equipped with the chip to execute the alarm processing method shown in FIG3.

[0234] This application embodiment also provides another chip, including: an input interface, an output interface, a processor, and a memory. The input interface, the output interface, the processor, and the memory are connected through an internal connection path. The processor is used to execute code in the memory. When the code is executed, the processor is used to execute the alarm processing method shown in FIG3.

[0235] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state disk).

[0236] It should be noted that all information (including but not limited to user device information, user personal information, etc.), data (including but not limited to data used for analysis, stored data, displayed data, etc.), and signals involved in this application have been authorized by the user or fully authorized by all parties, and the collection, use, and processing of related data must comply with the relevant laws, regulations, and standards of the relevant countries and regions. For example, alarm information involved in this application was obtained with full authorization.

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

[0238] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware or by a program instructing related hardware. The program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.

[0239] When implemented using software, it can be implemented wholly or partially as a computer program product. This computer program product includes one or more computer program instructions. As an example, the methods of this application embodiment can be described in the context of machine-executable instructions, such as program modules that execute on a device on a real or virtual processor of the target. Generally, program modules include routines, programs, libraries, objects, classes, components, data structures, etc., which perform specific tasks or implement specific abstract data structures. In various embodiments, the functionality of program modules can be combined or divided among the described program modules. 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 on both local and remote storage media.

[0240] Computer program code used to implement the methods of the embodiments of this application may be written in one or more programming languages. This computer program code may be provided to the processor of a general-purpose computer, a special-purpose computer, or other programmable alarm processing device, such that when executed by the computer or other programmable alarm 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 standalone software package, partially on a computer and partially on a remote computer, or entirely on a remote computer or server.

[0241] In the context of the embodiments of this application, 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, etc.

[0242] Examples of signals may include electrical, optical, radio, sound, or other forms of propagation signals, such as carrier waves, infrared signals, etc.

[0243] A machine-readable medium can be any tangible medium that contains or stores programs for or relating to an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. Machine-readable media can include, but are not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. More detailed examples of machine-readable storage media include electrical connections with one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0244] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and modules described above can be found in the corresponding processes in the foregoing method embodiments, and will not be repeated here.

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

[0246] The modules described as separate components may or may not be physically separate. Similarly, the components shown as modules may or may not be physical modules; they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of the embodiments of this application, depending on actual needs.

[0247] Furthermore, the functional modules in the various embodiments of this application can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module. The integrated modules described above can be implemented in hardware or as software functional modules.

[0248] If the integrated module is implemented as a software functional module 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 several 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 in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0249] In this application, the terms "first," "second," etc., are used to distinguish identical or similar items that have substantially the same function and purpose. It should be understood that there is no logical or temporal dependency between "first," "second," and "nth," nor does it limit the quantity or order of execution. It should also be understood that although the following description uses the terms "first," "second," etc., to describe various elements, these elements should not be limited by the terms. These terms are merely used to distinguish one element from another. For example, without departing from the various examples described, a first image can be referred to as a second image, and similarly, a second image can be referred to as a first image. Both the first image and the second image can be images, and in some cases, they can be separate and distinct images.

[0250] It should also be understood that, in the various embodiments of this application, the sequence number of each process does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0251] In this application, the term "at least one" means one or more, and the term "multiple" means two or more. For example, multiple second messages refer to two or more second messages. The terms "system" and "network" are often used interchangeably in this document.

[0252] It should be understood that the terminology used in the description of the various examples herein is for the purpose of describing particular examples only and is not intended to be limiting. As used in the description of the various examples and the appended claims, the singular forms “a” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise.

[0253] It should also be understood that the term "and / or" as used herein refers to and covers any and all possible combinations of one or more of the associated listed items. The term "and / or" describes an association between related objects, indicating that three relationships can exist; for example, A and / or B can represent: A alone, A and B simultaneously, or B alone. Additionally, the character " / " in this application generally indicates that the preceding and following related objects are in an "or" relationship.

[0254] It should also be understood that the term “comprising” (also referred to as “includes”, “including”, “comprises” and / or “comprising”) as used in this specification specifies the presence of the stated features, integers, steps, operations, elements, and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0255] It should also be understood that the terms “if” and “if” can be interpreted as meaning “when” or “upon”, or “in response to determination” or “in response to detection”. Similarly, depending on the context, the phrases “if determination…” or “if detection [the stated condition or event]” can be interpreted as meaning “when determination…”, or “in response to determination…”, or “when detection [the stated condition or event]” or “in response to detection [the stated condition or event]”.

[0256] It should be understood that determining B based on A does not mean determining B solely based on A; B can also be determined based on A and / or other information.

[0257] It should also be understood that the phrases "an embodiment," "an embodiment," and "a possible implementation" used throughout the specification mean that a specific feature, structure, or characteristic related to an embodiment or implementation is included in at least one embodiment of this application. Therefore, the phrases "in an embodiment," "an embodiment," or "a possible implementation" appearing throughout the specification do not necessarily refer to the same embodiment. Furthermore, these specific features, structures, or characteristics can be combined in any suitable manner in one or more embodiments.

Claims

1. An alarm processing method characterized by comprising: The method includes: Receive alarm information sent by network devices; The alarm level of the alarm information is obtained, and the alarm level is determined based on intent information, which is used to build or maintain the operation and maintenance system where the network device is located; The alarm information is processed according to the alarm level.

2. The method of claim 1, wherein, The alarm information includes the alarm level, which is determined by the network device based on the device maintenance information in the intent information. The device maintenance information is used to describe the change operation corresponding to the network device.

3. The method of claim 1, wherein, Before obtaining the alarm level of the alarm information, the method further includes: Obtain the intent information; At least one device maintenance information is determined based on the intent information, and the device maintenance information is used to describe the change operation of the network device in the operation and maintenance system; The alarm levels at which the alarm information is obtained include: The alarm level is determined based on the at least one device maintenance information and the alarm information.

4. The method of claim 3, wherein, Determining the alarm level based on the at least one device maintenance information and the alarm information includes: Based on the at least one device maintenance information and the alarm information, at least one of a first matching result, a second matching result, or a third matching result is determined. The first matching result indicates whether the occurrence time included in the alarm information is within the maintenance period included in the device maintenance information. The second matching result indicates whether the abnormal event caused by the change operation includes the fault event included in the alarm information. The third matching result indicates whether the faulty device where the abnormal event occurred includes the network device indicated by the alarm information. The alarm level is determined based on at least one of the first matching result, the second matching result, or the third matching result.

5. The method of claim 4, wherein, Determining the alarm level based on at least one of the first matching result, the second matching result, or the third matching result includes: If at least one of the following conditions is met: the first matching result indicates that the occurrence time is not within the maintenance period; the second matching result indicates that the abnormal event does not include the fault event; or the third matching result indicates that the faulty device does not include the network device, the alarm level is determined to be the first level. Alternatively, if the first matching result indicates that the occurrence time is within the maintenance period, the second matching result indicates that the abnormal event includes the fault event, and the third matching result indicates that the faulty device includes the network device, the alarm level is determined to be the second level, where the fault severity indicated by the second level is lower than the fault severity indicated by the first level.

6. The method of claim 5, wherein, The alarm information also includes the first level.

7. The method according to any of claims 4-6, characterized by, The faulty device includes at least one of a change device or an associated device, wherein the change device is a device that performs a change operation based on the device maintenance information.

8. The method according to any one of claims 1-7, characterized in that, The intent information includes at least one of the following: device name, component name, link name, or instance name of the network device to be changed.

9. The method according to any one of claims 1-8, characterized in that, The alarm information is multiple, and the step of processing the alarm information according to the alarm level includes: Based on the alarm level of each alarm message among multiple alarm messages, the processing priority of each alarm message is determined; Repair the events triggered by each alarm message according to the processing priority of each alarm message.

10. An alarm processing method, characterized in that, The method includes: The alarm level is determined based on the device maintenance information in the intent information. The device maintenance information is used to describe the change operation corresponding to the network device. The intent information is used to build or maintain the operation and maintenance system where the network device is located. Obtain alarm information including the alarm level; The alarm information is sent to the monitoring device, and the alarm level included in the alarm information is used by the monitoring device to process the alarm information.

11. The method according to claim 10, characterized in that, Determining the alarm level based on the device maintenance information in the intent information includes: Based on the equipment maintenance information, at least one of a fourth matching result or a fifth matching result is determined. The fourth matching result indicates whether the maintenance period included in the equipment maintenance information includes the time of occurrence of the fault event that triggered the alarm. The fifth matching result indicates whether the abnormal event caused by the change operation includes the fault event. The alarm level is determined based on at least one of the fourth matching result or the fifth matching result.

12. The method according to claim 11, characterized in that, Determining the alarm level based on at least one of the fourth matching result or the fifth matching result includes: If the fourth matching result indicates that the occurrence time is not within the maintenance period, or if the fifth matching result indicates that the abnormal event does not include at least one of the fault events, the alarm level is determined to be the first level. Alternatively, if the fourth matching result indicates that the occurrence time is within the maintenance period, and the fifth matching result indicates that the abnormal event includes the fault event, the alarm level is determined to be the second level, where the severity of the fault indicated by the second level is lower than the severity of the fault indicated by the first level.

13. The method according to any one of claims 10-12, characterized in that, The device maintenance information includes at least one of first maintenance information or second maintenance information. The first maintenance information is used to control the network device to perform change operations, and the second maintenance information is used to control the associated devices of the network device to perform change operations.

14. An alarm processing device, characterized in that, The device includes: The receiving module is used to receive alarm information sent by network devices; The acquisition module is used to acquire the alarm level of the alarm information. The alarm level is determined based on intent information, which is used to build or maintain the operation and maintenance system where the network device is located. The processing module is used to process the alarm information according to the alarm level.

15. An alarm processing device, characterized in that, The device includes: The determination module is used to determine the alarm level based on the device maintenance information in the intent information. The device maintenance information is used to describe the change operation corresponding to the network device, and the intent information is used to build or maintain the operation and maintenance system where the network device is located. The acquisition module is used to acquire alarm information including the alarm level; The sending module is used to send the alarm information to the monitoring device, and the alarm information includes an alarm level for the monitoring device to process the alarm information.

16. An alarm processing device, characterized in that, The device includes a processor coupled to a memory, the processor being configured to load and execute at least one instruction stored in the memory to enable the alarm processing device to implement the alarm processing method as described in any one of claims 1-9, or to implement the alarm processing method as described in any one of claims 10-13.

17. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores at least one instruction, which is loaded and executed by a processor to implement the alarm processing method as described in any one of claims 1-9, or to implement the alarm processing method as described in any one of claims 10-13.

18. A chip, characterized in that, The chip includes a processor for running program instructions or code that cause a device containing the chip to perform an alarm processing method as described in any one of claims 1-9, or to implement an alarm processing method as described in any one of claims 10-13.

19. A computer program product, characterized in that, The computer program product includes a computer program / instruction that is executed by a processor to cause a computer to perform the alarm processing method as described in any one of claims 1-9, or to implement the alarm processing method as described in any one of claims 10-13.

Images