Method and device for determining root cause alarm event and electronic equipment

Abstract

The invention discloses a root cause alarm event determination method and apparatus, and an electronic device. The method comprises the following steps: processing an alarm data packet to obtain a standardized alarm data packet; determining a target alarm data packet related to a preset service path in the standardized alarm data packet; calculating the comprehensive weight of the alarm event; clustering the alarm events to obtain a plurality of first alarm events, and calculating a first probability that each first alarm event belongs to a preset root cause alarm event; and determining a target probability that each first alarm event belongs to a preset root cause alarm event, and determining one or more target root cause alarm events of which the target probabilities are greater than a preset threshold in the plurality of first alarm events. According to the method and the device, the technical problem that the positioning efficiency and the positioning accuracy of the root cause alarm event are relatively low due to the fact that the positioning method of the related root cause alarm event performs analysis only based on the local alarm of the single manufacturer equipment and does not consider the weight coefficient of the equipment is solved.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of wireless communication and terminal, in particular, to a root cause alarm event determination method and device and electronic equipment. BACKGROUND

[0002] In the optical network management of the box type wavelength division system, the related alarm root cause analysis faces the following problems:

[0003] 1. Multi-vendor management barrier: the alarm data formats of different vendor devices are not unified, and it is difficult to realize cross-vendor root cause collaborative analysis.

[0004] 2. End-to-end path analysis is floating: based on local alarm of single-vendor device or only combined with static service data as the basis for association, the root cause positioning efficiency is low and the accuracy is poor.

[0005] 3. Single weight dimension: when analyzing the alarm root cause, the position of the device, the hardware quality of the device, the degradation degree and the like are not referred to, so the weight of the device itself cannot be reflected in the analysis process.

[0006] In view of the above problems, no effective solution has been proposed at present. SUMMARY

[0007] The present application provides a root cause alarm event determination method and device and electronic equipment to at least solve the technical problem of low root cause alarm event positioning efficiency and positioning accuracy caused by the positioning method of the related root cause alarm event only based on the analysis of local alarm of single-vendor device and without considering the weight coefficient of the device.

[0008] According to one aspect of the present application, a root cause alarm event determination method is provided, comprising: acquiring alarm data packets of different formats generated for a box type wavelength division system, and performing standardized processing on the alarm data packets by using a standardized data modeling model to obtain standardized alarm data packets; determining a target alarm data packet related to a preset service path in the standardized alarm data packets by using a weighted directed graph, wherein the nodes in the weighted directed graph are network elements in the box type wavelength division system, the edges are network links between the network elements, and the attributes include at least one of the following: device type and failure rate; calculating a comprehensive weight of an alarm event according to at least the device type and device performance index of the alarm event in the target alarm data packet; performing clustering processing on the alarm events to obtain a plurality of first alarm events, and calculating a first probability that each first alarm event belongs to a preset root cause alarm event; determining a target probability that each first alarm event belongs to the preset root cause alarm event according to the comprehensive weight and the first probability corresponding to each first alarm event, and determining one or more target root cause alarm events in the plurality of first alarm events whose target probability is greater than a preset threshold.

[0009] Optionally, the alarm data packet is standardized by using a standardized data modeling model to obtain a standardized alarm data packet, including: extracting a vendor identifier in the alarm data packet, determining a target entry matched with the vendor identifier in a model mapping relationship table in the standardized data modeling model, wherein the model mapping relationship table is a field path mapping rule library between the standardized data modeling model and a vendor model; marking non-standard fields in the alarm data packet based on a mapping rule of the target entry to obtain a marked intermediate standard field set, and extracting an alarm code field set from the intermediate standard field set; performing base class derivation verification on a vendor self-defined field in the alarm code field set based on a base class inheritance relationship of the target entry to output an effective alarm code set with a state marker; extracting a position field value from the intermediate standard field set based on a position rewriting rule of the target entry, performing topology compression from a physical position to a logical position and uniform format rewriting processing on the position field value to obtain a standard topology position identifier; and in a case of passing the verification on the effective alarm code set, the intermediate standard field set and the standard topology position identifier, integrating a uniform resource identifier of the effective alarm code set, a standard field of the intermediate standard field set and the standard topology position identifier to obtain the standardized alarm data packet.

[0010] Optionally, the base class derivation verification is performed on the vendor self-defined field in the alarm code field set based on the base class inheritance relationship of the target entry, including: judging whether the vendor self-defined field in the effective alarm code set inherits a standard alarm base class corresponding to the target entry; if not, adding an illegal alarm marker in the effective alarm code set; verifying the intermediate standard field set by the following method: judging whether there is a missing mandatory field in the intermediate standard field set, and if so, adding a field missing marker in the intermediate standard field set; verifying the standard topology position identifier by the following method: judging whether the standard topology position identifier conforms to a preset specification, and if not, adding a position illegal marker in the standard topology position identifier.

[0011] Optionally, in a case of passing the verification on the effective alarm code set, the intermediate standard field set and the standard topology position identifier, the uniform resource identifier of the effective alarm code set, the standard field of the intermediate standard field set and the standard topology position identifier are integrated, including: in a case that the effective alarm code set does not include the illegal alarm marker, the intermediate standard field set does not include the field missing marker and the standard topology position identifier does not include the position illegal marker, the uniform resource identifier of the effective alarm code set, the standard field of the intermediate standard field set and the standard topology position identifier are integrated.

[0012] Optionally, the target alarm data packet related to the preset service path is determined in the standardized alarm data packet by using the weighted directed graph, including: obtaining an endpoint network element sequence of the preset service path, wherein the endpoint network element sequence includes a start network element and an end network element; based on the endpoint network element sequence, a shortest path from the start network element to the end network element is extracted from the weighted directed graph, and the shortest path is determined as a connected subgraph, wherein the connected subgraph includes a node set and an edge weight set; in the case that the network element identifier in the alarm resource field in the standardized alarm data packet belongs to the node set of the connected subgraph, the alarm resource field is marked as a candidate alarm, and the network element node corresponding to the candidate alarm is associated, to obtain a plurality of candidate alarms; for each candidate alarm, the following processing is performed: based on the edge weight set of the connected subgraph, the shortest path weight from the start network element to the network element node corresponding to the candidate alarm is calculated; in the case that the shortest path weight is greater than a weight threshold of the preset service path, the candidate alarm is determined as a valid alarm; the valid alarms are aggregated to obtain the target alarm data packet.

[0013] Optionally, the alarm events are clustered to obtain a plurality of first alarm events, and a first probability that each first alarm event belongs to a preset root cause alarm event is calculated, including: adopting a density clustering algorithm to cluster alarm events in the form of a multi-dimensional feature vector to obtain a set of alarm event clusters, the alarm events at least including: an alarm location, an alarm time, an alarm type and a device type; determining a real alarm event with the earliest occurrence time in each alarm event cluster as a first alarm event, and determining a cluster characteristic parameter corresponding to the first alarm event, wherein the cluster characteristic parameter includes at least one of: a total number of alarm events in the alarm event cluster, a difference between the maximum value and the minimum value of the alarm duration in the alarm event cluster, the number of associated devices in the alarm event cluster and the proportion distribution of different alarm types in the alarm event cluster; performing feature fusion on the basic attributes of the first alarm event and the cluster characteristic parameter corresponding to the first alarm event to obtain a joint feature vector, wherein the basic attributes at least include: the alarm location, the alarm time, the alarm type and the device type; using a pre-trained Bayesian classification model to classify the joint feature vector to obtain a multi-class probability distribution, screening a target root cause category matching the preset root cause alarm event list in the multi-class probability distribution, and determining the highest probability value in the target root cause category as the first probability that the first alarm event belongs to the preset root cause alarm event.

[0014] Optionally, the method also includes: detecting changes in the business path in the weighted directed graph; when it is detected that the business path in the weighted directed graph is modified or deleted, if there is an overlapping part between the first time window and the second time window, reusing the weighted directed graph to determine the target alarm data packet related to the preset business path in the standardized alarm data packet, wherein the first start time of the first time window is the time when the business path starts to be modified or deleted, the first end time is the time when the modification or deletion ends, the second start time of the second time window is the start time of the weighted directed graph processing the standardized alarm data, and the second end time is the end time of the weighted directed graph processing the standardized alarm data.

[0015] According to another aspect of the present application, a device for determining a root cause alarm event is provided, comprising: an acquisition module for acquiring alarm data packets of different formats generated for a box-type wavelength division multiplexing system, and standardizing the alarm data packets using a standardized data modeling model to obtain a standardized alarm data packet; a first determination module for determining a target alarm data packet related to a preset service path in the standardized alarm data packet using a weighted directed graph, wherein the nodes in the weighted directed graph are network elements in the box-type wavelength division multiplexing system, the edges are network links between network elements, and the attributes include at least one of the following: device type and fault failure rate; a second determination module, used to calculate the comprehensive weight of the alarm event based on at least the device type and device performance index of the alarm event in the target alarm data packet; cluster the alarm events to obtain multiple first alarm events, and calculate the first probability that each first alarm event belongs to the preset root cause alarm event; a third determination module, used to determine the target probability that each first alarm event belongs to the preset root cause alarm event based on the comprehensive weight and the first probability corresponding to each first alarm event, and determine one or more target root cause alarm events among the multiple first alarm events whose target probability is greater than a preset threshold.

[0016] According to another aspect of the present application, a non-volatile storage medium is provided, which includes a stored program, wherein when the program is executed, the device where the storage medium is located is controlled to execute the above method for determining the root cause alarm event.

[0017] According to another aspect of the present application, an electronic device is provided, including: a memory and a processor, wherein the processor is configured to run a program stored in the memory, wherein the program executes the above method for determining a root cause alarm event when the program is running.

[0018] According to yet another aspect of the present application, a computer program is provided, wherein when the computer program is executed by a processor, the method for determining the root cause alarm event is implemented.

[0019] According to still another aspect of the present application, a computer program product is also provided, which comprises a non-volatile computer readable storage medium, wherein the non-volatile computer readable storage medium stores a computer program, which, when executed by a processor, implements the above method for determining a root cause alarm event.

[0020] In the present application, different formats of alarm data packets generated for a box wave division system are obtained, and the alarm data packets are standardized by using a standardized data modeling model to obtain standardized alarm data packets; a weighted directed graph is used to determine target alarm data packets related to a preset service path in the standardized alarm data packets, wherein the nodes in the weighted directed graph are network elements in the box wave division system, the edges are network links between the network elements, and the attributes include at least one of the following: device type and failure rate; the comprehensive weight of an alarm event is calculated at least according to the device type and device performance index of the alarm event in the target alarm data packet; the alarm events are clustered to obtain a plurality of first alarm events, and a first probability that each first alarm event belongs to a preset root cause alarm event is calculated; the target probability that each first alarm event belongs to a preset root cause alarm event is determined according to the corresponding comprehensive weight and first probability of each first alarm event, and one or more target root cause alarm events with a target probability greater than a preset threshold are determined from the plurality of first alarm events. In this way, the global alarm data of multi-vendor devices is analyzed, and the weight coefficient of the device is fully considered, so as to realize the technical effects of improving the positioning efficiency and positioning accuracy of the root cause alarm event, and further solve the technical problem of low positioning efficiency and positioning accuracy of the root cause alarm event caused by the positioning method of the related root cause alarm event which is only based on the analysis of the local alarm of single-vendor devices and does not consider the weight coefficient of the device. BRIEF DESCRIPTION OF DRAWINGS

[0021] The accompanying drawings, which are included to provide a further understanding of the present application and constitute a part of this application, illustrate certain illustrative embodiments of the present application and together with the description serve to explain the present application. In the drawings:

[0022] Figure 1 is a flowchart of a method for determining a root cause alarm event according to an embodiment of the present application;

[0023] Figure 2 is a flowchart of another method for determining a root cause alarm event according to an embodiment of the present application;

[0024] Figure 3 is a flowchart of a Bayesian alarm root cause analysis method according to an embodiment of the present application;

[0025] Figure 4is a flow chart of a graph traversal path updating method according to an embodiment of the present application;

[0026] Figure 5 is a structural diagram of a root cause alarm event determination device according to an embodiment of the present application;

[0027] Figure 6 is a hardware structural block diagram of a computer terminal of a root cause alarm event determination method according to an embodiment of the present application. DETAILED DESCRIPTION

[0028] In order to enable persons skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be described clearly and completely below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, but not all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by persons skilled in the art without creative labor should fall within the scope of protection of the present application.

[0029] It should be noted that the terms "first", "second", and the like in the specification and claims of the present application and the above-described drawings are used to distinguish similar objects, and do not necessarily indicate a specific order or a chronological sequence. It should be understood that the data thus used can be interchanged under appropriate circumstances, so that the embodiments of the present application described herein can be implemented in an order other than that illustrated or described herein. In addition, the terms "include" and "have" and any variations thereof are intended to cover non-exclusive inclusion, for example, a process, method, system, product or device that includes a series of steps or units does not necessarily have to be limited to only those steps or units clearly listed, but can include other steps or units not clearly listed or inherent to the process, method, product or device.

[0030] According to an embodiment of the present application, a method embodiment of a root cause alarm event determination method is provided. It should be noted that the steps shown in the flow chart of the drawings can be executed in a computer system such as a set of computer executable instructions, and although a logical order is shown in the flow chart, in some cases, the steps shown or described herein can be executed in an order different from that shown herein.

[0031] Figure 1 is a flow chart of a root cause alarm event determination method according to an embodiment of the present application, as Figure 1 shown, the method comprises the following steps:

[0032] Step S102, different format alarm data packets generated for the cassette wave division system are obtained, and the alarm data packets are standardized by using a standardized data modeling model to obtain standardized alarm data packets.

[0033] Among them, the box wave division system is a highly integrated optical fiber communication equipment, which is designed compactly for scenarios such as data centers, metropolitan area networks or enterprise networks that require space and resource saving. The key components of the box wave division system include:

[0034] Wavelength division multiplexer and demultiplexer: The wavelength division multiplexer combines multiple optical signals of different wavelengths into a single composite optical signal for transmission through a single optical fiber; the demultiplexer separates the composite optical signal into individual wavelength signals at the receiving end for processing by downstream equipment.

[0035] Optical amplifier: used to enhance the intensity of the transmitted optical signal to overcome the attenuation in the process of optical fiber transmission.

[0036] Electrical layer devices: These devices are responsible for processing electrical signals, including: optical modules: perform optical-electrical conversion to convert electrical signals into optical signals, or convert optical signals into electrical signals. Cross-connect devices: In some box wave division systems, small cross-connect functions may be included for signal routing and scheduling. Optical monitoring channels: used to transmit and receive system monitoring signals to monitor the operating status of the wave division system, such as optical power, signal-to-noise ratio, bit error rate, and other key parameters.

[0037] Control system and software: including network management system and control software, used for configuration, monitoring and management of wave division system.

[0038] In step S102, the alarm data packets generated in the box wave division system are processed, and the alarm data packets come from different equipment manufacturers, so their formats are different, including encoding method, field definition and data structure, which may not be consistent. In order to integrate and effectively analyze the alarm data packets, a unified standard is needed to process these data. The standardization data modeling model adopted in this application can be a data model based on YANG model, which is used to convert alarm data of different manufacturers into a unified and standardized format, i.e. standardized alarm data packet. The YANG (Yet Another Next Generation) model is a data modeling language, and the YANG model describes the structure, type and constraints of data, so that the configuration and status data of network equipment can be standardized expressed and processed.

[0039] Step S104, using a weighted directed graph, determines the target alarm data packet related to the preset service path in the standardized alarm data packet, wherein the nodes in the weighted directed graph are network elements in the box wave division system, and the edges are network links between the network elements. The attributes include at least one of the following: device type and failure rate.

[0040] Among them, the directed graph refers to the edge in the graph is directional, that is, from one vertex (or node) to another vertex, while the weighted graph refers to the edge or vertex in the graph is associated with a numerical weight. The weighted directed graph is therefore a graph structure combining directionality and weight, consisting of a set of vertices and a set of directed edges, each edge has an associated weight value. In mathematics, the weighted directed graph can be represented as a triple (G=(V,E,w)), where (V) is the set of vertices, (E) is the set of directed edges, and (w) is a weight function that maps each edge to a real value.

[0041] In step S104, the data structure of the weighted directed graph is used to analyze and filter the alarm data. In the weighted directed graph, each node represents a network element in the box wave division system, which can be an optical multiplexer, an optical amplifier, or an electrical layer device, etc., and the edge between the nodes represents the physical or logical connection between the network elements, that is, the network link. The weight in the graph is given to the node and the edge, which is used to reflect the importance of the device or the stability of the link, such as device type and failure rate are two important attributes. The setting of the device type weight is based on the role and function of the device in the network, such as optical layer devices usually carry more traffic than electrical layer devices, so their weight is higher. The failure rate is obtained by statistical analysis of historical data, which reflects the reliability of the device in a period of time.

[0042] Step S106, at least according to the device type and device performance index of the alarm event in the target alarm data packet, the comprehensive weight of the alarm event is calculated; the alarm event is clustered to obtain a plurality of first alarm events, and the first probability of each first alarm event belonging to a preset root cause alarm event is calculated.

[0043] In step S106, the comprehensive weight of each alarm event is calculated according to the device type and the real-time monitored device performance index, such as light emitting power, temperature, etc. The weight calculation process considers the importance and current health status of the device, which helps to distinguish which device problem needs more attention. The alarm events are clustered by a clustering algorithm such as density peak clustering algorithm, and the alarm events with similar characteristics are classified into a group to obtain a plurality of first alarm events. Each cluster represents a possible failure mode or root cause. After clustering is completed, the probability of each first alarm event belonging to a preset root cause alarm event, i.e. the first probability, is calculated.

[0044] Step S108, according to the comprehensive weight and the first probability corresponding to each first alarm event, the target probability of each first alarm event belonging to a preset root cause alarm event is determined, and one or more target root cause alarm events with a target probability greater than a preset threshold are determined among a plurality of first alarm events.

[0045] In step S108, each first alarm event is evaluated not only with its first probability but also with the previously calculated comprehensive weight, forming a more comprehensive evaluation system. The target probability calculation takes into account the device weight and the first probability of the alarm event, reflecting the likelihood of a particular alarm event being the root cause, given the device's importance and current conditions. Next, the target probability of each first alarm event is compared with a preset threshold. Alarm events with a target probability greater than this threshold are identified. These events are considered the most likely root causes, i.e., the target root cause alarm events.

[0046] Through the above steps S102 to S108, starting from the original multi-format alarm data packet, through standardization, filtering, weight calculation, cluster analysis and final probability determination, the root cause of the fault in the box-type wavelength division multiplexing system is accurately identified, providing strong support for network operation and maintenance personnel.

[0047] The following Figure 1 The steps shown are exemplified and explained.

[0048] According to some optional embodiments of the present application, the standardized processing of the alarm data packet using the standardized data modeling model in step S102 to obtain a standardized alarm data packet can be achieved by the following method: extracting the manufacturer identifier in the alarm data packet, determining the target entry that matches the manufacturer identifier in the model mapping relationship table in the standardized data modeling model, wherein the model mapping relationship table is a field path mapping rule library between the standardized data modeling model and the manufacturer model; based on the mapping rule of the target entry, marking the non-standard fields in the alarm data packet to obtain a marked intermediate standard field set, and extracting the alarm code field set from the intermediate standard field set; based on the target entry, Based on the inheritance relationship of the target base class, the base class derivation verification is performed on the manufacturer-defined fields in the alarm code field set, and a valid alarm code set with a status mark is output; based on the location rewriting rule of the target entry, the location field value is extracted from the intermediate standard field set, and the location field value is topologically compressed from the physical location to the logical location and rewritten in a unified format to obtain a standard topological location identifier; after verifying the valid alarm code set, the intermediate standard field set and the standard topological location identifier, the uniform resource identifier of the valid alarm code set, the standard field of the intermediate standard field set and the standard topological location identifier are integrated to obtain a standardized alarm data packet.

[0049] In the present embodiment, first, the vendor identifier is extracted from the original alarm data packet, which is used as an index key to search for the matching target entry in the preset model mapping relationship table - the entry is essentially the field conversion rule library of a specific vendor, which records the path mapping of the vendor model to the standard model, the base class inheritance relationship and the position rewriting rule. Then, the alarm data packet fields are scanned according to the mapping rules in the target entry: the fields that can be associated with the standard path retain the original values but are marked with standard field names, and the fields without mapping relationship are marked to generate an intermediate standard field set carrying both the original values and the marked state.

[0050] Subsequently, the process is divided into three channels for parallel processing: the first channel extracts the alarm code field from the intermediate set, and uses the base class inheritance relationship tree in the target entry to check the vendor-defined code - if the code is derived from the standard alarm base class, it is converted into the standard URI format, otherwise it is marked with an "illegal alarm" state, and the valid alarm code set with compliance labels is output; the second channel extracts the position field value from the intermediate set based on the position rewriting rules (such as physical port regular expression templates) in the target entry, and performs topology compression (such as "slot 3 / port 8→device NE40E") and format rewriting (such as "GigabitEthernet0 / 0 / 1→ge-0 / 0 / 1") to generate machine-readable standard topology position identifiers; the third channel performs field integrity pre-check on the intermediate set.

[0051] When and only when the valid alarm code set has no illegal mark, the intermediate standard field set is complete (including the resource / alarm-type-id / severity triple), and the standard topology position identifier meets the relevant specifications, the core outputs of the three: standardized URI code, cleaned standard field value, normalized position identifier, are combined with the original vendor identifier and reorganized to form a standardized alarm data packet containing uniform device types, alarm locations and alarm codes.

[0052] The above steps ensure that the data conversion is traceable and controllable throughout the process through three times of reuse of the target entry (field mapping→base class checking→position rewriting) and step-by-step transfer of state marks.

[0053] Further, based on the inheritance relationship of the target entry base class, the base class derivation verification is performed on the vendor-defined fields in the alarm code field set, which can be implemented by the following method: judging whether the vendor-defined fields in the valid alarm code set inherit the standard alarm base class corresponding to the target entry; if not, adding an illegal alarm marker in the valid alarm code set; the intermediate standard field set is verified by the following method: judging whether there is a missing mandatory field in the intermediate standard field set, if so, adding a field missing marker in the intermediate standard field set; the standard topology location identifier is verified by the following method: judging whether the standard topology location identifier conforms to the preset specification, if not, adding a position illegal marker in the standard topology location identifier.

[0054] Further, in the case of verifying the valid alarm code set, the intermediate standard field set and the standard topology location identifier, the uniform resource identifier of the valid alarm code set, the standard field of the intermediate standard field set and the standard topology location identifier are integrated, which can be implemented by the following method: in the case that the valid alarm code set does not include an illegal alarm marker, the intermediate standard field set does not include a field missing marker and the standard topology location identifier does not include a position illegal marker, the uniform resource identifier of the valid alarm code set, the standard field of the intermediate standard field set and the standard topology location identifier are integrated.

[0055] In the embodiment, first, for the vendor-defined fields in the alarm code field set, the standard alarm base class inheritance relationship tree stored in the target entry is queried for verification: if the field does not declare inheritance of the standard base class in the YANG model (for example, the vendor-private extension vendor-diagnostic-alarm does not derive from ietf-alarms:alarm-type), an illegal alarm marker (such as INVALID_BASE) is added in the valid alarm code set, which will block the subsequent integration process.

[0056] Secondly, the integrity verification is performed on the intermediate standard field set by checking whether the mandatory field triple (alarm type alarm-type-id, resource location resource, severity level severity) required by the relevant specification is missing. If any field is missing (such as the resource field is not parsed), a field missing marker (MISSING_FIELD) is added, which directly reflects the defect of the data structure.

[0057] Thirdly, the URI specification is verified at the syntax level and the network topology model is confirmed at the semantic level (such as whether the resource path exists in the device tree defined in RFC 8341). If any verification fails, a position illegal marker (INVALID_TOPOLOGY) is added.

[0058] Finally, only when all three output sets (valid alarm code set, intermediate standard field set, and standard topological location identifier) ​​are free of negative flags—that is, no illegal alarm flags, no missing field flags, and no illegal location flags—does the system perform data stitching. At this point, the system extracts the standard URI (e.g., urn:ietf:params:alarm:201911:link-failure) from the valid alarm code set, the cleaned standard field values ​​(e.g., severity:critical) from the intermediate set, and the normalized location identifier (e.g., urn:ietf:params:resource:node=NE40E,slot=3) and combines them with the original vendor identifier to create the final standardized alarm data packet.

[0059] In some optional embodiments of the present application, a weighted directed graph is used to determine a target alarm data packet related to a preset service path in a standardized alarm data packet, which can be achieved by the following method: obtaining an endpoint network element sequence of the preset service path, wherein the endpoint network element sequence includes a starting network element and an ending network element; based on the endpoint network element sequence, extracting the shortest path from the starting network element to the ending network element from the weighted directed graph, and determining the shortest path as a connected subgraph, wherein the connected subgraph includes a node set and an edge weight set; when the network element identifier in the alarm resource field in the standardized alarm data packet belongs to the node set of the connected subgraph, marking the alarm resource field as a candidate alarm, and associating the network element nodes corresponding to the candidate alarms to obtain multiple candidate alarms; for each candidate alarm, performing the following processing: calculating the shortest path weight from the starting network element to the network element node corresponding to the candidate alarm based on the edge weight set of the connected subgraph; when the shortest path weight is greater than the weight threshold of the preset service path, determining the candidate alarm as a valid alarm; and summarizing the valid alarms to obtain a target alarm data packet.

[0060] In this embodiment, the core path is first located using a pre-defined sequence of endpoint network elements (including the start and end network elements) of the service path. The shortest path from the start point to the end point is then extracted from a weighted directed graph as a connected subgraph, consisting of the set of nodes and edge weights along the path. This step transforms the service logic into a topological structure, ensuring that subsequent alarm detection is limited to the critical path.

[0061] When a network element identifier appears in the alarm resource field of a standardized alarm packet, the system verifies whether the identifier belongs to the node set of the connected subgraph. If so, the alarm is marked as a candidate alarm and associated with the corresponding specific network element node to form a candidate alarm set. This step uses topology attribution filtering to eliminate interference alarms unrelated to the current service path and focus on potentially valid events.

[0062] The judgment of each candidate alarm is divided into two steps: one is to calculate the accumulated weight of the shortest path from the start of the service path to the alarm network element node based on the edge weight set of the connected subgraph; the second is to compare the weight with the weight threshold of the preset service path. If the accumulated weight exceeds the threshold, the alarm is determined to be a valid alarm. This design implies the service logic: the path weight reflects the transmission cost or risk strength, and the accumulated weight exceeding the threshold indicates that the fault has had a substantial impact on the critical path.

[0063] Finally, all valid alarms are summarized to generate target alarm data packets, realizing the extraction from the original mass alarm to the core fault event of the service path. The whole process ensures that the alarm analysis is closely coupled with the physical and logical characteristics of the service path.

[0064] As some optional embodiments of the present application, the alarm events are clustered to obtain a plurality of first alarm events, and a first probability that each first alarm event belongs to a preset root cause alarm event is calculated. This can be achieved by the following method: using a density clustering algorithm to cluster alarm events in the form of a multi-dimensional feature vector to obtain an alarm event cluster set, the alarm event at least including: alarm location, alarm time, alarm type and device type; determining the earliest real alarm event in each alarm event cluster as the first alarm event, and determining the cluster feature parameters corresponding to the first alarm event, wherein the cluster feature parameters include at least one of the following: the total number of alarm events in the alarm event cluster, the difference between the maximum and minimum values of the alarm duration in the alarm event cluster, the number of associated devices in the alarm event cluster, and the proportion distribution of different alarm types in the alarm event cluster; performing feature fusion on the basic attributes of the first alarm event and the cluster feature parameters corresponding to the first alarm event to obtain a joint feature vector, wherein the basic attributes at least include: alarm location, alarm time, alarm type and device type; using a pre-trained Bayesian classification model to classify the joint feature vector to obtain a multi-category probability distribution, screening a target root cause category matching the preset root cause alarm event list in the multi-category probability distribution, and determining the highest probability value in the target root cause category as the first probability that the first alarm event belongs to the preset root cause alarm event.

[0065] In the present embodiment, first, a density clustering algorithm is used to group and cluster alarm events, each alarm event being represented by a multi-dimensional feature vector composed of alarm location, occurrence time, alarm type and device type. The alarm event cluster set generated by clustering reflects the temporal and spatial aggregation characteristics of the fault event, for example, continuous port down alarms triggered by the same device within a short period of time will be grouped into the same cluster.

[0066] In determining the key representative event, the earliest time of the real alarm in each alarm cluster is selected as the first alarm event, which is consistent with the operation and maintenance experience that the earliest event is closest to the root cause. Meanwhile, the statistical feature parameters of the alarm cluster to which the event belongs are extracted, including the total number of alarms in the cluster, the duration span from the first alarm to the last alarm, the number of affected devices, and the distribution proportion of different types of alarms. These parameters quantify the propagation range and impact strength of the fault, for example, a long-duration cluster implies a persistent fault, and a large number of device clusters indicate a wide impact.

[0067] In the feature fusion stage, the basic attributes (original location, time, type, device type) of the first alarm event are combined with the aforementioned cluster statistical parameters to form a joint feature vector. This fusion not only retains the detailed features of specific events, but also introduces group behavior statistics, for example, a CPU overload alarm (basic attribute) of a certain core switch (device type), if its alarm cluster contains 50 events (cluster total), affects 5 associated devices (associated device number), and 90% of the alarms are of the overload type (type distribution), then the joint vector can express both individual features and group patterns.

[0068] Finally, the joint feature vector is processed by a pre-trained Bayesian classification model to output a multi-class probability distribution. The model is based on a pre-set list of root cause alarm events (such as "fiber interruption", "power failure", etc. standard root cause) for matching and filtering, and the highest probability value in the matching category is taken as the final probability that the first alarm event belongs to a certain root cause. For example, the probability of a certain event to "optical module failure" is 0.92, which is much higher than that of other categories, so the value is directly output as the basis for root cause determination.

[0069] In some optional embodiments of the present application, the method for determining the root cause alarm event further comprises the following steps: detecting the change of the service path in the weighted directed graph; in the case of detecting that the service path in the weighted directed graph is modified or deleted, if there is an overlapping part between the first time window and the second time window, the weighted directed graph is used again to determine the target alarm data packet related to the pre-set service path in the standardized alarm data packet, wherein the first start time of the first time window is the time when the service path starts to modify or delete, and the first end time is the time when the modification or deletion ends, the second start time of the second time window is the start time of the weighted directed graph processing the standardized alarm data, and the second end time is the end time of the weighted directed graph processing the standardized alarm data.

[0070] In this embodiment, the response mode is entered when a modification or deletion of a service path is detected. This includes a time window of service path changes, i.e. the time from the start to the completion of the modification or deletion operation, which is referred to as the first time window, and the time span from the first start time (the time when the path starts to be modified or deleted) to the first end time (the time when the modification or deletion operation is completed); in addition, there is a time window for processing standardized alarm data, i.e. a period for analyzing standardized alarm data, which lasts from the second start time (the start time of the weighted directed graph processing standardized alarm data) to the second end time (the end time of processing alarm data).

[0071] If there is an overlapping area between the two time windows, it means that while the standardized alarm data is being analyzed, the service path of the network has changed. In order to ensure the accuracy and effectiveness of the alarm analysis, it is necessary to re-evaluate the relevance of the alarm data. Specifically, in the standardized alarm data package, based on the updated weighted directed graph model, the alarm data package related to the preset service path is re-screened. The purpose of this re-screening is to exclude those alarm information that is no longer related to the current service path, which may be invalid or outdated, to ensure that the alarm analysis focuses on the still valid network status, and to avoid analysis deviation caused by path changes.

[0072] Figure 2 is a flowchart of another method for determining a root cause alarm event according to an embodiment of the present application;

[0073] Step 1, standardized collection and processing of alarm data.

[0074] After receiving the alarm data from the device, the data is parsed and formatted using the YANG model. YANG is a modeling language specifically designed to describe network device configuration data and state data. Through the YANG model, alarm data generated by various multi-vendor devices can be uniformly processed, ensuring the format consistency of key fields such as device type, alarm location, and alarm code. Custom alarm fields that do not meet the YANG standard are filtered and discarded to avoid parsing difficulties and analysis errors caused by non-standard formats.

[0075] The generation of standardized alarm data eliminates the differences in alarm data formats between different manufacturers, providing a solid foundation for subsequent cross-vendor device alarm correlation analysis. In a complex network environment with multiple manufacturers coexisting, this standardization process greatly improves the readability and processability of alarm information, reduces the time and resources consumed due to format compatibility issues, and enables faster and more accurate fault location and problem solving.

[0076] Although the NETCONF protocol is chosen as the preferred solution for alarm data reporting and processing in this scenario, it should be noted that other standardized network management protocols such as the Simple Network Management Protocol (SNMP) or the Transmission Control Protocol (TCP) can also be considered depending on the different network environments and device types.

[0077] Step 2, Topology Modeling and Alarm Filtering.

[0078] First, the network element devices are taken as nodes in the graph model, and the links connecting these devices are taken as edges, together building a weighted directed graph. In this graph, each node and edge is assigned specific weights and attributes, such as device type and historical failure rate, which can reflect the relative importance and potential failure tendency of the device in the network. Through such modeling, the physical and logical structure of the network is intuitively presented, providing a clear reference for subsequent fault localization and resource allocation.

[0079] Then, the graph traversal algorithm is used to filter the standardized alarm data, accurately identifying which alarms are directly related to the current service path and which are irrelevant. By excluding alarms unrelated to the service path and retaining only critical alarms that directly affect the service, the complexity of alarm analysis can be significantly reduced, avoiding the interference of invalid alarms and ensuring that the focus of fault troubleshooting is accurately placed on the most important place.

[0080] In actual operation, both depth-first search and breadth-first search are effective alternatives. Depth-first search tends to explore the branches of the graph first, suitable for quickly finding specific targets or applying in smaller-scale networks; while breadth-first search prioritizes exploring all nodes at the same level of the graph, more effective for discovering all possible paths or locating the root cause in large networks. The choice of algorithm depends on the specific size and topology of the network, as well as the specific requirements of fault localization, ensuring the best balance between efficiency and accuracy.

[0081] Step 3, Device Weight Calculation.

[0082] In the specific operation, the device type is regarded as the primary weight factor. The optical layer devices, such as optical multiplexers and optical amplifiers, are given a higher weight (e.g., 2) to reflect their important role in network stability, as they undertake the key responsibilities of signal long-distance transmission and signal strengthening. In contrast, the electrical layer devices (such as TMUX) have a lower weight (e.g., 1) because they mainly process electrical signals and their influence is usually limited to their own services. Then, the performance indicators, including but not limited to the light emitting power and temperature, are considered to evaluate the health degree weight of the device. For example, when the light emitting power is lower than -7dBm, the system marks it as an out-of-limit state, and once it drops to -20dBm, it is considered as a fault state. The temperature of the device is also monitored, and exceeding 60℃ triggers a warning, and reaching 90℃ is recognized as a fault. The judgment of these states helps to calculate the average health degree of the device, and then the performance weight of the device is obtained.

[0083] The historical fault record is also an important basis for calculating the weight of the device. The current alarm situation of the device and the alarm frequency in the past month are considered to measure the fault risk weight of the device. For devices that frequently trigger emergency or major alarms, a higher fault risk weight is given, and vice versa. Through the comprehensive consideration of these parameters, the comprehensive weight value of each device can be obtained, which provides a key decision basis for subsequent fault location.

[0084] Specifically, the device weight shown in the following table can be used:

[0085]

[0086]

[0087] Preferably, the weight calculation parameters can be adjusted according to the actual network situation, such as adjusting the power threshold or alarm frequency interval.

[0088] Step 4, density peak clustering and Bayesian model analysis.

[0089] Figure 3 The flow chart of a Bayesian alarm root cause analysis method according to an embodiment of the present application is shown in FIG. 4. Figure 3 Step 4 can be realized by the following method.

[0090] Extracting alarm data in the path: Extracting each alarm data associated with all network elements involved in the current service path. These data not only include basic information of the alarm, such as alarm type, level, time and location, but also cover the details of device properties and health status.

[0091] Obtaining corresponding path data: On this basis, all data related to the service path are further collected, including but not limited to device type, performance parameters (such as light emitting power, temperature, etc.), and historical maintenance records.

[0092] According to the path data, obtain the related attributes of the network elements: combine the path data with the network element attributes to create an archive for each network element device containing its type, current performance status, and historical failure conditions.

[0093] According to the alarm location, time, device type, and other data, construct an alarm feature vector: each alarm information is converted into a feature vector containing the specific location of the alarm, the triggering time, the device type, and the related device health and failure risk, preparing for subsequent algorithm analysis.

[0094] Identify the cluster center and obtain alarm clustering based on the cluster center to form an alarm cluster set: use the density peak clustering algorithm to identify the point with the highest density in the alarm data set as the cluster center, and based on this, similar alarms are grouped into a set to form multiple alarm cluster sets.

[0095] Calculate the matrix similarity: evaluate the similarity between each alarm cluster and express the relevance between different alarm clusters through the construction of a matrix.

[0096] Determine the cutoff distance, calculate the local density, and calculate the distance: to further refine the clustering, determine a cutoff distance threshold to measure the closeness of members within an alarm cluster. Based on this distance, calculate the local density of each alarm cluster and evaluate the distance between different alarm clusters to set standards for subsequent conditional probability tables.

[0097] Define network nodes, determine node causal edges, and form a conditional probability table: treat each alarm cluster as a node in the graph, determine the connection edges between nodes by analyzing the causal relationship between alarms, and construct a conditional probability table.

[0098] Based on the obtained alarm cluster set, combine expert experience to obtain preliminary results: based on the conditional probability table, combine the knowledge and experience of industry experts to preliminarily identify possible faulty devices or components and form preliminary root cause analysis results.

[0099] Adjust according to confidence based on device weight: considering the influence of device type, historical performance, and other factors on the possibility of failure, incorporate the comprehensive weight of the device into the analysis and adjust the confidence in the preliminary results to more accurately reflect the possibility of each device as a source of failure.

[0100] Reorder alarms according to confidence and output analysis results: reorder the alarm cluster set according to the adjusted confidence to place the most likely fault root source at the forefront and form the final root cause analysis report, providing clear guidance for the maintenance team to quickly locate problems and take repair measures.

[0101] Preferably, the clustering algorithm can be replaced by K-means, etc., and the Bayesian model can be combined with machine learning algorithm optimization.

[0102] Step 5, path change processing.

[0103] Figure 4 Figure 1 is a flowchart of a graph traversal path updating method according to an embodiment of the present application, as shown in Figure 4 Step 5 can be implemented by the following method.

[0104] Add, modify, or delete path: when a change in the business path is detected, the path updating process is called.

[0105] Pause the main process: in order to avoid the impact of path change on the ongoing root cause analysis, the main analysis process is temporarily suspended. This is to ensure the accuracy and reliability of the analysis results before and after the path update, and to avoid analysis errors caused by network structure changes.

[0106] Update the graph model: in the context of path change, the weighted directed graph model maintained internally needs to be updated. This includes steps such as redrawing the network topology, including the addition, deletion, or attribute change of network element nodes, and the adjustment of link edges, to ensure that the graph model perfectly matches the real-world network architecture.

[0107] Determine: modify or delete path: evaluate the nature of the path change. If the change is a modification or deletion of an existing path, further judgment is needed to determine whether these operations are performed within the current root cause analysis period. This is because the change of the path may affect the relevance and validity of the current alarm data, and different processing measures need to be taken according to the specific situation.

[0108] If the correlation graph model is in the root cause analysis: if the path change occurs during the current root cause analysis process, the main process will be resumed and the analysis will continue based on the updated network model. This ensures the continuity and real-time nature of the analysis results, even if the network structure changes, the system can still quickly adapt and accurately locate the fault.

[0109] If not in root cause analysis: for path modification or deletion that does not immediately affect the ongoing alarm analysis, re-perform graph traversal on all alarm data within the window period to filter and re-evaluate non-path alarms. This step ensures that after the path change, alarm analysis can be based on the latest network status, avoiding the interference of invalid or outdated alarm data on the analysis results.

[0110] Determine: add path: when a new business path is added to the network, the impact of this change on existing alarm data also needs to be evaluated. If the newly added path has no direct correlation with the current alarm analysis, the main process is resumed and the existing analysis task is continued.

[0111] If not in the new path: for the new path irrelevant to the current analysis period, directly end the process to avoid unnecessary waste of computing resources. This is because the alarm impact of the new path will usually be reflected in the future analysis period, and there is no need to immediately re-evaluate the existing alarm data.

[0112] The above steps unify the multi-vendor alarm data format through the Netconf protocol and the YANG model, build a cross-vendor semantic mapping dictionary, and eliminate heterogeneous alarm semantic ambiguity. At the same time, a weighted directed graph is constructed with network elements as nodes and links as edges, and a graph traversal algorithm is combined to filter non-path alarms. In the analysis stage, the optical and electrical equipment types and quality weights are introduced, and finally the Bayesian model is used to combine expert experience and consider the equipment weights to realize end-to-end full-path multi-dimensional root cause analysis, improve the fault positioning efficiency and accuracy.

[0113] As can be seen from the above, the above steps have the following advantages.

[0114] Cross-vendor collaborative analysis: Through the Netconf protocol and the YANG model, the multi-vendor alarm data format is unified, the manufacturer barriers are broken, the alarm correlation analysis of cross-vendor devices is realized, and the troubleshooting time is shortened. For example, when the optical layer device (A manufacturer) and the electrical layer device (B manufacturer) alarms appear at the same time, the optical layer device can be quickly located as the root cause, avoiding the limitations of traditional single-vendor analysis.

[0115] End-to-end full-path analysis: Based on the weighted directed graph topology and the graph traversal algorithm, non-path alarms are filtered to ensure that the analysis is carried out around the business path, improving the efficiency of root cause positioning. Experimental data shows that compared with the traditional static path matching, this method can reduce 50% of the invalid alarm processing time.

[0116] Multi-dimensional weight accurate positioning: Combined with the device type weight (optical layer is higher than electrical layer) and the device health weight, the importance and health status of the device are quantified, so that the root cause positioning is more in line with the actual network situation. For example, when the optical layer device EDFA power is out of limit, it will be preferentially determined as the root cause due to its high weight, improving the fault positioning accuracy.

[0117] Figure 5 The structure of a root cause alarm event determination device according to an embodiment of the present application is shown in FIG. 1, which comprises: Figure 5

[0118] The acquisition module 52 is configured to acquire alarm data packets of different formats generated by the cassette wavelength division system, and perform standardized processing on the alarm data packets by using a standardized data modeling model to obtain standardized alarm data packets.

[0119] ​The first determining module 54 is configured to determine a target alarm data packet related to the preset service path from the standardized alarm data packet by using a weighted directed graph, wherein the nodes in the weighted directed graph are network elements in the box WDM system, the edges are network links between the network elements, and the attributes include at least one of the device type and the failure rate.

[0120] The second determining module 56 is configured to calculate a comprehensive weight of an alarm event according to at least the device type and the device performance index of the alarm event in the target alarm data packet, perform clustering processing on the alarm events to obtain a plurality of first alarm events, and calculate a first probability that each first alarm event belongs to a preset root cause alarm event.

[0121] The third determining module 58 is configured to determine a target probability that each first alarm event belongs to the preset root cause alarm event according to the comprehensive weight and the first probability corresponding to each first alarm event, and determine one or more target root cause alarm events with a target probability greater than a preset threshold from the plurality of first alarm events.

[0122] Optionally, the alarm data packet is standardized by using a standardized data modeling model to obtain the standardized alarm data packet, and the method includes the following steps: extracting a vendor identifier in the alarm data packet, determining a target entry matched with the vendor identifier in a model mapping relationship table in the standardized data modeling model, wherein the model mapping relationship table is a field path mapping rule library between the standardized data modeling model and a vendor model; marking a non-standard field in the alarm data packet based on a mapping rule of the target entry to obtain a set of intermediate standard fields with marks, and extracting a set of alarm code fields from the set of intermediate standard fields; performing base class derivation verification on a vendor self-defined field in the set of alarm code fields based on a base class inheritance relationship of the target entry to output a set of valid alarm codes with state marks; extracting a position field value from the set of intermediate standard fields based on a position rewriting rule of the target entry, and performing topology compression from a physical position to a logical position and uniform format rewriting processing on the position field value to obtain a standard topology position identifier; and in a case of passing the verification on the set of valid alarm codes, the set of intermediate standard fields, and the standard topology position identifier, integrating a uniform resource identifier of the set of valid alarm codes, a standard field of the set of intermediate standard fields, and the standard topology position identifier to obtain the standardized alarm data packet.

[0123] Optionally, based on the inheritance relationship of the base class of the target entry, the vendor-defined field in the alarm code field set is derived and verified, specifically including the following steps: judging whether the vendor-defined field in the valid alarm code set inherits the standard alarm base class corresponding to the target entry; if not, adding an illegal alarm mark in the valid alarm code set; verifying the intermediate standard field set by the following method: judging whether there is a missing mandatory field in the intermediate standard field set, if so, adding a field missing mark in the intermediate standard field set; verifying the standard topology location identifier by the following method: judging whether the standard topology location identifier conforms to the preset specification, if not, adding a position illegal mark in the standard topology location identifier.

[0124] Optionally, in the case of verifying the valid alarm code set, the intermediate standard field set and the standard topology location identifier, the uniform resource identifier of the valid alarm code set, the standard field of the intermediate standard field set and the standard topology location identifier are integrated, specifically including the following steps: in the case that the valid alarm code set does not include an illegal alarm mark, the intermediate standard field set does not include a field missing mark and the standard topology location identifier does not include a position illegal mark, the uniform resource identifier of the valid alarm code set, the standard field of the intermediate standard field set and the standard topology location identifier are integrated.

[0125] Optionally, using a weighted directed graph, a target alarm data packet related to a preset service path is determined in a standardized alarm data packet, specifically including the following steps: obtaining an endpoint network element sequence of the preset service path, wherein the endpoint network element sequence includes a starting network element and a terminal network element; based on the endpoint network element sequence, extracting a shortest path from the starting network element to the terminal network element from the weighted directed graph, and determining the shortest path as a connected subgraph, wherein the connected subgraph includes a node set and an edge weight set; in the case that the network element identifier in the alarm resource field in the standardized alarm data packet belongs to the node set of the connected subgraph, marking the alarm resource field as a candidate alarm and associating the corresponding network element node of the candidate alarm, to obtain a plurality of candidate alarms; for each candidate alarm, the following processing is performed: based on the edge weight set of the connected subgraph, calculating the shortest path weight from the starting network element to the network element node corresponding to the candidate alarm; in the case that the shortest path weight is greater than a weight threshold of the preset service path, determining the candidate alarm as a valid alarm; aggregating the valid alarms to obtain a target alarm data packet.

[0126] Optionally, the alarm events are clustered to obtain a plurality of first alarm events, and a first probability that each first alarm event belongs to a preset root cause alarm event is calculated, specifically including the following steps: adopting a density clustering algorithm to cluster the alarm events in the form of a multi-dimensional feature vector to obtain a set of alarm event clusters, the alarm events at least including: alarm location, alarm time, alarm type and device type; determining a real alarm event occurring earliest in time in each alarm event cluster as a first alarm event, and determining a cluster characteristic parameter corresponding to the first alarm event, wherein the cluster characteristic parameter includes at least one of: total number of alarm events in the alarm event cluster, maximum and minimum difference of alarm duration in the alarm event cluster, number of associated devices in the alarm event cluster and proportion distribution of different alarm types in the alarm event cluster; performing feature fusion on the basic attributes of the first alarm event and the cluster characteristic parameter corresponding to the first alarm event to obtain a joint feature vector, wherein the basic attributes at least include: alarm location, alarm time, alarm type and device type; classifying the joint feature vector by using a pre-trained Bayesian classification model to obtain a multi-category probability distribution, screening a target root cause category matching the preset root cause alarm event list in the multi-category probability distribution, and determining a highest probability value in the target root cause category as the first probability that the first alarm event belongs to the preset root cause alarm event.

[0127] Optionally, the root cause alarm event determination apparatus is further configured to perform the following steps: detecting a change in the service path in the weighted directed graph; in a case where it is detected that the service path in the weighted directed graph is modified or deleted, if there is an overlapping part between the first time window and the second time window, re-determining the target alarm data packet related to the preset service path in the standardized alarm data packet by using the weighted directed graph, wherein the first start time of the first time window is the time when the service path starts to be modified or deleted, the first end time is the time when the modification or deletion is ended, the second start time of the second time window is the start time of the weighted directed graph processing the standardized alarm data, and the second end time is the end time of the weighted directed graph processing the standardized alarm data.

[0128] It should be noted that the above Figure 5 Each module in the above

[0129] It should be noted that the preferred embodiments of the above Figure 5 are described in the related description of the above Figure 1 embodiments, which will not be repeated here.

[0130] Figure 6A hardware structure block diagram of a computer terminal for implementing the determination method of root cause alarm events is shown. As shown in Figure 6 The computer terminal 60 can include one or more processors 602 (the processor 602 can include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA processing device, etc.), a memory 604 for storing data, and a transmission module 606 for communication functions. In addition, it can also include a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which can be included as one of the ports of the BUS bus), a network interface, a power supply and / or a camera. Those skilled in the art can understand that Figure 6 The structure shown is only schematic, which does not limit the structure of the above-mentioned electronic device. For example, the computer terminal 60 can include more or fewer components than those shown in Figure 6 or have a different configuration than that shown in Figure 6 .

[0131] It should be noted that the one or more processors 602 and / or other data processing circuits described above can be referred to herein as "data processing circuits" in general. The data processing circuit can be embodied in whole or in part as software, hardware, firmware or any other combination. In addition, the data processing circuit can be a single independent processing module, or all or part of any one of the other elements combined into the computer terminal 60. As referred to in the embodiments of the present application, the data processing circuit is a processor control (for example, selection of a variable resistance terminal path connected to an interface).

[0132] The memory 604 can be used to store software programs and modules of application software, such as program instructions / data storage devices corresponding to the determination method of root cause alarm events in the embodiments of the present application. The processor 602 executes various functional applications and data processing by running the software programs and modules stored in the memory 604, that is, implements the above-mentioned determination method of root cause alarm events. The memory 604 can include a high-speed random access memory, and can also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some examples, the memory 604 can further include a memory remotely disposed with respect to the processor 602, which can be connected to the computer terminal 60 through a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0133] The transmission module 606 is configured to receive or send data via a network. The network can include a wireless network provided by a communication provider of the computer terminal 60. In one example, the transmission module 606 includes a network interface controller (NIC) that can be connected to other network devices through a base station to communicate with the Internet. In one example, the transmission module 606 can be a radio frequency (RF) module configured to communicate with the Internet via a wireless manner.

[0134] The display can be a liquid crystal display (LCD) that is touch screen type, for example, which can enable a user to interact with a user interface of the computer terminal 60.

[0135] It should be noted that, in some optional embodiments, the above-mentioned Figure 6 The computer terminal shown can include hardware elements (including circuitry), software elements (including computer code stored on a computer readable medium), or a combination of both hardware and software elements. It should be noted that Figure 6 is merely one example of a particular implementation and is intended to illustrate the types of components that can be present in the computer terminal described above.

[0136] It should be noted that Figure 6 The computer terminal shown is configured to perform Figure 1 The method for determining a root cause alarm event shown, and thus the related explanations in the method for executing the above-mentioned commands also apply to the electronic device, which will not be described herein again.

[0137] The embodiments of the present application also provide a non-volatile storage medium, which includes a stored program, wherein the program controls a device where the storage medium is located to perform the above-mentioned method for determining a root cause alarm event when the program is running.

[0138] The non-volatile storage medium executes a program performing the following functions: obtaining alarm data packets in different formats generated for a box-based wavelength division system, and performing standardized processing on the alarm data packets by using a standardized data modeling model to obtain standardized alarm data packets; determining target alarm data packets related to a preset service path in the standardized alarm data packets by using a weighted directed graph, wherein nodes in the weighted directed graph are network elements in the box-based wavelength division system, edges are network links between the network elements, and attributes include at least one of the following: device type and failure rate; calculating a comprehensive weight of an alarm event according to at least the device type and device performance indicators of the alarm event in the target alarm data packet; performing clustering processing on the alarm events to obtain a plurality of first alarm events, and calculating a first probability that each first alarm event belongs to a preset root cause alarm event; determining a target probability that each first alarm event belongs to the preset root cause alarm event according to the comprehensive weight and the first probability corresponding to each first alarm event, and determining one or more target root cause alarm events in the plurality of first alarm events, wherein the target probability is greater than a preset threshold.

[0139] The application also provides an electronic device, including a memory and a processor, the processor is used for running the program stored in the memory, wherein the program runs and executes the above root cause alarm event determination method.

[0140] The processor is used for running a program performing the following functions: obtaining alarm data packets in different formats generated for a box-based wavelength division system, and performing standardized processing on the alarm data packets by using a standardized data modeling model to obtain standardized alarm data packets; determining target alarm data packets related to a preset service path in the standardized alarm data packets by using a weighted directed graph, wherein nodes in the weighted directed graph are network elements in the box-based wavelength division system, edges are network links between the network elements, and attributes include at least one of the following: device type and failure rate; calculating a comprehensive weight of an alarm event according to at least the device type and device performance indicators of the alarm event in the target alarm data packet; performing clustering processing on the alarm events to obtain a plurality of first alarm events, and calculating a first probability that each first alarm event belongs to a preset root cause alarm event; determining a target probability that each first alarm event belongs to the preset root cause alarm event according to the comprehensive weight and the first probability corresponding to each first alarm event, and determining one or more target root cause alarm events in the plurality of first alarm events, wherein the target probability is greater than a preset threshold.

[0141] The above application embodiment serial numbers are only for description, and do not represent the advantages and disadvantages of the embodiments.

[0142] In the above embodiments of the application, the description of each embodiment has its own focus, and the parts not described in detail in a certain embodiment can be referred to the related description of other embodiments.

[0143] In the above embodiments of the present application, the collected information is information and data authorized by the user or fully authorized by all parties, and the collection, storage, use, processing, transmission, provision, disclosure and application of the relevant data all comply with relevant laws, regulations and standards, necessary protection measures are taken, the public order and good customs are not violated, and corresponding operation portals are provided for the user to select authorization or refusal.

[0144] In several embodiments provided in the present application, it should be understood that the disclosed technical content can be implemented by other ways. Among them, the above-described device embodiments are only schematic, for example, the division of the units can be a logical function division, and actual implementation can have another division way, for example, a plurality of units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between the units or modules shown or discussed can be indirect coupling or communication connection through some interfaces, units or modules, which can be electrical or other forms.

[0145] The units described as separate components can or can not be physically separated, and the components shown as units can or can not be physical units, that is, they can be located in one place or distributed to multiple units. Part or all of the units can be selected to achieve the purpose of the embodiment scheme according to actual needs.

[0146] In addition, each functional unit in each embodiment of the present application can be integrated in one processing unit, or each unit can exist physically, or two or more units can be integrated in one unit. The above integrated unit can be realized in the form of hardware or in the form of a software functional unit.

[0147] The integrated unit, if realized in the form of a software functional unit and sold or used as an independent product, can be stored in a computer readable storage medium. Based on such understanding, the technical solutions of the present application or the part that essentially contributes to the related art or the whole or part of the technical solutions can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes a plurality of instructions for causing a computer device (which can be a personal computer, a server or a network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The foregoing storage medium includes a U disk, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk or an optical disk and various program code storage media.

[0148] The above merely describes the preferred embodiments of the present application, and it should be pointed out that, for those skilled in the art, some improvements and refinements can be made without departing from the principles of the present application, and these improvements and refinements should also be considered as the protection scope of the present application.

Claims

1. A method for determining a root cause alarm event, characterized in that: The method comprises the following steps: acquiring different formats of alarm data packets generated by a box wave division system, and standardizing the alarm data packets by using a standardized data modeling model to obtain standardized alarm data packets; determining target alarm data packets related to a preset service path in the standardized alarm data packets by using a weighted directed graph, wherein nodes in the weighted directed graph are network elements in the box wave division system, edges are network links between the network elements, and attributes include at least one of device types and failure rates; calculating a comprehensive weight of an alarm event in the target alarm data packet according to at least a device type and a device performance index of the alarm event, clustering the alarm event to obtain a plurality of first alarm events, and calculating a first probability that each first alarm event belongs to a preset root cause alarm event; determining a target probability that each first alarm event belongs to the preset root cause alarm event according to the comprehensive weight and the first probability corresponding to each first alarm event, and determining one or more target root cause alarm events in the plurality of first alarm events, wherein the target probability is greater than a preset threshold.

2. The method of claim 1, wherein, The method for standardizing the alarm data packets by using a standardized data modeling model to obtain standardized alarm data packets comprises the following steps: extracting a vendor identifier in the alarm data packet, and determining a target entry matched with the vendor identifier in a model mapping relationship table in the standardized data modeling model, wherein the model mapping relationship table is a field path mapping rule library between the standardized data modeling model and a vendor model; based on a mapping rule of the target entry, marking non-standard fields in the alarm data packet to obtain a set of intermediate standard fields with marks, and extracting a set of alarm code fields from the set of intermediate standard fields with marks; based on a base class inheritance relationship of the target entry, performing base class derivation verification on vendor self-defined fields in the set of alarm code fields, and outputting a set of valid alarm codes with state marks; based on a position rewriting rule of the target entry, extracting a position field value from the set of intermediate standard fields, performing topology compression from a physical position to a logical position and uniform format rewriting processing on the position field value to obtain a standard topology position identifier; in a case of passing the verification on the set of valid alarm codes, the set of intermediate standard fields, and the standard topology position identifier, integrating a uniform resource identifier of the set of valid alarm codes, standard fields of the set of intermediate standard fields, and the standard topology position identifier to obtain the standardized alarm data packets.

3. The method of claim 2, wherein based on the base class inheritance relationship of the target entry, performing base class derivation verification on the vendor self-defined fields in the set of alarm code fields comprises: judging whether the vendor self-defined fields in the set of valid alarm codes inherit a standard alarm base class corresponding to the target entry; and if not, adding an illegal alarm mark in the set of valid alarm codes. The intermediate standard field set is verified by determining whether there is a missing mandatory field in the intermediate standard field set, and if so, adding a field missing mark in the intermediate standard field set; The standard topology position identifier is verified by determining whether the standard topology position identifier meets a preset specification, and if not, adding a position illegal mark in the standard topology position identifier.

4. The method of claim 3, wherein, In the case of verification of the valid alarm code set, the intermediate standard field set and the standard topology position identifier, the uniform resource identifier of the valid alarm code set, the standard field of the intermediate standard field set and the standard topology position identifier are integrated, including: In the case that the valid alarm code set does not include the illegal alarm mark, the intermediate standard field set does not include the field missing mark, and the standard topology position identifier does not include the position illegal mark, the uniform resource identifier of the valid alarm code set, the standard field of the intermediate standard field set and the standard topology position identifier are integrated.

5. The method of claim 1, wherein, Using a weighted directed graph, a target alarm data packet related to a preset service path is determined in the standardized alarm data packet, including: An endpoint network element sequence of a preset service path is obtained, wherein the endpoint network element sequence includes a starting point network element and a terminal network element; Based on the endpoint network element sequence, a shortest path from the starting point network element to the terminal network element is extracted from the weighted directed graph, and the shortest path is determined as a connected subgraph, wherein the connected subgraph includes a node set and an edge weight set; In the case that a network element identifier in an alarm resource field in the standardized alarm data packet belongs to the node set of the connected subgraph, the alarm resource field is marked as a candidate alarm, and the corresponding network element node of the candidate alarm is associated, to obtain a plurality of candidate alarms; For each candidate alarm, the following processing is performed: based on the edge weight set of the connected subgraph, the shortest path weight from the starting point network element to the corresponding network element node of the candidate alarm is calculated; in the case that the shortest path weight is greater than a weight threshold of the preset service path, the candidate alarm is determined as a valid alarm; the valid alarms are aggregated to obtain the target alarm data packet.

6. The method of claim 1, wherein, The alarm events are clustered to obtain a plurality of first alarm events, and a first probability that each first alarm event belongs to a preset root cause alarm event is calculated, including: The alarm events in the form of multi-dimensional feature vectors are clustered using a density clustering algorithm to obtain a set of alarm event clusters, wherein the alarm events at least include alarm location, alarm time, alarm type and device type; determine a first alarm event in each of the alarm event clusters as a real alarm event with the earliest occurrence time and determine a cluster characteristic parameter corresponding to the first alarm event, wherein the cluster characteristic parameter comprises at least one of the following: a total number of alarm events in the alarm event cluster, a difference between a maximum value and a minimum value of alarm duration in the alarm event cluster, a number of associated devices in the alarm event cluster, and a proportion distribution of different alarm types in the alarm event cluster; perform feature fusion on a basic attribute of the first alarm event and the cluster characteristic parameter corresponding to the first alarm event to obtain a joint feature vector, wherein the basic attribute at least comprises: an alarm location, an alarm time, an alarm type, and a device type; classify the joint feature vector by using a pre-trained Bayesian classification model to obtain a multi-class probability distribution, filter a target root cause category matching a preset root cause alarm event list in the multi-class probability distribution, and determine a highest probability value in the target root cause category as the first probability of the first alarm event belonging to the preset root cause alarm event.

7. The method of claim 1, wherein, The method further comprises: detecting a change of a service path in the weighted directed graph; in a case where it is detected that the service path in the weighted directed graph is modified or deleted, if there is an overlapping part between a first time window and a second time window, re-determining a target alarm data packet related to a preset service path in the standardized alarm data packet by using the weighted directed graph, wherein a first start time of the first time window is a time when the service path starts to be modified or deleted, a first end time is a time when the modification or deletion is ended, a second start time of the second time window is a start time of processing the standardized alarm data by the weighted directed graph, and a second end time is an end time of processing the standardized alarm data by the weighted directed graph.

8. A device for determining a root cause alarm event, characterized in that: comprise: an acquisition module configured to acquire alarm data packets in different formats generated for a box wave division system, and perform standardized processing on the alarm data packets by using a standardized data modeling model to obtain standardized alarm data packets; a first determination module configured to determine a target alarm data packet related to a preset service path in the standardized alarm data packet by using a weighted directed graph, wherein nodes in the weighted directed graph are network elements in the box wave division system, edges are network links between the network elements, and attributes comprise at least one of the following: a device type and a failure rate; a second determination module configured to calculate a comprehensive weight of an alarm event in the target alarm data packet according to at least a device type and a device performance index of the alarm event, perform clustering processing on the alarm event to obtain a plurality of first alarm events, and calculate a first probability of each of the first alarm events belonging to a preset root cause alarm event. A third determining module is configured to determine a target probability that each of the first alarm events belongs to the preset root cause alarm event according to the comprehensive weight and the first probability corresponding to each of the first alarm events, and determine one or more target root cause alarm events in which the target probability is greater than a preset threshold value.

9. A non-volatile storage medium, characterized in that: The non-volatile storage medium includes a stored program, wherein the non-volatile storage medium controls the device in which the non-volatile storage medium is located to execute the root cause alarm event determination method of any one of claims 1 to 7 when the program is running.

10. An electronic device, comprising: Comprise: A memory and a processor, wherein the processor is configured to run a program stored in the memory, and the program is configured to execute the root cause alarm event determination method of any one of claims 1 to 7 when the program is running.

11. A computer program product comprising a computer program, characterized in that, The computer program is executed by the processor to implement the root cause alarm event determination method of any one of claims 1 to 7.

Images