Knowledge graph-based data center network topology root cause fault location system

Abstract

The application relates to the technical field of network operation and maintenance, and discloses a data center network topology root cause fault positioning system based on a knowledge graph, which comprises processing units such as endpoint state acquisition, alarm correlation, graph maintenance, candidate generation, sorting processing and result output; in a unified time window, according to a port adjacency mapping relationship, the running states of a local port, the running states of a counterport and the detection states of a local received signal are collected in groups, the ports and links are written into a basic knowledge graph, ordered endpoint relationships and ordered double-end received fracture criteria of the ports are generated, candidate root cause objects are generated based on event clusters, and root cause positioning results are output according to effective port aggregation values and basic root cause sorting scores; when the states are missing, the time windows are inconsistent or the mapping is invalid, the basic sorting is returned, and the system is suitable for data center network alarm analysis and work order disposal.

Description

Technical Field

[0001] This invention belongs to the field of network operation and maintenance technology, specifically relating to a knowledge graph-based root cause fault location system for data center network topology. Background Technology

[0002] Large-scale data center networks typically consist of switching equipment, servers, firewalls, load balancers, and virtualized resources that carry services. The operations and maintenance platform generally connects to configuration management databases, device configurations, neighbor discovery tables, SNMP, NETCONF, RESTAPI, Syslog, log platforms, and monitoring platforms. It continuously aggregates asset, topology, metrics, alarms, and change records, and writes the relationships between devices, ports, links, services, and alarms into a graph library for alarm convergence, impact analysis, and root cause localization.

[0003] In a standard root cause analysis process, the system typically first aggregates alarms by time window, then generates candidate root cause objects based on information such as topological adjacency, service dependency, alarm level, alarm duration, impact range, maintenance window, and known changes, and calculates ranking scores for the candidate root cause objects. This process facilitates integration with existing monitoring platforms and ticketing systems, and also makes it easier for operations and maintenance personnel to trace evidence along device, port, link, and service paths.

[0004] When a link-related failure occurs, devices at both ends of the link, adjacent ports, and affected services may generate alarms simultaneously within a short period of time. If the system primarily sorts alarms based on alarm level, topological distance, and impact range, the local port, peer port, link, and adjacent devices may obtain similar sorting results. Maintenance personnel still need to manually verify these results by combining port status, neighbor discovery records, and received signal status. The localization process is easily affected by data collection delays, expired neighbor discovery records, and missing status information.

[0005] Therefore, without adding new dedicated detection equipment or changing the access method of the existing monitoring platform, the operation and maintenance system needs to further utilize the local port operation status, remote port operation status, and local received signal detection status that can be obtained from the device management interface, and associate them with ports, links, services, and alarms in the knowledge graph, so that the candidate root cause ranking can absorb endpoint direction evidence; at the same time, when the status is unavailable, the time window is inconsistent, or the port adjacency mapping relationship fails, the system should still retain the existing ranking output in order to be compatible with the existing fault handling process. Summary of the Invention

[0006] The present invention aims to provide a knowledge graph-based data center network topology root cause fault location system, which solves the technical problems mentioned in the background art.

[0007] To achieve the above-mentioned objectives, the present invention provides the following technical solution.

[0008] The knowledge graph-based data center network topology root cause fault location system includes an endpoint parameter acquisition module, an event association module, a knowledge graph construction module, a candidate root cause generation module, a structural feature sorting module, and a location result output module. The basic knowledge graph includes device, port, physical link, and service dependency relationships. The endpoint parameter acquisition module is used to collect three endpoint states of the local physical port and the peer physical port, which are both capable of receiving signals, within a unified time window, based on the port adjacency mapping relationship determined by topology data or neighbor discovery data and within the validity period. The three endpoint states include the local port running status, the peer port running status, and the local receiving signal detection status. The event association module is used to generate event clusters according to a unified time window; The knowledge graph construction module is used to generate an ordered endpoint structure in the basic knowledge graph and generate port-ordered double-ended receiving fracture structure features based on three endpoint states. The candidate root cause generation module is used to generate candidate root cause objects based on event clusters and basic knowledge graphs; The structural feature sorting module is used to obtain the basic root cause sorting score based on the alarm evidence and topological association information of the candidate root cause object. When all three endpoint states exist, belong to the same time window, and the port adjacency mapping relationship is valid, the module summarizes the port ordered double-end reception fracture structure features to obtain the effective port feature summary value associated with the candidate object and sorts it in priority over the basic root cause sorting score. When the port ordered double-end reception fracture structure features are invalid or missing, the module reverts to sorting in the basic root cause sorting score. The root cause localization results output module is used to output the root cause localization results.

[0009] Compared with the prior art, the present invention has the following substantial features and significant progress: This invention relies on the existing monitoring platform, device management interface, neighbor discovery results, and knowledge graph library of the data center to process the local port operation status, the peer port operation status, and the local received signal detection status in groups within a unified time window. It also links with event clusters and candidate root cause objects, enabling the root cause ranking to obtain endpoint direction evidence when devices at both ends of the link alarm simultaneously. By limiting scenarios with missing status, inconsistent time windows, or invalid port adjacency mapping relationships through validity flags, the system can revert to the basic root cause ranking score, reducing misranking caused by incomplete data. This process does not require additional sensors or dedicated testing equipment, making it easy to integrate into existing operation and maintenance platforms, and ensuring that the output results carry a verifiable chain of evidence. Attached Figure Description

[0010] Figure 1 This is a diagram of the system architecture and positioning processing mechanism of the present invention. Detailed Implementation

[0011] The following description is provided in conjunction with the accompanying drawings. It should be understood that the following embodiments are for illustrative purposes only and are not intended to limit the invention; those skilled in the art can make equivalent substitutions or combinations for the specific implementations.

[0012] This implementation method is applicable to data center network operation and maintenance scenarios, especially suitable for complex operating environments formed by servers, switches, firewalls, load balancers, physical ports, physical links, and service dependencies. The system processes data that has already been generated or can be directly provided by the configuration management database, neighbor discovery data source, device management interface, and monitoring and alarm platform, without changing the forwarding protocol, optical module structure, physical port arrangement, fiber optic connection method, or chassis hardware structure of the network devices.

[0013] like Figure 1 As shown, the system in this embodiment includes a data source layer 100, a static topology acquisition module 200, an endpoint parameter acquisition module 300, an event association module 400, a knowledge graph construction module 500, a candidate root cause generation module 600, a structural feature ranking module 700, a consistency verification module 800, and a location result output module 900. The endpoint parameter acquisition module, event association module, knowledge graph construction module, candidate root cause generation module, structural feature ranking module, and location result output module correspond to [specific components in this embodiment]. Figure 1 The module includes an endpoint parameter acquisition module 300, an event association module 400, a knowledge graph construction module 500, a candidate root cause generation module 600, a structural feature sorting module 700, and a localization result output module 900.

[0014] The data source layer 100 is used to represent the set of data sources accessed by the system. The configuration management database 110 provides static data such as devices, ports, physical links, and service dependencies; the neighbor discovery data source 120 provides neighbor discovery data that can determine the port adjacency mapping relationship 210; the device management interface 130 provides port status data; and the monitoring and alarm platform 140 provides alarm records.

[0015] The basic knowledge graph 510 includes device, port, physical link, and service dependencies. For ease of use... Figure 1 Corresponding to each item in this implementation, the basic knowledge graph 510 may also include device entity 511, port entity 512, physical link entity 513, service entity 514, alarm entity 515, and service dependency relationship 516.

[0016] This implementation establishes a fault location and processing link around a unified time window 340. The unified time window 340 is used to ensure that the three endpoint states 330 correspond to the alarm records in time. Within the unified time window 340, the endpoint parameter acquisition module 300, based on the port adjacency mapping relationship 210, collects the three endpoint states 330 of the local physical port 310 and the peer physical port 320, both of which have the ability to receive signals. The three endpoint states 330 include the local port operating state 331, the peer port operating state 332, and the local received signal detection state 333.

[0017] The knowledge graph construction module 500 generates an ordered endpoint structure 520 in the basic knowledge graph 510, and generates a port ordered double-ended reception fracture structure feature 530 and a validity flag 540 based on three endpoint states 330. The candidate root cause generation module 600 generates candidate root cause objects 610 based on event clusters 410 and the basic knowledge graph 510. The structural feature sorting module 700 sorts the candidate root cause objects 610 based on the summary value of valid port features associated with the candidate objects 710 and the basic root cause sorting score 720, and reverts to sorting based on the basic root cause sorting score 720 through the backsliding sorting path 730 when the port ordered double-ended reception fracture structure feature 530 is invalid or missing.

[0018] The technical problem this embodiment aims to solve is that when devices at both ends of a physical link, adjacent ports, the physical link itself, and the affected service all generate alarms within a similar timeframe, the basic root cause ranking score 720, obtained solely based on alarm severity, topology distance, and impact coverage, may not reliably distinguish which physical endpoint the fault evidence is closer to. This embodiment, through an ordered endpoint structure 520 and a port ordered dual-end reception breakage structure feature 530, enables the ranking of candidate root cause objects 610 to utilize endpoint direction evidence. Simultaneously, a validity flag 540 restricts misuse caused by missing states, inconsistent time windows, and invalid port adjacency mapping relationships 210.

[0019] The data source layer 100 includes at least a configuration management database 110, a neighbor discovery data source 120, a device management interface 130, and a monitoring and alarm platform 140.

[0020] In one implementation, the configuration management database 110 records the device identifier, device name, device type, management address, device role, port identifier, port name, physical link identifier, and service dependency of devices within the data center. The neighbor discovery data source 120 can be an LLDP neighbor table, device neighbor discovery results, or adjacency records derived from an existing topology system. Its function is to provide the port adjacency mapping relationship 210 between the local physical port 310 and the peer physical port 320.

[0021] The static topology acquisition module 200 collects topology data and neighbor discovery data from the configuration management database 110 and the neighbor discovery data source 120. The static topology acquisition module 200 outputs a port adjacency mapping relationship 210 and provides this relationship to the endpoint parameter acquisition module 300 and the knowledge graph construction module 500. The port adjacency mapping relationship 210 records the correspondence between the local physical port 310 and the peer physical port 320, enabling the system to determine the peer physical port 320 corresponding to the local physical port 310.

[0022] The validity of port adjacency mapping relationship 210 can be jointly limited by the data source time, the neighbor discovery refresh time, and the preset validity period. This preset validity period is only used to determine whether the port adjacency mapping relationship 210 is still valid; it does not change the physical link entity 513 itself, nor does it change the working method of the neighbor discovery protocol. When the port adjacency mapping relationship 210 exceeds the preset validity period, the knowledge graph construction module 500 sets the validity flag 540 to invalid, causing the structural feature sorting module 700 to not use the valid port feature summary value 710 associated with the candidate object as the first sorting key.

[0023] In one implementation, the unified time window 340 adopts a fixed unified time window length configured by the system. The fixed unified time window length can be configured to be 30 seconds, 60 seconds, or 300 seconds according to the refresh capability of the monitoring alarm platform 140 and the device management interface 130. When the existing monitoring platform has already output the start and end times according to the event cluster 410, the unified time window 340 can also be obtained by extending the earliest alarm occurrence time of the event cluster 410 forward by one collection cycle and extending the latest alarm occurrence time backward by one collection cycle. For the fixed unified time window length, the system adopts an attribution rule of closed start boundary and open end boundary, so that any state record belongs to only one unified time window 340.

[0024] The preset validity period is used to determine whether the port adjacency mapping relationship 210 is within its validity period. The preset validity period can be determined by the neighbor discovery refresh cycle or the topology acquisition cycle of the static topology acquisition module 200, and is set to be no less than one neighbor discovery refresh cycle and no more than three neighbor discovery refresh cycles; when the system only configures the topology acquisition cycle, the preset validity period is set to be no less than one topology acquisition cycle and no more than three topology acquisition cycles. If the time difference between the last successful acquisition time of the port adjacency mapping relationship 210 and the start time of the unified time window 340 exceeds the preset validity period, the knowledge graph construction module 500 sets the validity flag 540 to invalid.

[0025] The static topology acquisition module 200 can read devices, ports, physical links, and service dependencies according to a preset acquisition cycle. For records from the configuration management database 110 and the neighbor discovery data source 120, the static topology acquisition module 200 can merge them using device identifiers and port identifiers.

[0026] When the static topology acquisition module 200 finds that the port name formats from different data sources are inconsistent, it can retain the original port names and unify the device names, port names, time formats, status enumerations and alarm levels in the subsequent data standardization module.

[0027] The endpoint parameter acquisition module 300 is used to collect, within a unified time window 340, three endpoint states 330 of the local physical port 310 and the peer physical port 320, both of which have the ability to receive signals, based on the port adjacency mapping relationship 210 determined by topology data or neighbor discovery data and within its validity period. This group acquisition requires that the local port operating state 331, the peer port operating state 332, and the local received signal detection state 333 correspond to the same unified time window 340 to avoid incorrect combination of states across time windows.

[0028] Both the local physical port 310 and the remote physical port 320 are physical optical ports. The local physical port 310 represents the physical optical port that serves as the local end from the current computing perspective, while the remote physical port 320 represents the other physical optical port determined by the port adjacency mapping relationship 210. For the same physical link entity 513, the system can use one physical optical port as the local physical port 310 in one computing perspective and another physical optical port as the local physical port 310 in another computing perspective.

[0029] The local port operating status 331 indicates the operating status of the local physical port 310. The endpoint parameter acquisition module 300 can read the local port operating status 331 through the device management interface 130. The device management interface 130 can be one or more of the following: an existing SNMP interface, a NETCONF interface, a RESTAPI interface, a device read-only command interface, or a device telemetry interface. These interfaces are all common interfaces used in data center operation and maintenance systems for reading port operating status; this implementation only uses these interfaces to read existing status data.

[0030] The peer port running status 332 indicates the running status of the peer physical port 320. The endpoint parameter acquisition module 300 identifies the peer physical port 320 through LLDP neighbor relationships and reads the peer port running status 332 through the peer device management interface. The peer device management interface can be a read-only interface of the same type as the device management interface 130, or it can be read by the monitoring platform. Regardless of the reading method, the peer port running status 332 corresponds to the peer physical port 320 determined by the port adjacency mapping relationship 210.

[0031] The local received signal detection status 333 indicates whether the local physical port 310 has detected a received signal. The endpoint parameter acquisition module 300 reads the local received signal detection status 333 through the optical module digital diagnostic interface. This optical module digital diagnostic interface can read the inverse meaning or equivalent fields of the receivesignaldetect field and the LOS field. If the device interface directly returns whether a received signal is detected, the endpoint parameter acquisition module 300 generates the local received signal detection status 333 according to this field; if the device interface returns the LOS field, the endpoint parameter acquisition module 300 converts the LOS state (indicating no received signal detected) to the local received signal detection status 333.

[0032] The endpoint parameter acquisition module 300 is also used to save the local physical port identifier, the peer physical port identifier, and the unified time window identifier. Saving the local physical port identifier is used to locate the local physical port 310 in the basic knowledge graph 510, saving the peer physical port identifier is used to locate the peer physical port 320 in the basic knowledge graph 510, and saving the unified time window identifier is used to prove that the three endpoint states 330 belong to the same unified time window 340.

[0033] The endpoint parameter acquisition module 300 records the three endpoint states 330 as binary state values. The local port operating state 331 is recorded as 1 when it is online and 0 when it is offline. The remote port operating state 332 is recorded as 1 when it is online and 0 when it is offline. The local received signal detection state 333 is recorded as 1 when a received signal is detected and 0 when no received signal is detected.

[0034] For ease of subsequent calculations, this implementation defines the symbol corresponding to the local port operating state 331. Define the symbol corresponding to the operating state 332 of the peer port. Define the symbol corresponding to the local received signal detection state 333. .in, The value is derived from the device management interface 130 of the local physical port 310. The value is derived from the peer device management interface on the peer physical port 320. The value is derived from the optical module digital diagnostic interface of the physical port 310 on this end.

[0035] When the unified time window 340 begins, the endpoint parameter acquisition module 300 first checks whether the port adjacency mapping relationship 210 is valid. If the port adjacency mapping relationship 210 is valid, the endpoint parameter acquisition module 300 then reads the local port operating status 331, the peer port operating status 332, and the local received signal detection status 333. If the port adjacency mapping relationship 210 is not valid, the endpoint parameter acquisition module 300 can still retain the existing acquisition records, but the knowledge graph construction module 500 will not set the port ordered dual-end reception breakage structure feature 530 as a valid feature that can participate in sorting.

[0036] When the endpoint parameter acquisition module 300 reads the local port operating status 331, the peer port operating status 332, and the local received signal detection status 333 within a unified time window 340, it uses the end boundary of the unified time window 340 as the latest return time for this group acquisition. If any interface does not return a resolvable status before this latest return time, or if the acquisition time of the returned status does not belong to the same unified time window 340, the data standardization module retains a missing flag. The endpoint parameter acquisition module 300 can perform one original read and one retry read on the same interface within the unified time window 340; if the retry read still fails, it will not fill in the value with the old status.

[0037] When the device management interface 130, the peer device management interface, or the optical module digital diagnostic interface returns an unrecognizable state, communication timeout, authentication failure, missing field, or missing timestamp, the endpoint parameter acquisition module 300 marks the corresponding local port operating state 331, peer port operating state 332, or local received signal detection state 333 as unavailable. This unavailable state enters the data standardization module to form a missing flag, which is then used by the knowledge graph construction module 500 to set the validity flag 540 to invalid.

[0038] In one implementation, the system further includes a data standardization module. Located between the static topology acquisition module 200, the endpoint parameter acquisition module 300, the event association module 400, and the knowledge graph construction module 500, the data standardization module is used to unify device names, port names, time formats, status enumerations, and alarm levels. This module ensures that the three endpoint states 330, alarm records, and object references in the basic knowledge graph 510 can match each other.

[0039] The data standardization module first unifies the device names, mapping the device names in the configuration management database 110, the neighbor discovery data source 120, the device names returned by the device management interface 130, and the device names in the monitoring and alarm platform 140 to the same device identifier. Subsequently, the data standardization module unifies the port names, mapping port names returned by different manufacturers or different interfaces to the same port identifier.

[0040] The data standardization module unifies the time format and converts the three endpoint states 330 and alarm records to a unified time base. The unified time window 340 can be a fixed-length time window, a sliding time window, or a time window derived from the event occurrence time. Regardless of the time window implementation method used, the unified time window 340 is used to determine whether the local port operating status 331, the remote port operating status 332, the local received signal detection status 333, and the alarm records can be used together in the same event analysis process.

[0041] The data standardization module unifies the state enumeration. For the local port operating state 331 and the remote port operating state 332, the device may return up, down, testing, unknown, administratively down, or other vendor-specific states. The data standardization module only maps values ​​that clearly indicate an online state to 1 and values ​​that clearly indicate an offline state to 0; for values ​​that cannot be determined as online or offline...

[0042] The data standardization module unifies alarm levels. The monitoring alarm platform 140 may express alarm levels in terms of emergency, severe, major, minor, or alert, or it may express alarm levels numerically. The data standardization module converts alarm levels into structural feature ranking modules 700, which can be used to calculate the alarm severity input based on the root cause ranking score 720.

[0043] The data standardization module performs deduplication and time alignment based on object identifiers, event types, and unified time window identifiers. Object identifiers determine which of the following objects—device entity 511, port entity 512, physical link entity 513, or service entity 514—an alarm record or status record belongs to. Event types distinguish between port offline, link anomaly, service unavailability, device alarms, and other existing alarm types. Unified time window identifiers limit the range of status combinations during the analysis of the same event.

[0044] When any of the three endpoint states 330 is unavailable, the data standardization module retains a missing flag. This missing flag is entered into the knowledge graph construction module 500 along with the three endpoint states 330. When the knowledge graph construction module 500 detects a missing state in the local port operation state 331, the remote port operation state 332, or the local received signal detection state 333, it sets the validity flag 540 to invalid. This process prevents the structural feature ranking module 700 from improving the ranking of a candidate root cause object 610 based on incomplete data.

[0045] The event association module 400 generates event clusters 410 according to a unified time window 340. An event cluster 410 represents a set of associated alarm objects within the same unified time window 340. The monitoring and alarm platform 140 provides alarm records to the event association module 400, and the unified time window 340 provides time alignment criteria to the event association module 400. The processing results of the event association module 400 are provided to the knowledge graph construction module 500 and the candidate root cause generation module 600.

[0046] The event association module 400 can aggregate duplicate alarms according to object, alarm type, and unified time window 340. For the same alarm that occurs repeatedly within the same unified time window 340 for the same device entity 511, port entity 512, physical link entity 513, or service entity 514, the event association module 400 will group them into one alarm evidence in the same event cluster 410.

[0047] The event association module 400 can also establish associations for alarms occurring on the same device or adjacent topology objects within the same unified time window 340. For example, if a service entity 514 experiences a service unavailability alarm, a port entity 512 experiences a port offline alarm, and a physical link entity 513 experiences a link abnormality alarm, and all of the above alarms fall within the same unified time window 340, then the event association module 400 will include these alarms in the same event cluster 410, so that the candidate root cause generation module 600 can generate candidate root cause objects 610 along the basic knowledge graph 510.

[0048] The event association module 400 can pair recovery events with corresponding occurrence events, and can also suppress alarms for objects in maintenance status. This pairing and suppression processing is a standard event handling method in existing operation and maintenance platforms, used to reduce the impact of recovered alarms or alarms within the maintenance window on root cause localization.

[0049] After the event association module 400 generates the event cluster 410, the event cluster 410 may contain a set of alarm objects, a set of alarm types, alarm occurrence time, alarm recovery time, and a unified time window identifier. This information is used by the subsequent consistency verification module 800 to determine whether the top-ranked candidate root cause object 610 contains abnormal evidence within the unified time window 340, and whether the alarm time is earlier than or no later than the downstream alarm.

[0050] To enable event cluster 410 to directly participate in subsequent graph processing, event cluster 410 must retain at least the object identifier, object type, alarm type, alarm level, alarm occurrence time, and unified time window identifier. The object identifier is used to establish a correspondence with the device entity 511, port entity 512, physical link entity 513, service entity 514, or alarm entity 515 in the basic knowledge graph 510; the unified time window identifier is used to verify time consistency with the three endpoint states 330 and the ordered endpoint structure 520.

[0051] The knowledge graph construction module 500 is used to generate an ordered endpoint structure 520 in the basic knowledge graph 510, and to generate a port ordered double-ended reception breakage structure feature 530 based on three endpoint states 330. The knowledge graph construction module 500 is also used to retain the device entity 511, port entity 512, physical link entity 513, service entity 514, and alarm entity 515 and their relationships in the basic knowledge graph 510, and to add the ordered endpoint structure 520, the port ordered double-ended reception breakage structure feature 530, and the validity flag 540 to the physical link relationship.

[0052] The basic knowledge graph 510 can be composed of nodes and relationships. Device entity 511 represents device objects such as switches, servers, firewalls, or load balancers; port entity 512 represents physical port objects on the device; physical link entity 513 represents physical link objects connecting two port entities 512; service entity 514 represents service objects that depend on device entity 511, port entity 512, or physical link entity 513 to run; alarm entity 515 represents alarm objects provided by the monitoring and alarm platform 140; and service dependency relationship 516 represents the dependency relationship between service entity 514 and device entity 511, port entity 512, or physical link entity 513.

[0053] The ordered endpoint structure 520 is used to express the ordered relationship between the local physical port 310, the physical link entity 513, and the peer physical port 320. For the same physical link entity 513, if the first physical optical port is used as the local physical port 310 and the second physical optical port is used as the peer physical port 320, an ordered endpoint structure 520 is generated; if the second physical optical port is used as the local physical port 310 and the first physical optical port is used as the peer physical port 320, another ordered endpoint structure 520 can be generated.

[0054] The knowledge graph construction module 500 can implement the ordered endpoint structure 520 as an intermediate node in the basic knowledge graph 510, or as a set of directed attributes on physical link relationships. Both of these methods belong to conventional graph data representation methods. Regardless of the implementation method, the ordered endpoint structure 520 is associated with at least the local physical port identifier, the peer physical port identifier, the physical link identifier, the unified time window identifier, the local port running status 331, the peer port running status 332, the local received signal detection status 333, the status code, the port ordered dual-end reception breakage structure feature 530, and the validity flag 540.

[0055] The knowledge graph construction module 500 calculates state codes based on three endpoint states 330. The state codes correspond to the following symbols. This is used to form a storable and comparable three-bit status code from the local port operating status 331, the remote port operating status 332, and the local received signal detection status 333. The status code is calculated using the following formula:

[0056] In the above formula, Indicates the status code. This indicates that the local port is in operating status 331. This indicates that the peer port is in operating status 332. This indicates that the local receiving signal detection status is 333. When the local port operation status 331 is online... When offline When the peer port's operating status 332 is online. When offline When the local receiving signal detection status 333 indicates that a received signal has been detected. When no received signal is detected .

[0057] The state coding calculation assigns a definite value to each combination of the three endpoint states 330. Since the state coding is determined only by the local port operating state 331, the remote port operating state 332, and the local received signal detection state 333, this calculation does not introduce new detection items, nor does it change the content collected by the device management interface 130 or the optical module digital diagnostic interface. The purpose of the state coding is to enable the knowledge graph construction module 500 to store the three endpoint states 330 as structured attributes on the ordered endpoint structure 520.

[0058] The knowledge graph construction module 500 generates a port-ordered double-ended reception fracture structure feature 530 based on three endpoint states 330. The port-ordered double-ended reception fracture structure feature 530 corresponds to the symbol... This is used to represent endpoint direction evidence formed when the local physical port 310 is offline, the remote physical port 320 is online, and the local physical port 310 does not detect a received signal. The port-ordered dual-end reception breakage structural feature 530 is calculated using the following formula:

[0059] In the above formula, The feature 530 indicates a broken structure in the ordered dual-ended receiver at the port. This indicates that the local port is in operating status 331. This indicates that the peer port is in operating status 332. This indicates the local receiving signal detection status 333. When the local port operation status 331 indicates that the local physical port 310 is offline, the peer port operation status 332 indicates that the peer physical port 320 is online, and the local receiving signal detection status 333 indicates that no receiving signal is detected, the port ordered dual-end receiving break structure feature 530 is set to a binary value indicating a hit.

[0060] In other state combinations, the knowledge graph construction module 500 sets the port-ordered double-ended reception breakage structure feature 530 as a binary value representing a missed hit. For example, when both the local physical port 310 and the remote physical port 320 are online, no directional evidence facing the local receiving side is formed; when the local physical port 310 is offline but the local receiving signal detection state 333 indicates that a receiving signal has been detected, no hit result is formed for the port-ordered double-ended reception breakage structure feature 530; when both the local physical port 310 and the remote physical port 320 are offline, it is not possible to determine that the fault evidence is closer to the local physical port 310 based on a single direction.

[0061] The validity flag 540 indicates whether the port-ordered double-ended reception fracture structure feature 530 can participate in the sorting process of the structure feature sorting module 700. The knowledge graph construction module 500 sets the validity flag 540 to valid when all three endpoint states 330 exist, belong to the same time window 340, and the port adjacency mapping relationship 210 is valid. Only when the validity flag 540 is valid does the structure feature sorting module 700 summarize the port-ordered double-ended reception fracture structure feature 530 to obtain the valid port feature summary value 710 associated with the candidate object.

[0062] When the knowledge graph construction module 500 has missing endpoint states 330, inconsistent unified time windows 340, or port adjacency mapping relationship 210 exceeds the preset valid time, it sets the validity flag 540 to invalid and retains the device entity 511, port entity 512, physical link entity 513, service entity 514, and alarm entity 515 and their relationships in the basic knowledge graph 510.

[0063] The knowledge graph construction module 500 does not delete or replace existing graph data in the basic knowledge graph 510. For ordered endpoint structures 520 with invalid or missing features, the system still retains device entities 511, port entities 512, physical link entities 513, service entities 514, alarm entities 515, and service dependencies 516, so that the candidate root cause generation module 600 and the structural feature sorting module 700 can continue to use the basic root cause sorting score 720 to complete the sorting.

[0064] The candidate root cause generation module 600 generates candidate root cause objects 610 based on event clusters 410 and the basic knowledge graph 510. Candidate root cause objects 610 can be device entities 511, port entities 512, or physical link entities 513, or other existing graph objects that have a business dependency relationship 516 with the affected service entity 514. The generation scope of the candidate root cause generation module 600 is jointly defined by the alarm objects in the event clusters 410 and the topological relationships in the basic knowledge graph 510.

[0065] In one implementation, the candidate root cause generation module 600 starts from the service entity 514 that has a service alarm or is unavailable, and traverses a limited number of levels along the service dependency relationship 516, the device-port relationship, the port-to-physical link relationship, and the physical link-to-port relationship. During the traversal, the candidate root cause generation module 600 adds the device entity 511, port entity 512, and physical link entity 513 that have abnormal states, alarm records, or recent change records within a unified time window 340 to the candidate root cause object 610.

[0066] When the candidate root cause generation module 600 generates the candidate root cause object 610, it does not require that the port-ordered double-ended reception fracture structure feature 530 has been hit. That is to say, the candidate root cause generation module 600 still forms the candidate root cause object 610 according to the basic knowledge graph 510 and event cluster 410, and the structure feature sorting module 700 then determines whether to use the effective port feature summary value 710 associated with the candidate object during the sorting stage.

[0067] The candidate root cause generation module 600 can also store the graph path between the candidate root cause object 610 and the affected business entity 514. This graph path is used by the consistency verification module 800 to check whether the top-ranked candidate root cause object 610 is located in the dependency path of the affected business. For candidate root cause objects 610 that are not in the dependency path, the consistency verification module 800 can reduce their confidence or mark them as insufficient evidence.

[0068] Candidate root cause object 610 retains at least the object identifier, object type, source event cluster identifier, unified time window identifier, and graph path. The object type is used to distinguish the candidate root cause object 610 from the corresponding device entity 511, port entity 512, or physical link entity 513; the graph path records the device entities 511, port entities 512, physical link entities 513, and service dependencies 516 traversed between the candidate root cause object 610 and the affected service entity 514. The structural feature sorting module 700 determines the set of physical ports associated with the candidate object based on the object identifier and object type.

[0069] When event cluster 410 contains alarm evidence for local physical port 310, remote physical port 320, physical link entity 513, and service entity 514, the candidate root cause generation module 600 can simultaneously generate port entity 512 corresponding to local physical port 310, port entity 512 corresponding to remote physical port 320, physical link entity 513, and related device entity 511 as candidate root cause objects 610. These candidate root cause objects 610 are then uniformly sorted by the structural feature sorting module 700.

[0070] The structural feature sorting module 700 is used to obtain a basic root cause sorting score 720 based on the alarm evidence and topological association information of the candidate root cause object 610. When all three endpoint states 330 exist, belong to a unified time window 340, and the port adjacency mapping relationship 210 is valid, it summarizes the port ordered dual-end reception fracture structural features 530 to obtain a summary value 710 of valid port features associated with the candidate object. The summary value 710 of valid port features associated with the candidate object serves as the first sorting key, and the basic root cause sorting score 720 serves as the second sorting key.

[0071] The basic root cause ranking score of 720 can be calculated based on alarm severity, topology distance, and impact coverage. Alarm severity indicates the severity of the alarm evidence corresponding to candidate root cause object 610 in event cluster 410; topology distance indicates the graph path distance between candidate root cause object 610 and affected business entity 514; impact coverage indicates the extent to which downstream or related objects of candidate root cause object 610 are affected.

[0072] The structural feature ranking module 700 first converts alarm severity, topology distance, and impact coverage into dimensionless scores, and then calculates the root cause ranking score 720. The dimensionless score corresponding to alarm severity is denoted as... The dimensionless score corresponding to the topological distance is denoted as The dimensionless score corresponding to the impact on coverage is denoted as . , and The range of values ​​is The larger the value, the higher the candidate root cause object 610 should rank in the basic root cause ranking score 720.

[0073] When the monitoring and alarm platform 140 represents the alarm level as a sortable alarm level sequence number, the structural feature sorting module 700 can calculate the dimensionless score corresponding to the alarm severity according to the following formula:

[0074] In the above formula, Indicates that candidate root cause object 610 is The dimensionless score corresponding to the severity of the alarm at that time. This indicates the alarm level sequence number of candidate root cause object 610 in event cluster 410. This represents the minimum value of the alarm level number. This indicates the maximum value of the alarm level number. , and All are dimensionless ordinal numbers; the denominator uses... This is used to avoid division by zero when there is only one alarm level number.

[0075] When the basic knowledge graph 510 can provide the number of hops in the graph path between the candidate root cause object 610 and the affected business entity 514, the structural feature ranking module 700 can calculate the dimensionless score corresponding to the topological distance according to the following formula:

[0076] In the above formula, Indicates that candidate root cause object 610 is The dimensionless score corresponding to the topological distance at time. This represents the number of hops in the graph path between candidate root cause object 610 and affected business entity 514. It is a dimensionless non-negative integer; when the candidate root cause object 610 is located in the affected business entity 514 itself or its directly corresponding object. ,at this time As the number of hops on the graph path increases, It decreases monotonically.

[0077] When event cluster 410 is able to count the number of objects affected by candidate root cause object 610, structural feature sorting module 700 can calculate the dimensionless score corresponding to the influence coverage according to the following formula:

[0078] In the above formula, Indicates that candidate root cause object 610 is The dimensionless score corresponding to the coverage of the time-related impact. This indicates the number of affected objects associated with candidate root cause object 610 in event cluster 410. This indicates the total number of affected objects in event cluster 410. and All are dimensionless counts; the denominator uses... This is used to avoid division by zero when the number of affected objects is not counted in event cluster 410.

[0079] Basic Root Cause Ranking Score 720 Corresponding Symbol In one implementation, the structural feature ranking module 700 calculates the basic root cause ranking score 720 of the candidate root cause object 610 according to the following formula:

[0080] In the above formula, Indicates that candidate root cause object 610 is The baseline root cause ranking score was 720. Indicates that candidate root cause object 610 is The severity of the alarm at that time Indicates that candidate root cause object 610 is Topological distance at time Indicates that candidate root cause object 610 is The impact of time on coverage, This indicates the weight corresponding to the severity of the alarm. This indicates the weight corresponding to the topological distance. This indicates the weight that affects coverage. These weights can be determined by existing system configuration or operational strategies.

[0081] Alarm severity corresponding to weight Topological distance corresponding to weight Weights corresponding to the impact coverage All weights are dimensionless. Before using the above weights, the structural feature ranking module 700 first checks that the three satisfy the following constraints:

[0082] In the above formula, This indicates the weight corresponding to the severity of the alarm. This indicates the weight corresponding to the topological distance. This indicates the weight corresponding to the impact on coverage. The above constraints ensure that the root cause ranking score of 720 remains a dimensionless score, and also... The range of values ​​varies , and Keep it within the comparable range. If the existing system has already output dimensionless alarm severity, topology distance and impact coverage, the structural feature ranking module 700 directly uses the dimensionless output; if the existing system outputs the original alarm level, original graph path hop count or original number of affected objects, it is first converted in the above manner before calculating the basic root cause ranking score 720.

[0083] The symbol corresponding to the summary value of the effective port features associated with the candidate object 710 The structural feature sorting module 700 summarizes the port-ordered double-ended reception fracture structural features 530 on the valid ports associated with the candidate root cause object 610, obtaining a summary value 710 of the valid port features associated with the candidate object. This summarization can be implemented using a maximum value method, such that when any associated valid port hits the port-ordered double-ended reception fracture structural feature 530, the summary value 710 of the valid port features associated with the candidate object takes a binary value representing the existence of directional evidence.

[0084]

[0085] In the above formula, Indicates that candidate root cause object 610 is The total value of the effective port features associated with the candidate objects at that time was 710. This represents the set of physical ports associated with the candidate object. This represents the physical ports in the set of physical ports associated with the candidate object. Indicates physical port The corresponding port-ordered double-ended reception fracture structure feature 530. The set of physical ports associated with the candidate object is determined by the association relationships in the event cluster 410 and the basic knowledge graph 510.

[0086] When the set of physical ports associated with a candidate object is empty, the structural feature sorting module 700 does not perform the maximum value operation and marks the candidate root cause object 610 as having no valid port feature. Having no valid port feature is different from missing the port-ordered double-ended reception breakage structural feature 530: the former indicates that there is no port evidence that can participate in the first sorting key, while the latter indicates that valid port evidence exists, but the port-ordered double-ended reception breakage structural feature 530 takes a binary value representing a missed match.

[0087] When the set of physical ports associated with a candidate object is not empty, but none of the associated physical ports have a valid port-ordered double-ended reception breakage structural feature 530, the structural feature sorting module 700 also does not use the summary value 710 of the valid port features associated with the candidate object for priority, and sorts them using the basic root cause sorting score 720 through the backsliding sorting path 730. Only when at least one associated physical port has a validity flag 540 indicating a valid port-ordered double-ended reception breakage structural feature 530, does the structural feature sorting module 700 calculate the summary value 710 of the valid port features associated with the candidate object.

[0088] When candidate root cause object 610 is port entity 512, the set of physical ports associated with the candidate object can include the physical ports corresponding to port entity 512 itself. When candidate root cause object 610 is physical link entity 513, the set of physical ports associated with the candidate object can include the physical ports at both ends of physical link entity 513. When candidate root cause object 610 is device entity 511, the set of physical ports associated with the candidate object can include the physical ports related to device entity 511 in event cluster 410. The above association methods are all based on the existing device, port, physical link, and service dependency relationships in the basic knowledge graph 510.

[0089] The structural feature sorting module 700 forms the final sorting key based on the aggregated value 710 of the effective port features associated with the candidate objects and the basic root cause sorting score 720. The final sorting key corresponds to the symbol... This is used to perform a descending lexicographical sort on the candidate root cause objects 610. The final sort key is represented by the following formula:

[0090] In the above formula, Indicates that candidate root cause object 610 is The final sort key at that time The total value of the effective port features associated with the candidate object is 710. The basic root cause ranking score is 720. The structural feature ranking module 700 first compares the sum of effective port features associated with candidate objects 710, and then compares the basic root cause ranking score 720. Candidate root cause objects 610 with a larger sum of effective port features associated with candidate objects 710 are ranked higher; when the sum of effective port features associated with candidate objects 710 are the same, candidate root cause objects 610 with a larger basic root cause ranking score 720 are ranked higher.

[0091] When the port-ordered double-ended reception fracture structure feature 530 is invalid or missing, the structure feature sorting module 700 reverts to the basic root cause sorting score 720 via the rollback sorting path 730. Invalidity or missing features include the absence of three endpoint states 330, inconsistencies in the unified time window 340 to which the three endpoint states 330 belong, port adjacency mapping relationships 210 exceeding a preset valid time, or the knowledge graph construction module 500 failing to generate a port-ordered double-ended reception fracture structure feature 530 suitable for sorting. This rollback process ensures that the system can still output root cause localization results 910 compatible with existing root cause localization processes even when data is incomplete.

[0092] The structural feature sorting module 700 does not prioritize sorting based on the individual local port operating state 331 being offline, the individual peer port operating state 332 being online, or the individual local receiving signal detection state 333 not detecting a received signal. Only when the local port operating state 331, the peer port operating state 332, and the local receiving signal detection state 333 all meet the hit condition of the port ordered dual-end reception breakage structural feature 530, and the validity flag 540 is valid, will the aggregated value 710 of the valid port features associated with the candidate object participate in the priority sorting.

[0093] The consistency verification module 800 checks whether the top-ranked candidate root cause object 610 is located in the dependency path of the affected service, whether there is abnormal evidence within the unified time window 340, whether the alarm time is earlier than or no later than the downstream alarm, and whether there is maintenance or known changes. The verification result 810 is then provided to the location result output module 900. The consistency verification module 800 corresponds to... Figure 1 The processing unit is located after the structural feature sorting module 700.

[0094] When the consistency verification module 800 checks whether the top-ranked candidate root cause object 610 is located in the dependency path of the affected business, it can use the graph path saved by the candidate root cause generation module 600. If there is no interpretable business dependency relationship 516 or topological path between the candidate root cause object 610 and the affected business entity 514, the consistency verification module 800 can mark the verification result 810 of the candidate root cause object 610 as insufficient evidence.

[0095] When the consistency verification module 800 checks whether the top-ranked candidate root cause object 610 has abnormal evidence within the unified time window 340, it can read the relevant object status in the event cluster 410, the three endpoint states 330, the port ordered double-ended reception fracture structure feature 530, and the basic knowledge graph 510. If the top-ranked candidate root cause object 610 does not have a corresponding alarm record, abnormal state, or traceable endpoint direction evidence, the consistency verification module 800 can reduce its confidence level or submit it for manual verification.

[0096] When the consistency verification module 800 checks whether the alarm time is earlier than or no later than the downstream alarm, it can compare the occurrence time of the alarm record corresponding to the candidate root cause object 610 with the occurrence time of the alarm record corresponding to the affected business entity 514 or the downstream object. This comparison is used to avoid prioritizing objects that are significantly later than the downstream impact as the root cause object.

[0097] When the consistency verification module 800 checks whether maintenance or known changes exist, it can read the maintenance window information provided by the change system, maintenance status records, or monitoring and alarm platform 140. If the candidate root cause object 610 ranked at the top is under maintenance or has known changes within the unified time window 340, the consistency verification module 800 can mark the existence of maintenance or known changes in the verification result 810 so that the root cause location result output module 900 can output an interpretable root cause location result 910.

[0098] The root cause localization result output module 900 outputs the root cause localization result 910. The root cause localization result 910 may include the root cause object, affected services, associated alarms, topology path, key evidence, and suggested inspection items. Key evidence may include the port ordered double-ended reception breakage structural feature 530, the summary value of valid port features associated with candidate objects 710, the basic root cause ranking score 720, the validity flag 540, and the verification result 810. The root cause localization result output module 900 can output the root cause localization result 910 through an interface, work order fields, interface response, or report file.

[0099] The location result output module 900 can also archive the manual confirmation results, recovery time, and processing records. By outputting the verification result 810 together with the root cause location result 910, the operation and maintenance personnel can see why the candidate root cause object 610 is ranked higher due to port direction evidence, and also see why the system reverts to the basic root cause ranking score 720 when the port ordered double-ended reception fracture structure feature 530 is invalid or missing.

[0100] In a complete workflow embodiment, the system first connects to the configuration management database 110, the neighbor discovery data source 120, the device management interface 130, and the monitoring and alarm platform 140 via the data source layer 100. The static topology acquisition module 200 reads the devices, ports, physical links, and service dependencies from the configuration management database 110, and reads the neighbor discovery data from the neighbor discovery data source 120. Based on the above data, the static topology acquisition module 200 generates a port adjacency mapping relationship 210 and provides the port adjacency mapping relationship 210 to the endpoint parameter acquisition module 300 and the knowledge graph construction module 500.

[0101] After the unified time window 340 begins, the endpoint parameter acquisition module 300 confirms that the port adjacency mapping relationship 210 is within its validity period and identifies the local physical port 310 and the peer physical port 320, both of which have the capability to receive signals. The endpoint parameter acquisition module 300 reads the local port's operating status 331 through the device management interface 130, identifies the peer physical port 320 through the LLDP neighbor relationship and reads the peer port's operating status 332 through the peer device management interface, and reads the local received signal detection status 333 through the optical module digital diagnostic interface.

[0102] The data standardization module performs unified processing on device names, port names, time formats, status enumerations, and alarm levels, and performs deduplication and time alignment based on object identifiers, event types, and unified time window identifiers. If any of the following states is unavailable: local port operating status 331, remote port operating status 332, or local received signal detection status 333, the data standardization module retains a missing status flag. If all three endpoint states are available, the data standardization module converts them into binary status values.

[0103] The event association module 400 reads the alarm records provided by the monitoring and alarm platform 140 and generates event clusters 410 according to a unified time window 340. Event clusters 410 are provided to the knowledge graph construction module 500 and the candidate root cause generation module 600. The knowledge graph construction module 500 retains device entities 511, port entities 512, physical link entities 513, service entities 514, alarm entities 515, and service dependencies 516 in the basic knowledge graph 510, and generates an ordered endpoint structure 520 on the physical link relationships.

[0104] exist Figure 1In the connection relationship, the three endpoint states 330, port adjacency mapping relationship 210, and event cluster 410 are respectively input into the knowledge graph construction module 500. The knowledge graph construction module 500 maintains the basic knowledge graph 510, generates an ordered endpoint structure 520, generates port ordered double-ended reception fracture structure features 530, and sets a validity flag 540. The port ordered double-ended reception fracture structure features 530 are summarized by the structure feature sorting module 700 to form a summary value 710 of valid port features associated with candidate objects. The summary value 710 of valid port features associated with candidate objects is used as the first sorting input to the structure feature sorting module 700, and the basic root cause sorting score 720 is used as the second sorting input to the structure feature sorting module 700. When the validity flag 540 is invalid or the port ordered double-ended reception fracture structure feature 530 is missing, the fallback sorting path 730 will guide the sorting process to the basic root cause sorting score 720.

[0105] The knowledge graph construction module 500 calculates the state code based on the local port operating state 331, the remote port operating state 332, and the local received signal detection state 333, and generates the port ordered dual-end reception break structure feature 530. If all three endpoint states 330 exist, belong to the same time window 340, and the port adjacency mapping relationship 210 is valid, the knowledge graph construction module 500 sets the validity flag 540 to valid; otherwise, it sets the validity flag 540 to invalid and retains the existing entities and relationships in the basic knowledge graph 510.

[0106] The candidate root cause generation module 600 generates candidate root cause objects 610 based on event clusters 410 and a basic knowledge graph 510. The candidate root cause object 610 may include the port entity 512 that experienced the anomaly, the physical link entity 513 connected to the port entity 512, adjacent device entities 511, and other objects on the dependent path of the affected service entity 514. The candidate root cause generation module 600 also stores the graph path between the candidate root cause object 610 and the affected service entity 514.

[0107] The structural feature sorting module 700 first calculates the basic root cause sorting score 720 based on the alarm evidence and topology association information of the candidate root cause object 610. Then, under the condition that the validity flag 540 is valid, it summarizes the port-ordered double-ended reception breakage structural feature 530 to obtain the valid port feature summary value 710 associated with the candidate object. The structural feature sorting module 700 then performs descending lexicographical sorting on the candidate root cause object 610 according to the final sorting key. If the port-ordered double-ended reception breakage structural feature 530 is invalid or missing, the structural feature sorting module 700 returns to the basic root cause sorting score 720 through the backsliding sorting path 730.

[0108] The consistency verification module 800 verifies the top-ranked candidate root cause objects 610, checking whether they are located in the dependency path of the affected service, whether there is abnormal evidence within the unified time window 340, whether the alarm time is earlier or later than the downstream alarm, and whether there is maintenance or known change. The consistency verification module 800 generates a verification result 810 and provides the verification result 810 to the location result output module 900. The location result output module 900 outputs the root cause location result 910.

[0109] In one implementation, Eth1 / 1 of Leaf-01 and Eth2 / 1 of Spine-01 are connected via physical link entity 513. The static topology acquisition module 200 generates a port adjacency mapping relationship 210 based on the configuration management database 110 and the neighbor discovery data source 120. The port adjacency mapping relationship 210 shows that Eth1 / 1 of Leaf-01 and Eth2 / 1 of Spine-01 are adjacent ports, and the port adjacency mapping relationship 210 is valid.

[0110] The endpoint parameter acquisition module 300 uses Eth1 / 1 of Leaf-01 as its local physical port 310 and Eth2 / 1 of Spine-01 as its remote physical port 320, and collects three endpoint statuses 330 in groups within a unified time window 340. At this time, the local port running status 331 indicates that the local physical port 310 is online, the remote port running status 332 indicates that the remote physical port 320 is online, and the local received signal detection status 333 indicates that a received signal has been detected.

[0111] Specifically, , , The knowledge graph construction module 500 obtains a state code of 2 based on the state coding formula, and obtains the port-ordered double-ended reception fracture structure feature 530 as a binary value representing a missed match based on the formula for the port-ordered double-ended reception fracture structure feature 530. Since no directional evidence facing the local receiving side is formed, the structure feature ranking module 700 will not improve the ranking of the relevant candidate root cause objects 610 due to the port-ordered double-ended reception fracture structure feature 530.

[0112] If the monitoring and alarm platform 140 does not generate any service unavailability alarms or link anomaly alarms within the same unified time window 340, the event association module 400 will not generate an event cluster 410 that requires root cause localization. If other minor alarms exist, the candidate root cause generation module 600 can still generate candidate root cause objects 610 based on the event cluster 410 and the basic knowledge graph 510, but the structural feature ranking module 700 mainly completes the ranking based on the basic root cause ranking score 720.

[0113] In one implementation, server Srv-01 connects to the upper-layer network via Eth1 / 1 of Leaf-01 and Eth2 / 1 of Spine-01. During a unified time window 340, Srv-01 becomes unreachable, and the monitoring and alarm platform 140 generates service unavailability alarms and port-related alarms. The static topology acquisition module 200 has already generated port adjacency mapping relationships 210 based on the neighbor discovery data source 120 and confirmed that Eth1 / 1 of Leaf-01 and Eth2 / 1 of Spine-01 are in a valid adjacency relationship.

[0114] The endpoint parameter acquisition module 300 uses Eth1 / 1 of Leaf-01 as its local physical port 310 and Eth2 / 1 of Spine-01 as its peer physical port 320, acquiring three endpoint statuses 330 within the same unified time window 340. The acquisition results are as follows: local port running status 331 indicates that local physical port 310 is offline; peer port running status 332 indicates that peer physical port 320 is online; and local received signal detection status 333 indicates that no received signal was detected.

[0115] Specifically, , , The computational status coding for the knowledge graph construction module 500 is as follows:

[0116] The knowledge graph construction module 500 computation port has an ordered, dual-ended receiving structure with fractured features as follows:

[0117] The above calculation results indicate that when Leaf-01's Eth1 / 1 is used as the local physical port 310, the port's ordered dual-end reception breakage structure feature 530 is a binary value representing a hit. This result is not obtained from a single port offline, nor from a single failure to detect a received signal, but rather from the local port operating state 331, the peer port operating state 332, and the local received signal detection state 333 all satisfying the same conditions within the same unified time window 340.

[0118] The event association module 400 incorporates the Srv-01 unreachable alarm, the Leaf-01 Eth1 / 1 port alarm, and related link alarms into the event cluster 410. The candidate root cause generation module 600 generates, based on the event cluster 410 and the basic knowledge graph 510, the Leaf-01 Eth1 / 1 corresponding port entity 512, the Leaf-01 and Spine-01 physical link entity 513, the Spine-01 Eth2 / 1 corresponding port entity 512, and related device entities 511 as candidate root cause objects 610.

[0119] The structural feature ranking module 700 first calculates the basic root cause ranking score 720 for each candidate root cause object 610, and then summarizes the port-ordered double-ended receiving fracture structural features 530 based on the physical port set associated with the candidate objects. For candidate root cause objects 610 directly associated with Eth1 / 1 of Leaf-01, the summary value 710 of the effective port features associated with the candidate object is a binary value representing the existence of directional evidence. If the basic root cause ranking scores 720 of multiple candidate root cause objects 610 are close, the final ranking key makes the candidate root cause object 610 with the higher summary value 710 of the effective port features associated with the candidate object ranked higher.

[0120] The consistency verification module 800 then checks whether the top-ranked candidate root cause object 610 is located in the dependency path of the business entity 514 corresponding to Srv-01, whether there is abnormal evidence within the unified time window 340, whether the alarm time is earlier or no later than the downstream alarm, and whether there is maintenance or known changes. If the verification result 810 passes, the root cause location result output module 900 outputs the root cause location result 910, which includes the port ordered double-ended reception fracture structure feature 530, the summary value of the valid port features associated with the candidate object 710, and the basic root cause ranking score 720.

[0121] In one implementation, the endpoint parameter acquisition module 300 can read the local port operating status 331 and the local received signal detection status 333, but cannot read the peer port operating status 332 because the peer device management interface is temporarily unavailable. The data standardization module retains a missing flag for the peer port operating status 332 among the three endpoint statuses 330 and provides this missing flag to the knowledge graph construction module 500.

[0122] After the knowledge graph construction module 500 discovers that three endpoint states 330 are missing, it sets the validity flag 540 to invalid. Because the validity flag 540 is invalid, the knowledge graph construction module 500 does not generate a port-ordered double-ended reception breakage structure feature 530 that can participate in sorting. At this time, the device entity 511, port entity 512, physical link entity 513, service entity 514, alarm entity 515, and service dependency relationship 516 in the basic knowledge graph 510 are still retained.

[0123] When the structural feature sorting module 700 discovers that the port ordered double-ended reception structural feature 530 is invalid or missing, it reverts to the basic root cause sorting score 720 through the fallback sorting path 730. In other words, the structural feature sorting module 700 does not use the summary value 710 of valid port features associated with the candidate object as the first sorting key, but instead uses the basic root cause sorting score 720 formed by alarm severity, topology distance, and impact coverage to sort the candidate root cause objects 610.

[0124] Specifically, if the peer device management interface does not return the peer port running status 332 before the end boundary of the unified time window 340, the endpoint parameter acquisition module 300 performs a retry read. If the retry read still does not return a resolvable status, the data standardization module retains the missing flag of the peer port running status 332, the knowledge graph construction module 500 sets the validity flag 540 to invalid, and the structural feature sorting module 700 does not calculate the valid port feature summary value 710 associated with the candidate object corresponding to the ordered endpoint structure 520.

[0125] In another implementation, the endpoint parameter acquisition module 300 can read the local port operating status 331, the remote port operating status 332, and the local received signal detection status 333, but the three endpoint states 330 belong to different unified time windows 340. The knowledge graph construction module 500 also sets the validity flag 540 to invalid. This process avoids incorrectly combining port states acquired at different times into the port ordered dual-end reception broken structural feature 530.

[0126] In another implementation, a neighbor discovers that the port adjacency mapping relationship 210 in data source 120 has exceeded a preset validity period. Although the endpoint parameter acquisition module 300 may still read the local port operating status 331, the peer port operating status 332, and the local received signal detection status 333, the knowledge graph construction module 500 sets the validity flag 540 to invalid because the port adjacency mapping relationship 210 is not within its validity period. This process avoids incorrectly determining the peer physical port 320 based on expired adjacency relationships.

[0127] In one implementation, the system performs a reverse calculation perspective on the same physical link entity 513. Taking the aforementioned Eth1 / 1 of Leaf-01 and Eth2 / 1 of Spine-01 as an example, if the system uses Eth2 / 1 of Spine-01 as the local physical port 310 and Eth1 / 1 of Leaf-01 as the peer physical port 320, then the endpoint parameter acquisition module 300 rereads the local port operating status 331, the peer port operating status 332, and the local received signal detection status 333 under this calculation perspective.

[0128] Specifically, the directionality of the ordered endpoint structure 520 comes from the computational perspectives of the local physical port 310 and the remote physical port 320, rather than from modifications to the physical link entity 513. For the same physical link entity 513, the ordered endpoint structures 520 in both directions can respectively store the state code and the port-ordered double-ended reception breakage structure feature 530. When sorting, the structure feature sorting module 700 only uses the port-ordered double-ended reception breakage structure feature 530 that is associated with and valid for the candidate root cause object 610.

[0129] This implementation can be deployed in data center operation and maintenance management platforms, network monitoring platforms, fault alarm analysis platforms, AIOps platforms, or analysis services between configuration management databases and monitoring systems. The system can be implemented by a single server or distributed across multiple servers. The static topology acquisition module 200, endpoint parameter acquisition module 300, event association module 400, knowledge graph construction module 500, candidate root cause generation module 600, structural feature sorting module 700, consistency verification module 800, and location result output module 900 can be different functional units within the same program, or they can be multiple service units called through interfaces.

[0130] The device management interface 130 can be a read-only interface. The endpoint parameter acquisition module 300 reads the local port operating status 331 through the device management interface 130, the peer port operating status 332 through the peer device management interface, and the local received signal detection status 333 through the optical module digital diagnostic interface. Reading from these interfaces does not require modification of the switch port, optical module, fiber optic cable, or cabling structure. For port status data already centrally collected by the monitoring platform, the endpoint parameter acquisition module 300 can also read the same fields from the monitoring platform's data interface.

[0131] The basic knowledge graph 510 can be stored in a graph database, relational database, document-oriented database, or in-memory graph structure. If a graph database is used, device entities 511, port entities 512, physical link entities 513, service entities 514, and alarm entities 515 can be represented as nodes; service dependencies 516 and port connection relationships can be represented as relations; and the ordered endpoint structure 520 can be represented as relations with directional attributes or intermediate nodes. If a relational database is used, edge tables and attribute tables can be used to record the same information. The above storage methods are all conventional implementation methods.

[0132] The structural feature sorting module 700 can be implemented by a software program. This software program reads the candidate root cause object 610, the basic root cause sorting score 720, the port-ordered double-ended receiving fracture structural feature 530, and the validity flag 540, and performs descending lexicographical sorting according to the final sorting key. The sorting output is passed to the consistency verification module 800, which then provides the verification result 810 to the location result output module 900. The entire process can be executed in batches after the unified time window 340 ends, or incrementally according to event clusters 410 as alarm records continuously enter.

[0133] The module names in this embodiment are used to describe functional boundaries and do not require each module to correspond to an independent physical device. Modules can be deployed in the same server process or in different containers, virtual machines, or service nodes. As long as the system can perform the grouped data collection, event correlation, basic knowledge graph maintenance (510), ordered endpoint structure generation (520), candidate root cause object generation (610), structural feature sorting, consistency verification, and root cause localization result output (910) described in this embodiment, it falls within the scope of this embodiment.

[0134] This implementation uses the endpoint parameter acquisition module 300 to collect the local port operating status 331, the peer port operating status 332, and the local received signal detection status 333 in groups within a unified time window 340. This allows the system to obtain status evidence from both ends of the physical link and the local receiving side during the same event analysis process. Compared to relying solely on a single port alarm, this group acquisition reduces ambiguity in judgment caused by single-point status.

[0135] In this implementation, the knowledge graph construction module 500 generates an ordered endpoint structure 520 in the basic knowledge graph 510, so that the same physical link entity 513 has a directional expression of its local physical port 310 and its peer physical port 320 at the data layer of the computer system. This directional expression does not change the actual physical connection, but enables the ordered dual-end receiving fracture structure feature 530 of the port to be attached to a clear endpoint perspective.

[0136] This embodiment defines the combination of the local port operating state 331 being offline, the remote port operating state 332 being online, and the local receiving signal detection state 333 being no received signal detected by the port ordered dual-end receiving structural feature 530. This avoids directly using a single port offline, a single no received signal detected, or both ends being offline simultaneously as directional evidence. This combination condition allows the structural feature sorting module 700 to obtain more specific endpoint directional evidence.

[0137] In this embodiment, the structural feature sorting module 700 uses the summary value 710 of the effective port features associated with candidate objects as the first sorting key and the basic root cause sorting score 720 as the second sorting key. When the basic root cause sorting scores 720 of multiple candidate root cause objects 610 are close, the candidate root cause object 610 with endpoint direction evidence can be output first. This sorting method retains the basic root cause sorting score 720 and adds sorting criteria related to physical endpoint direction.

[0138] This implementation restricts the use of the port-ordered dual-end reception fracture structure feature 530 by using a validity flag 540 and a fallback sorting path 730. When three endpoint states 330 are missing, the corresponding unified time windows 340 are inconsistent, or the port adjacency mapping relationship 210 exceeds a preset valid time, the system does not use the valid port feature summary value 710 associated with the candidate object as the first sorting key, but instead falls back to the basic root cause sorting score 720 for sorting. This process reduces missorting caused by incomplete data or expired adjacency relationships.

[0139] This implementation uses the consistency verification module 800 to check dependency paths, abnormal evidence, alarm time, maintenance and known changes, and outputs the root cause location result 910 through the location result output module 900. The root cause location result 910 includes not only the sorting order, but also the verification result 810 and key evidence that can be reviewed by operation and maintenance personnel.

[0140] This embodiment also provides a knowledge graph-based method for locating root cause faults in data center network topology. This method can be developed by... Figure 1 The system shown can be executed by a software system with the same functionality. At the beginning of the method, the static topology acquisition module 200 reads static topology data and neighbor discovery data from the configuration management database 110 and the neighbor discovery data source 120, generates a port adjacency mapping relationship 210 that is within its validity period, and provides the port adjacency mapping relationship 210 to the endpoint parameter acquisition module 300.

[0141] Within a unified time window 340, the endpoint parameter acquisition module 300, based on the port adjacency mapping relationship 210 determined by static topology data or neighbor discovery data and within its validity period, collects three endpoint states 330 corresponding to the local physical port 310 and the peer physical port 320, all of which have the capability to receive signals. The three endpoint states 330 include the local port operating state 331, the peer port operating state 332, and the local received signal detection state 333. The endpoint parameter acquisition module 300 stores the local physical port identifier, the peer physical port identifier, and the unified time window identifier.

[0142] The event association module 400 associates alarm records based on a unified time window 340 and generates event clusters 410. The data standardization module standardizes device names, port names, time formats, status enumerations, and alarm levels before or during event association, and performs deduplication and time alignment based on object identifiers, event types, and unified time window identifiers. When any of the three endpoint states 330 is unavailable, the data standardization module retains a missing status flag.

[0143] The knowledge graph construction module 500 generates an ordered endpoint structure 520 in the basic knowledge graph 510 and generates an ordered dual-end reception breakage structure feature 530 based on three endpoint states 330. The basic knowledge graph 510 contains device, port, physical link, and service dependency relationships. The ordered endpoint structure 520 records the ordered relationship between the local physical port 310, the physical link entity 513, and the peer physical port 320. When the three endpoint states 330 are missing, the unified time window 340 is inconsistent, or the port adjacency mapping relationship 210 exceeds the preset valid time, the knowledge graph construction module 500 sets the validity flag 540 to invalid.

[0144] In this method implementation, the knowledge graph construction module 500 also associates the object identifier of the event cluster 410, the object identifier of the candidate root cause object 610, and the port entity 512 in the basic knowledge graph 510. If the candidate root cause object 610 is a port entity 512, then the set of physical ports associated with the candidate object includes the port entity 512; if the candidate root cause object 610 is a physical link entity 513, then the set of physical ports associated with the candidate object includes the port entities 512 at both ends of the physical link entity 513; if the candidate root cause object 610 is a device entity 511, then the set of physical ports associated with the candidate object includes the port entities 512 of the device entity 511 that have an alarm or abnormal state in the event cluster 410.

[0145] The candidate root cause generation module 600 generates candidate root cause objects 610 based on event clusters 410 and a basic knowledge graph 510. The structural feature sorting module 700 sorts the candidate root cause objects 610 according to the summary value 710 of valid port features associated with the candidate objects and the basic root cause sorting score 720, and reverts to sorting based on the basic root cause sorting score 720 when the port ordered double-ended reception fracture structural feature 530 is invalid or missing. The localization result output module 900 outputs the root cause localization result 910.

[0146] The embodiments of this example have been described above. However, this example is not limited to the specific implementation methods described above. The specific implementation methods described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms based on the guidance of this example, and all of them are within the protection scope of this example.

Claims

1. A knowledge graph-based data center network topology root cause fault localization system, comprising an endpoint parameter acquisition module, an event association module, a knowledge graph construction module, a candidate root cause generation module, a structural feature ranking module, and a localization result output module, characterized in that, The basic knowledge graph includes devices, ports, physical links, and service dependencies; The endpoint parameter acquisition module is used to collect three endpoint states of the local physical port and the peer physical port, which are both capable of receiving signals, within a unified time window, based on the port adjacency mapping relationship determined by topology data or neighbor discovery data and within the validity period. The three endpoint states include the local port running status, the peer port running status, and the local receiving signal detection status. The event association module is used to generate event clusters according to a unified time window; The knowledge graph construction module is used to generate an ordered endpoint structure in the basic knowledge graph and generate port-ordered double-ended receiving fracture structure features based on three endpoint states. The candidate root cause generation module is used to generate candidate root cause objects based on event clusters and basic knowledge graphs; The structural feature sorting module is used to obtain the basic root cause sorting score based on the alarm evidence and topological association information of the candidate root cause object. When all three endpoint states exist, belong to the same time window, and the port adjacency mapping relationship is valid, the module summarizes the port ordered double-end reception fracture structure features to obtain the effective port feature summary value associated with the candidate object and sorts it in priority over the basic root cause sorting score. When the port ordered double-end reception fracture structure features are invalid or missing, the module reverts to sorting in the basic root cause sorting score. The root cause localization results output module is used to output the root cause localization results.

2. The knowledge graph-based data center network topology root cause fault location system according to claim 1, characterized in that, The endpoint parameter acquisition module is also used to save the local physical port identifier, the peer physical port identifier, and the unified time window identifier, and to record the three endpoint states as binary status values.

3. The knowledge graph-based data center network topology root cause fault location system according to claim 1, characterized in that, Both the local and remote physical ports are physical optical ports. The endpoint parameter acquisition module reads the local port's operating status through the device management interface, identifies the remote physical port through LLDP neighbor relationships, reads the remote port's operating status through the remote device management interface, and reads the local received signal detection status through the optical module's digital diagnostic interface.

4. The knowledge graph-based data center network topology root cause fault location system according to claim 1, characterized in that, It also includes a data standardization module, which is used to unify device names, port names, time formats, status enumerations and alarm levels, and to perform deduplication and time alignment based on object identifiers, event types and unified time window identifiers, and retain a missing flag when any of the three endpoint statuses is unavailable.

5. The knowledge graph-based data center network topology root cause fault location system according to claim 1, characterized in that, The knowledge graph construction module retains the device entities, port entities, physical link entities, service entities, and alarm entities and their relationships in the basic knowledge graph, and adds ordered endpoint structure, port ordered double-end reception breakage structure features, and validity flags to the physical link relationships.

6. The knowledge graph-based data center network topology root cause fault location system according to claim 1, characterized in that, When the local port running status indicates that the local physical port is offline, the remote port running status indicates that the remote physical port is online, and the local receiving signal detection status indicates that no receiving signal is detected, the knowledge graph construction module sets the port ordered double-ended receiving breakage structure feature to a binary value representing a hit. Under other state combinations, the port ordered double-ended receiving breakage structure feature is set to a binary value representing a miss.

7. The knowledge graph-based data center network topology root cause fault location system according to claim 1, characterized in that, When the knowledge graph construction module has missing statuses of the three endpoints, inconsistent unified time windows, or port adjacency mapping relationships exceeding the preset valid time, it sets the validity flag to invalid and retains the device entities, port entities, physical link entities, service entities, and alarm entities and their relationships in the basic knowledge graph.

8. The knowledge graph-based data center network topology root cause fault location system according to claim 1, characterized in that, The structural feature sorting module first calculates the basic root cause sorting score according to alarm severity, topology distance, and impact coverage. Then, it uses the summary value of the effective port features associated with the candidate object as the first sorting key and the basic root cause sorting score as the second sorting key to perform descending lexicographical sorting.

9. The knowledge graph-based data center network topology root cause fault location system according to claim 1, characterized in that, It also includes a consistency verification module, which checks whether the top-ranked candidate root cause objects are located in the dependency path of the affected business, whether there is abnormal evidence within a unified time window, whether the alarm time is earlier or no later than the downstream alarm, and whether there is maintenance or known changes, and provides the verification results to the location result output module.

10. A knowledge graph-based method for locating root cause faults in data center network topology, characterized in that, include: Within a unified time window, based on the port adjacency mapping relationship determined by static topology data or neighbor discovery data and within its validity period, three endpoint states corresponding to the local physical port and the peer physical port, which all have the ability to receive signals, are collected in groups. Alarm records are correlated and event clusters are generated based on a unified time window. An ordered endpoint structure is generated in the basic knowledge graph, and the port ordered double-ended reception fracture structure feature is generated based on the three endpoint states. Candidate root cause objects are generated based on event clusters and basic knowledge graphs; Candidate root cause objects are sorted according to the sum of valid port features associated with the candidate objects and the basic root cause sorting score, and the sorting is returned to the basic root cause sorting score when the port ordered double-end reception fracture structure features are invalid or missing. Output the root cause localization results.

Images