Network port state monitoring and early warning method based on knowledge graph

Abstract

The invention discloses a network port state monitoring and early warning method based on a knowledge graph. The method comprises the following steps: configuring and issuing an SNMP acquisition template; obtaining a network equipment identifier and a port identifier, constructing a port knowledge graph, and writing a port connection relationship and a protocol adjacency relationship; training an embedded vector by adopting TransE and generating a port dependent sub-graph; collecting port indexes according to a polling cycle to generate port time sequence data, retrying if the port time sequence data fails, and generating an abnormal collection alarm; the port time sequence data is written into a time sequence database through a message queue; generating a candidate alarm set according to an alarm rule and writing the candidate alarm set into a port knowledge graph; solving a root cause port set and an explanation path based on the port dependence subgraph to generate a root cause alarm set; and grading based on the root cause alarm set and combining work order feedback to update a grading weight and a grading threshold value. According to the invention, the port-level root cause positioning and alarm closed-loop calibration capability is improved.

Description

Technical Field

[0001] This invention relates to the field of network management and network operation and maintenance monitoring technology, and in particular to a method for monitoring and early warning of network port status based on knowledge graphs. Background Technology

[0002] In the field of network operation and maintenance and network management, SNMP polling, Trap alarms, and centralized display on network management platforms are commonly used to monitor device status. Existing solutions typically collect indicators such as CPU, memory, and overall system traffic at the device level, and configure fixed threshold policies on the management end. Combined with alarm notifications and work order flow, fault handling is completed. To improve collection and storage capabilities, message queues are often used in engineering practice to decouple the collection and storage process, and the monitoring data is written to a time-series database to support historical queries and report analysis. In multi-vendor and multi-model network environments, operation and maintenance personnel often need to maintain OID mapping and SNMP parameters in a templated manner, rely on periodic polling to form time-series data, and then use a rule engine to determine alarms based on the time-series data.

[0003] Existing technologies have limitations in terms of monitoring granularity and fault location. Device-level monitoring struggles to express port-level link quality and port-level congestion. When service interruptions occur, only overall device alarms are often obtained, failing to quickly pinpoint specific ports, metrics, or abnormal intervals. This leads to an expanded troubleshooting scope and increased location time. Alarm generation is typically based on single-metric thresholds. Although baselines, trends, and composite conditions can be overlaid, there is a lack of structured modeling of network topology and protocol adjacency relationships between alarms, making it difficult to depict the dependency propagation relationships between ports. In alarm storm scenarios, cascading phenomena can easily occur where the same root cause triggers multiple alarms. When relying on manual experience for correlation analysis, alarm suppression and aggregation lack a unified and calculable basis, root cause explanation paths cannot be reliably reproduced, and the work order handling results in the alarm closed loop are difficult to systematically feed back into alarm judgment and classification strategies.

[0004] Existing technologies also have shortcomings in terms of data collection reliability and policy calibration. Network fluctuations, authentication configuration changes, and link jitter can cause data collection timeouts and intermittent failures. Traditional fixed retry strategies and fixed polling cycles are difficult to balance data continuity and collection overhead under different loads and fault stages, easily leading to insufficient collection frequency on critical ports or excessive collection frequency on non-critical ports. Although data pipelines can be extended through message queues and time-series databases, without a unified mechanism for cross-link tracing and data consistency verification, it is difficult to establish a traceable link between collection tasks, alarm judgment, and database records. More importantly, alarm classification and dispatch often rely on static weights and fixed threshold configurations, lacking a mechanism for online calibration of scoring weights and classification thresholds using work order processing results. False alarms and false negatives are difficult to control in long-term operation, leading to decreased alarm reliability and increased operation and maintenance costs.

[0005] Therefore, how to provide a knowledge graph-based method for network port status monitoring and early warning is a problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0006] One objective of this invention is to propose a network port status monitoring and early warning method based on knowledge graphs. This invention integrates SNMP port-level monitoring, knowledge graph modeling, and representation learning technologies to perform structured modeling and continuous monitoring of network device port status and performance indicators. Through port dependency mining, root cause alarm suppression aggregation, and closed-loop feedback online calibration, it achieves accurate location and intelligent early warning of network faults. It has the advantages of fine monitoring granularity, accurate root cause location, low alarm noise, and strong adaptive operation and maintenance decision-making capabilities.

[0007] A network port status monitoring and early warning method based on knowledge graph according to an embodiment of the present invention includes the following steps: Configure SNMP data collection templates and distribute them in batches via a web interface; Obtain network device identifiers and port identifiers, construct a port knowledge graph, and write port connection relationships and protocol adjacency relationships; Based on the port knowledge graph, TransE is used to train the embedding vectors, and the port dependency edge weights are calculated based on the vector distance to generate the port dependency subgraph. Based on the SNMP collection template, port status indicators and port performance indicators are collected according to the polling cycle, and port time sequence data is generated. If the collection fails, the collection is retried according to the number of retries and the retry interval, and a collection anomaly alarm is generated. Port timing data is written to the timing database via a message queue; Based on port time-series data and collected abnormal alarms, candidate alarm sets are generated according to threshold rules, baseline rules, trend rules, and composite logic rules and written into the port knowledge graph; Within a preset time window, the minimum cost root cause port set and explanation path are found for the candidate alarm set based on the port dependency subgraph. Suppression aggregation is performed on the candidate alarm set based on the root cause port set, and the root cause alarm set is generated. The port health score is calculated based on the root cause alarm set and the scoring weight, and the classification is completed based on the classification threshold. The notification is triggered to dispatch the work order and the work order processing result is obtained to form a feedback sample. The scoring weight and classification threshold are updated in the sliding time window using projective gradient descent and the upper limit of false alarm rate and the upper limit of false alarm rate are satisfied to generate the weight version number.

[0008] Optionally, configuring the SNMP collection template and distributing it in batches via the Web interface specifically includes: Create an SNMP data collection template in the web interface, generate a data collection template identifier, and set the data collection template version number; Configure the SNMP version field corresponding to the data collection template in the web interface; When the SNMP version field is set to SNMPv2c, configure the community string, target port number, timeout duration, and number of retries in the web interface; When the SNMP version field is set to SNMPv3, configure the security username, authentication protocol, authentication password, encryption protocol, and encryption password in the web interface. Configure the Trap receiver parameters and set the Trap trigger conditions in the web interface. The Trap receiver parameters include the receiver address and receiver port. Configure the OID list in the web interface and establish the correspondence between OIDs and port status indicators and port performance indicators; Select a set of network device identifiers and send SNMP collection templates to the set of network device identifiers in batches, recording the sending status and sending timestamp.

[0009] Optionally, the construction of the port knowledge graph specifically includes: Obtain the network device identifier and port identifier, and establish the subordinate association between the network device identifier and port identifier; Create a port knowledge graph, write the network device entity corresponding to the network device identifier into the port knowledge graph, and write the port entity corresponding to the port identifier into the port knowledge graph. Based on the subordinate relationship, the subordinate relationship between network device entities and port entities is written into the port knowledge graph; Obtain port connection data, which includes port identifier pairs. Write port connection relationships into the port knowledge graph based on the port identifier pairs. Obtain protocol adjacency data, which includes port identifiers and adjacent port identifiers. Write protocol adjacency relationships into the port knowledge graph based on the port identifiers and adjacent port identifiers, and perform consistency verification to complete the construction of the port knowledge graph.

[0010] Optionally, the generation of the port dependency subgraph specifically includes: Extract a set of training triples from the port knowledge graph. Each training triple contains a head entity identifier, a relation identifier, and a tail entity identifier. The head entity identifier uses the port identifier, the tail entity identifier uses the port identifier, and the relation identifier uses the port connection relation identifier and the protocol adjacency relation identifier. Initialize entity vectors for port identifiers in the training triplet set, and initialize relation vectors for port connection relation identifiers and protocol adjacency relation identifiers. The dimensions of entity vectors and relation vectors are kept consistent. A set of negative sample triples is generated based on the training triple set. The set of negative sample triples includes head-replaced negative sample triples and tail-replaced negative sample triples. The head-replaced negative sample triples are obtained by replacing the head entity identifier in the training triples with a port identifier that is different from the tail entity identifier. The tail-replaced negative sample triples are obtained by replacing the tail entity identifier in the training triples with a port identifier that is different from the head entity identifier. TransE is used to train the embedding vectors and perform iterative updates. The iterative update aims to make the sum of the head entity vector and the relation vector close to the tail entity vector. The vector distance is calculated by summing the absolute values ​​of the differences in each dimension. During the iterative update, the entity vectors are normalized to the unit length. For port connection relationships and protocol adjacency relationships in the port knowledge graph, read the header entity vector, relationship vector, and tail entity vector and calculate the vector distance; Normalization is performed on the set of vector distances. The normalization process includes obtaining the minimum and maximum values ​​of the vector distances, and calculating the normalized distance for each vector distance. The normalized distance is obtained by subtracting the minimum value of the vector distance from the vector distance and dividing by the minimum value of the vector distance from the maximum value of the vector distance. Create a port dependency subgraph, which contains port identifier nodes and port dependency edge weights. Calculate the port dependency edge weight for each normalized distance in the normalized distance set. The port dependency edge weight is obtained by subtracting the normalized distance from 1. Write the port identifier pairs and port dependency edge weights into the port dependency subgraph and complete the generation of the port dependency subgraph.

[0011] Optionally, the process of retrying and generating acquisition anomaly alarms for failed generation and acquisition of port timing data according to the number of retries and retry intervals specifically includes: Read the SNMP collection template, obtain the list of port status indicators OID and the list of port performance indicators OID, generate a collection task, and associate the collection task with network device identifier, port identifier, polling period, and collection timestamp; When the collection timestamp arrives, an SNMP collection request is initiated based on the SNMP collection template. When the SNMP version field is SNMPv2c, an SNMP collection request is initiated based on the community string. When the SNMP version field is SNMPv3, an SNMP collection request is initiated based on the security username, authentication information, and encryption information. Receive SNMP collection response and parse the corresponding indicator values ​​in the port status indicator OID list and the port performance indicator OID list, and write the port identifier, OID, collection timestamp, and indicator value into the port time series data; When an SNMP data collection request fails, the number of retries and the retry interval are read from Redis. If the number of retries and the retry interval are missing from Redis, the number of retries and the retry interval are read from the database and written to Redis. Retry is performed according to the number of retries and the retry interval. The retry process involves binding the SNMP data collection request to the agent identifier. If a single retry fails, the agent identifier is updated and a retry is performed. When the maximum number of retries is reached, a data collection anomaly alarm is generated. The data collection anomaly alarm is associated with the network device identifier, port identifier, data collection timestamp, and failure type.

[0012] Optionally, the process of writing the port timing data into the timing database via a message queue specifically includes: Standardization processing is performed on port time-series data. This standardization process includes normalizing the port identifier field, normalizing the OID field, unifying the collection timestamp format, and unifying the unit of indicator values. A tracking identifier is generated based on the port identifier, OID, and collection timestamp, and the tracking identifier is written into the port time series data. The port time-series data written to the trace identifier is sent to the Kafka message queue, and the Kafka message queue performs partition writing according to the port identifier; Read port time-series data from the Kafka message queue and write it to the TimescaleDB time-series database. The fields written include network device identifier, port identifier, OID, collection timestamp, metric value, and tracking identifier. Create network device identifier index, port identifier index, OID index, and collection timestamp index in the TimescaleDB time series database; A collection log verification code is generated based on the port identifier, OID, collection timestamp, and indicator value. The collection log verification code is then associated with the tracking identifier and written into the collection log record.

[0013] Optionally, the generation of the candidate alarm set specifically includes: Read port timing data and collect abnormal alarms, and form a port indicator sequence according to port identifier within a preset time window; Threshold determination is performed according to threshold rules, which include OID, threshold parameters, and duration parameters. Threshold determination includes comparing the indicator values ​​in the port indicator sequence with the threshold parameters. When the comparison result remains true within the duration specified by the duration parameters, a threshold candidate alarm is generated. Baseline determination is performed according to baseline rules, which include baseline window parameters, deviation threshold parameters, and duration parameters. Baseline determination includes calculating baseline statistics and deviation within the time period specified by the baseline window parameters. When the deviation remains within the duration specified by the duration parameters, a baseline candidate alarm is generated. Trend determination is performed according to trend rules. Trend rules include trend window parameters, trend threshold parameters, and duration parameters. Trend determination includes calculating the change and trend strength within the time period limited by the trend window parameters. When the trend strength meets the trend threshold parameters within the duration limited by the duration parameters, a trend candidate alarm is generated. Based on threshold candidate alarms, baseline candidate alarms, trend candidate alarms, and collection anomaly alarms, a composite judgment is performed according to composite logic rules. The composite logic rules include AND logic, any true logic, and NOT logic. When the composite judgment meets the triggering conditions, a composite candidate alarm is generated. The candidate alarm set is formed by aggregating threshold candidate alarms, baseline candidate alarms, trend candidate alarms, and composite candidate alarms. The candidate alarm set is associated with the port identifier and trigger timestamp and written into the port knowledge graph.

[0014] Optionally, the generation of the root cause alarm set specifically includes: Read the port dependency subgraph and candidate alarm set, filter candidate alarms within a preset time window, and extract the port identifiers associated with the candidate alarms to form an alarm port set; In the port dependency subgraph, the interpretation path record is calculated for the alarm port set. The interpretation path record includes the starting port identifier, the ending port identifier, the interpretation path, and the interpretation path cost. The interpretation path is the directed path from the starting port identifier to the ending port identifier. The interpretation path cost is the sum of the weights of the port-dependent edges in the interpretation path. The ending port identifier is the port identifier within the alarm port set. The overriding relationship is defined based on the interpretation path record. The overriding relationship represents the interpretation path from the root cause port identifier to the alarm port identifier. The root cause port set is solved based on the coverage relationship. The root cause port set is a set of port identifiers. The coverage cost includes the cumulative cost of the interpretation path from the root cause port identifier to the alarm port identifier and the penalty term for the size of the root cause port set. The solution objective is to minimize the coverage cost and cover the alarm port set. Based on the root cause port set, the explanation path from the root cause port identifier to the alarm port identifier is selected from the explanation path record to form the explanation path set. Based on the root cause port set and the explanation path set, the candidate alarm set is suppressed and aggregated to generate the root cause alarm set. The root cause alarm set is associated with the root cause port identifier and the explanation path set.

[0015] Optionally, the generation of the calculation port health score and weight version number specifically includes: Based on the root cause alarm set, the root cause alarm features corresponding to the port identifier are extracted. The root cause alarm features include the importance of the network device, the scope of impact, and the duration. The root cause alarm features are weighted and aggregated based on the scoring weights, and a port health score is calculated. The port health score is associated with the port identifier and the trigger timestamp. Based on the graded threshold, the port health score is classified into grades, and the classification results are associated with the port identifier and written into the root cause alarm set. Based on the hierarchical classification results, a notification is triggered to dispatch work orders and generate work order identifiers. The work order identifiers are associated with port identifiers and root cause alarm sets. The work order identifier is used to obtain the work order processing result to form a feedback sample. The feedback sample includes the port identifier, port health score, hierarchical classification result, and work order processing result. Within the sliding time window, the false alarm rate and false negative rate are calculated based on the feedback samples. The scoring weights and classification thresholds are updated using projective gradient descent while satisfying the upper limits of the false alarm rate and false negative rate. The weight version number is generated and associated with the scoring weights and classification thresholds.

[0016] The beneficial effects of this invention are: This invention uses network ports as the core monitoring object and introduces a knowledge graph to uniformly model network devices, port connection relationships, and protocol adjacency relationships. This allows port-level status, performance indicators, and structural relationships to form a computable whole, thus overcoming the problem of existing device-level monitoring's difficulty in accurately locating faults. Based on port dependency subgraphs and embedded vector distances, the invention constructs the dependency strength between ports, enabling the structural propagation of alarms. This allows multiple alarms triggered by the same root cause to be identified and associated under a unified model, effectively reducing alarm redundancy and narrowing the fault location range.

[0017] This invention constructs a port-level root cause analysis and explanation mechanism in the alarm generation and handling process. By solving for the root cause port set with the minimum coverage cost within a preset time window and generating an explanation path, it achieves suppression and aggregation of candidate alarms, ensuring that the output root cause alarms have a clear structural basis and a reproducible explanation path. Combined with a port health scoring and classification mechanism, alarm results can be matched with the degree of business impact and fault persistence characteristics, improving the accuracy of alarm classification and the pertinence of operation and maintenance responses.

[0018] Furthermore, this invention incorporates work order processing results into the alarm scoring and grading threshold update process, constructing a closed-loop online calibration mechanism based on feedback samples. This allows the scoring weights and grading thresholds to be continuously adjusted according to operational status, maintaining the long-term effectiveness of the alarm strategy while constraining false alarm and false negative rates. This approach achieves adaptive evolution of the alarm strategy without altering the original data acquisition and storage architecture, improving the stability and intelligence of the network operation and maintenance system in complex environments. Attached Figure Description

[0019] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used in conjunction with embodiments of the invention to explain the invention and do not constitute a limitation thereof. In the drawings:

[0020] Figure 1 This is a flowchart of a network port status monitoring and early warning method based on knowledge graph proposed in this invention; Figure 2 This is a schematic diagram of the system layered architecture of a network port status monitoring and early warning method based on knowledge graph proposed in this invention; Figure 3 This is a schematic diagram of the front-end, back-end, and microservice component deployment of a knowledge graph-based network port status monitoring and early warning method proposed in this invention. Figure 4 This is a schematic diagram of the data processing flow for a knowledge graph-based network port status monitoring and early warning method proposed in this invention, including data acquisition queuing, preprocessing, alarm matching, and database entry. Figure 5 This is a flowchart illustrating the polling collection, retry, and anomaly alarm generation process of a knowledge graph-based network port status monitoring and early warning method proposed in this invention. Detailed Implementation

[0021] The present invention will now be described in further detail with reference to the accompanying drawings. These drawings are simplified schematic diagrams, illustrating only the basic structure of the invention, and therefore only show the components relevant to the invention.

[0022] refer to Figure 1-5 A knowledge graph-based method for network port status monitoring and early warning includes the following steps: Configure SNMP data collection templates and distribute them in batches via a web interface; Obtain network device identifiers and port identifiers, construct a port knowledge graph, and write port connection relationships and protocol adjacency relationships; Based on the port knowledge graph, TransE is used to train the embedding vectors, and the port dependency edge weights are calculated based on the vector distance to generate the port dependency subgraph. Based on the SNMP collection template, port status indicators and port performance indicators are collected according to the polling cycle, and port time sequence data is generated. If the collection fails, the collection is retried according to the number of retries and the retry interval, and a collection anomaly alarm is generated. Port timing data is written to the timing database via a message queue; Based on port time-series data and collected abnormal alarms, candidate alarm sets are generated according to threshold rules, baseline rules, trend rules, and composite logic rules and written into the port knowledge graph; Within a preset time window, the minimum cost root cause port set and explanation path are found for the candidate alarm set based on the port dependency subgraph. Suppression aggregation is performed on the candidate alarm set based on the root cause port set, and the root cause alarm set is generated. The port health score is calculated based on the root cause alarm set and the scoring weight, and the classification is completed based on the classification threshold. The notification is triggered to dispatch the work order and the work order processing result is obtained to form a feedback sample. The scoring weight and classification threshold are updated in the sliding time window using projective gradient descent and the upper limit of false alarm rate and the upper limit of false alarm rate are satisfied to generate the weight version number.

[0023] In this embodiment, configuring the SNMP collection template and distributing it in batches via the Web interface specifically includes: Initiate the creation of an SNMP collection template operation in the web interface, receive the template name and template remarks, generate a collection template identifier and write it to the template storage record. The collection template identifier is generated using the UUID generation rule. Set the collection template version number, which includes the major version number and the revision version number. The major version number is initialized to 1 and the revision version number is initialized to 0. In the Web interface, the SNMP version field is set. The SNMP version field is written to the template storage record corresponding to the collection template identifier. The value of the SNMP version field is limited to SNMPv2c and SNMPv3. When the SNMP version field is set to SNMPv2c, configure the community string, target port number, timeout duration, and number of retries in the Web interface. Write the community string into the SNMPv2c parameter field, the target port number into the transmission port field, the timeout duration into the timeout field, and the number of retries into the retry field. The timeout duration is measured in milliseconds and must be greater than 0. The number of retries must be greater than or equal to 0. When the SNMP version field is set to SNMPv3, configure the security username, authentication protocol, authentication password, encryption protocol, and encryption password in the web interface. The security username is written to the security username field, the authentication protocol is written to the authentication protocol field, the authentication password is written to the authentication password field, the encryption protocol is written to the encryption protocol field, and the encryption password is written to the encryption password field. The authentication protocol value is limited to HMAC-MD5 and HMAC-SHA series identifiers, and the encryption protocol value is limited to DES and AES series identifiers. Configure Trap receiver parameters and set Trap trigger conditions in the web interface. Trap receiver parameters include receiver address and receiver port. Receiver address is written to the receiver address field, receiver port is written to the receiver port field, and Trap trigger conditions are written to the trigger condition field. The trigger condition field includes trigger OID, trigger comparison operator, trigger threshold, and trigger duration. Trigger OID is selected from the OID list, and the trigger comparison operator is limited to values ​​of greater than, less than, equal to, within the range, and outside the range. Configure the OID list in the web interface and establish the correspondence between OID and port status indicators and port performance indicators. The OID list consists of a set of OID entries. Each OID entry contains an OID string, indicator name, and indicator category field. The indicator category field takes the values ​​of port status indicator and port performance indicator. The OID entries are written to the OID mapping table record corresponding to the collection template identifier. In the web interface, select the network device identifier set and execute the batch distribution of SNMP collection templates. Generate a distribution task identifier and write it to the distribution task record. The distribution task record includes the collection template identifier, collection template version number, network device identifier set, distribution status, and distribution timestamp. The distribution status is limited to pending distribution, distribution in progress, distribution successful, and distribution failed. During the distribution process, a distribution command is sent to the network device identifier set, carrying the collection template identifier and collection template version number. When the distribution is successful, the distribution status is updated to distribution successful. When the distribution fails, the distribution status is updated to distribution failed and the failure reason field is recorded.

[0024] In this embodiment, the construction of the port knowledge graph specifically includes: Obtain the network device identifier and port identifier, read the network device identifier field and port identifier field from the network device asset record, and establish a subordinate association table based on the network device identifier field and port identifier field. Each record in the subordinate association table contains the network device identifier and port identifier. Create a port knowledge graph, establish a port knowledge graph instance and initialize the entity set and relationship set. Write the network device entity corresponding to the network device identifier into the entity set and write the network device identifier into the network device entity identifier field. Write the port entity corresponding to the port identifier into the entity set and write the port identifier into the port entity identifier field. Based on the subordinate association table, a subordinate relationship is written into the relationship set. The subordinate relationship record contains the network device identifier and the port identifier. When writing, the starting identifier of the subordinate relationship is set to the network device identifier, and the ending identifier of the subordinate relationship is set to the port identifier. Get port connection data. The port connection data includes port identifier pairs. Each port identifier pair consists of the local port identifier and the peer port identifier. Write port connection relationships into the relationship set based on the port identifier pairs. The port connection relationship record includes the local port identifier and the peer port identifier. Obtain protocol adjacency data, which includes port identifiers and adjacent port identifiers. Write protocol adjacency relationships into the relationship set based on the port identifiers and adjacent port identifiers. The protocol adjacency relationship record includes port identifiers and adjacent port identifiers. Perform consistency verification, which includes verification of the existence of network device identifiers, port identifiers, port connection relationship port identifiers, and protocol adjacency relationship port identifiers. When the consistency verification passes, submit the port knowledge graph construction and write it into the graph storage record.

[0025] In this embodiment, the generation of the port dependency subgraph specifically includes: The port connection relationship and protocol adjacency relationship are read from the port knowledge graph. For each port connection relationship and each protocol adjacency relationship, a training triple is generated. The training triple consists of a head entity identifier, a relationship identifier, and a tail entity identifier. The head entity identifier is taken from the port identifier of the start point of the relationship, the tail entity identifier is taken from the port identifier of the end point of the relationship, and the relationship identifier is taken from the port connection relationship identifier or the protocol adjacency relationship identifier. The training triples are summarized to form a training triple set. An entity vector table is established for each port identifier involved in the training triplet set. The entity vector table uses the port identifier as an index. An entity vector storage unit is created for each port identifier and the initial value of the entity vector is written into it. A relation vector table is established for port connection relation identifiers and protocol adjacency relation identifiers. The relation vector table uses the relation identifier as an index. A relation vector storage unit is created for each relation identifier and the initial value of the relation vector is written into it. The entity vectors and relation vectors use the same dimension value to meet the need for dimension-by-dimensional calculation of vector components during iterative updates. The initial values ​​of entity vectors and relation vectors are generated using pseudo-random number generation rules. The pseudo-random number generation rules use a fixed random seed to ensure that the same acquisition template version number corresponds to the same initialization result. The pseudo-random number generation rules generate an initial component in each dimension and write it into the corresponding vector component in sequence. After initialization, the entity vectors are normalized by unit length and written back to the entity vector table. The initial values ​​of the relation vectors are retained for iterative updates. For each training triplet set, negative sample triplets are generated. The negative sample triplet set includes head-replaced negative sample triplets and tail-replaced negative sample triplets. Head-replaced negative sample triplets are obtained by keeping the relation identifier and tail entity identifier unchanged in the training triplets and replacing the head entity identifier with a port identifier that is different from the tail entity identifier. Tail-replaced negative sample triplets are obtained by keeping the relation identifier and head entity identifier unchanged in the training triplets and replacing the tail entity identifier with a port identifier that is different from the head entity identifier. Head-replaced negative sample triplets and tail-replaced negative sample triplets are combined to form the negative sample triplet set. TransE is used to train embedding vectors and perform iterative updates. For each training triplet in the training triplet set, the head entity vector, relation vector, and tail entity vector are read and the vector distance is calculated. The vector distance is calculated by adding the head entity vector component and the relation vector component for each dimension, subtracting the absolute value of the difference between the tail entity vector component and summing the results across all dimensions to obtain the training distance. For each negative sample triplet in the negative sample triplet set, the negative sample distance is calculated in the same way. Based on the training distance and the negative sample distance, iterative updates are performed to update the entity vector and relation vector. During the iterative update process, unit length normalization is performed on the entity vector corresponding to each port identifier. Unit length normalization is achieved by summing the square roots of the squares of the entity vector components to obtain the length and then dividing each component by the length. For each port connection relationship and each protocol adjacency relationship in the port knowledge graph, the starting port identifier, relationship identifier, and ending port identifier of the relationship are read, and the corresponding header entity vector, relationship vector, and tail entity vector are read. The vector distance is calculated using the vector distance calculation method, and a vector distance set is formed. The minimum and maximum vector distances are calculated in the vector distance set. For each vector distance in the vector distance set, the normalized distance is calculated. The normalized distance is obtained by subtracting the minimum vector distance from the vector distance and dividing by the minimum vector distance from the maximum vector distance. The port dependency subgraph adopts a weighted directed graph structure. It contains a node set and an edge set. The node set consists of port identifiers, and the edge set consists of pairs of port identifiers. Each edge records the starting port identifier, the ending port identifier, and the port dependency weight. The port dependency subgraph generation process includes creating a port dependency subgraph storage instance and initializing the node and edge sets; writing the port identifiers appearing in the port knowledge graph into the node set; forming a port identifier pair by combining the starting and ending port identifiers of each record in the vector distance set; reading the normalized distance corresponding to the port identifier pair and calculating the port dependency weight. The port dependency weight is defined as 1 minus the normalized distance, with the normalized distance ranging from 0 to 1. When the normalized distance is 0, the port dependency weight is 1; when the normalized distance is 1, the port dependency weight is 0. The port identifier pairs and port dependency weights are written into the edge set. When a port identifier pair appears repeatedly in the edge set, the port dependency weight takes the larger value, thus completing the port dependency subgraph generation.

[0026] In this embodiment, the process of retrying and generating acquisition anomaly alarms based on the number of retries and retry intervals when the generation and acquisition of port timing data fail specifically includes: The system reads the template storage record corresponding to the SNMP collection template, obtains the port status indicator OID list and the port performance indicator OID list, reads the network device identifier corresponding to the network device importance and uses it as the port importance, counts candidate alarm sets based on the port identifier in a sliding time window to obtain the alarm activity, and calculates the mean of adjacent differences between indicator values ​​in the port time series data based on the port identifier in a sliding time window to obtain the indicator fluctuation range. The system determines the polling period based on the port importance, alarm activity, and indicator fluctuation range and limits the polling period to 5s to 300s. The system generates a collection task record based on the network device identifier and port identifier. The collection task record includes the network device identifier, port identifier, polling period, collection timestamp, port status indicator OID list, and port performance indicator OID list. The collection timestamp is generated and written to the collection task record in alignment with the polling period. When the collection timestamp arrives, the SNMP collection template parameters are read from the collection task record and the SNMP collection request message is assembled. When the SNMP version field is SNMPv2c, the community string is written into the corresponding field of the SNMP collection request message and the target port number is set. When the SNMP version field is SNMPv3, the security username, authentication information, and encryption information are written into the corresponding field of the SNMP collection request message and the authentication mode and encryption mode are set. The SNMP collection request message is sent to the device address corresponding to the network device identifier and the request initiation time is recorded. Receive SNMP collection response messages and verify the consistency between the response messages and the collection task records in terms of network device identifier and collection timestamp. Parse the response messages to obtain the corresponding indicator values ​​of the port status indicator OID list and the corresponding indicator values ​​of the port performance indicator OID list. Generate port time-series data records for each OID. The port time-series data records include port identifier, OID, collection timestamp, and indicator value. The port time-series data records are written to the port time-series data buffer in the order of collection timestamp. If an SNMP collection request fails to receive an SNMP collection response within the timeout period, the SNMP collection request is deemed to have failed. The process of reading the retry count and retry interval from Redis includes generating a cache query key and executing the query. The cache query key is generated by concatenating the SNMP collection template identifier and the network device identifier. The value field of the cache record in Redis contains the retry count and retry interval. If the Redis query does not return a cache record, the retry count and retry interval corresponding to the SNMP collection template identifier are read from the database and written to Redis. At the same time, the retry count and retry interval are written to the collection task record. Retry is performed according to the number of retries and the retry interval. The retry process is as follows: the SNMP collection request is bound to the agent identifier, the agent identifier is selected from the agent identifier pool and written into the collection task record, and before each retry, the next retry timestamp is calculated based on the retry interval and waited for it to arrive. If a single retry fails, the agent identifier is updated and the SNMP collection request message is reassembled to initiate a retry. Retrying stops when the retry count reaches the number of retries. When the retry count reaches the required number of retries, a data collection anomaly alarm is generated and written to the data collection anomaly alarm record. The data collection anomaly alarm record includes the network device identifier, port identifier, data collection timestamp, and failure type. The failure type consists of one of the following: timeout failure, authentication failure, encryption failure, or connection failure.

[0027] In this embodiment, the process of writing the port timing data into the timing database via a message queue specifically includes: Standardization processing is performed on port time-series data. The standardization process is performed one by one on each port time-series data record. The port identifier field standardization includes converting the port identifier into a preset format and verifying the subordinate association between the port identifier and the network device identifier. The OID field standardization includes converting the OID into a dotted decimal string format and verifying that the OID belongs to the SNMP collection template configuration OID set. The collection timestamp format standardization includes converting the collection timestamp into a millisecond timestamp format. The indicator value unit standardization includes performing unit conversion on the indicator value according to the unit rules corresponding to the OID and writing the conversion result back to the port time-series data record. The tracking identifier is generated based on the port identifier, OID, and collection timestamp. The tracking identifier generation process includes concatenating the port identifier, OID, and collection timestamp in a preset order to form a tracking source string, performing a hash calculation on the tracking source string to generate the tracking identifier, and writing the tracking identifier into the tracking identifier field of the port time series data record. The port time-series data with the trace identifier is sent to the Kafka message queue. The sending process includes constructing a message body and writing the port identifier, OID, collection timestamp, metric value, and trace identifier into the message body fields. The port identifier is used as the partition key to select the Kafka partition and write it into the message queue. The trace identifier is written into the sending log record. The process involves reading port time-series data from the Kafka message queue and writing it to the TimescaleDB time-series database. The reading process includes subscribing to Kafka partitions and reading message body fields in the order of message offsets. The writing process includes writing network device identifier, port identifier, OID, collection timestamp, metric value, and tracking identifier to the time-series table record in the TimescaleDB time-series database. The time-series table record uses the collection timestamp as the time field. In the TimescaleDB time series database, network device identifier index, port identifier index, OID index, and collection timestamp index are created. The index creation process includes creating indexes on the corresponding fields of the time series table and writing them into the index metadata records. The collection log verification code is generated based on the port identifier, OID, collection timestamp, and indicator value. The collection log verification code generation process includes concatenating the port identifier, OID, collection timestamp, and indicator value in a preset order to form a verification source string, performing a hash calculation on the verification source string to generate the collection log verification code, and writing the tracking identifier and collection log verification code into the collection log record. The collection log record includes a tracking identifier field and a collection log verification code field.

[0028] In this embodiment, the generation of the candidate alarm set specifically includes: Read port time series data from the time series database and read collection anomaly alarm records. Filter port time series data records covered by a preset time window based on port identifier. Sort port time series data records by collection timestamp to form port indicator sequence. Sort collection anomaly alarm records by occurrence timestamp to form anomaly sequence. Threshold determination is performed according to threshold rules. Threshold rules include OID, threshold parameters, and duration parameters. For the OID corresponding to the threshold rule, the indicator value sequence is extracted from the port indicator sequence. Each indicator value is compared with the threshold parameter and a determination sequence is generated. When the duration of consecutive determination sequences reaches the duration parameter, a threshold candidate alarm is generated. The threshold candidate alarm record includes port identifier, OID, trigger timestamp, and threshold rule identifier. Baseline determination is performed according to baseline rules, which include baseline window parameters, deviation threshold parameters, and duration parameters. For the OID corresponding to the baseline rule, the indicator value sequence is extracted from the port indicator sequence. Within the time period limited by the baseline window parameters, indicator value samples are selected to calculate the baseline statistics. The baseline statistics include the baseline mean and the baseline standard deviation. The deviation is calculated based on the indicator value and the baseline mean, and a deviation sequence is generated. When the deviation sequence continuously meets the deviation threshold parameter for a duration that reaches the duration parameter, a baseline candidate alarm is generated. The baseline candidate alarm record includes the port identifier, OID, trigger timestamp, and baseline rule identifier. Trend determination is performed according to trend rules. Trend rules include trend window parameters, trend threshold parameters, and duration parameters. For the OID corresponding to the trend rule, the indicator value sequence is extracted from the port indicator sequence. Within the time period limited by the trend window parameter, the indicator value at the beginning and end of the time window is selected to calculate the change. The change is divided by the time window length to obtain the trend strength and generate a trend strength sequence. When the trend strength sequence continuously satisfies the trend threshold parameter for a duration that reaches the duration parameter, a trend candidate alarm is generated. The trend candidate alarm record includes port identifier, OID, trigger timestamp, and trend rule identifier. Based on threshold candidate alarms, baseline candidate alarms, trend candidate alarms, and acquisition anomaly alarms, a composite judgment is performed according to composite logic rules. The composite judgment is processed separately according to port identifiers. A set of trigger timestamps is generated within a preset time window. The set of trigger timestamps is obtained by merging the trigger timestamps of threshold candidate alarms, baseline candidate alarms, trend candidate alarms, and acquisition anomaly alarms. A time alignment window is established for each trigger timestamp in the set of trigger timestamps. When a threshold candidate alarm exists in the time alignment window, the threshold condition is set to true. When a baseline candidate alarm exists in the time alignment window, the baseline condition is set to true. When a trend candidate alarm exists in the time alignment window, the trend condition is set to true. When an acquisition anomaly alarm exists in the time alignment window, the anomaly condition is set to true. The threshold condition, baseline condition, trend condition, and anomaly condition are subjected to AND logical operation, any true logical operation, and NOT logical operation according to composite logic rules. When the operation result meets the trigger condition, a composite candidate alarm is generated. The composite candidate alarm record contains port identifier, trigger timestamp, and composite logic rule identifier. The candidate alarm set is formed by aggregating threshold candidate alarms, baseline candidate alarms, trend candidate alarms, and composite candidate alarms. The candidate alarm set is grouped by port identifier and a candidate alarm identifier is generated. The candidate alarm identifier, port identifier, trigger timestamp, rule identifier, and alarm type are written into the port knowledge graph.

[0029] In this embodiment, the generation of the root cause alarm set specifically includes: Read the port dependency subgraph and candidate alarm set. The port dependency subgraph contains port identifier nodes and port dependency edge weights. The candidate alarm set contains port identifiers and trigger timestamps. Filter candidate alarm records covered by a preset time window, extract the port identifiers associated with the candidate alarm records, and remove duplicates to form an alarm port set. In the port dependency subgraph, an explanation path record is calculated for the alarm port set. The explanation path record includes the starting port identifier, the ending port identifier, the explanation path, and the explanation path cost. The ending port identifier is taken from the port identifier in the alarm port set, and the starting port identifier is taken from the port identifier in the port dependency subgraph. A directed path search is performed for each starting port identifier and the ending port identifier. The path search calculates the path cost by accumulating the weights of the port dependency edges. The directed path with the minimum path cost is selected as the explanation path, and the starting port identifier, the ending port identifier, the explanation path, and the explanation path cost are written into the explanation path record. Overlay relationships are defined based on the interpretation path record. Overlay relationships are established according to the interpretation path record. Overlay relationships include the starting port identifier and the ending port identifier. Overlay relationships indicate that the starting port identifier reaches the ending port identifier through the interpretation path. The root cause port set is solved based on the coverage relationship. The root cause port set is a set of port identifiers. The coverage cost includes an explanation path cost accumulation term and a root cause port set size penalty term. The explanation path cost accumulation term is obtained by accumulating the explanation path costs from the root cause port identifier to the alarm port identifier. The root cause port set size penalty term is obtained by multiplying the number of port identifiers in the root cause port set by the penalty coefficient. The solution process includes initializing the root cause port set as an empty set and the uncovered alarm port set as an alarm port set. Iteratively selecting port identifiers that reduce the coverage cost after being added to the root cause port set and updating the uncovered alarm port set. When the uncovered alarm port set is empty, the root cause port set is output. Based on the root cause port set, interpretable paths are selected from the interpretable path records whose starting port identifier belongs to the root cause port set and whose ending port identifier belongs to the alarm port set to form an interpretable path set. Based on the root cause port set and the interpretable path set, suppression aggregation is performed on the candidate alarm set. Suppression aggregation includes associating candidate alarm records whose port identifiers in the candidate alarm set belong to the alarm port set with port identifiers in the root cause port set and marking them with suppression identifiers. The candidate alarm records are aggregated to generate the root cause alarm set. The root cause alarm set records include the root cause port identifier, the trigger timestamp, and the interpretable path set identifier.

[0030] In this embodiment, the generation of the calculation port health score and weight version number specifically includes: Based on the root cause alarm set, the root cause alarm records are traversed by port identifier. The trigger timestamp and the set of interpretation paths are read from the root cause alarm records. The network device identifier is associated with the port identifier and the importance of the network device is read. The scope of impact is obtained by counting the port identifiers included in the set of interpretation paths. The duration is calculated by the time span during which the root cause alarm record remains in the triggered state within the sliding time window. The root cause alarm characteristics are formed and associated with the port identifier and the trigger timestamp. Read the scoring weights and perform weighted summation on the root cause alarm features. The importance of network devices, the scope of impact, and the duration are multiplied by the corresponding weights in the scoring weights and then summed to obtain the port health score. The port health score is written to the scoring record corresponding to the port identifier and associated with the trigger timestamp. Read the classification threshold and perform interval determination on the port health score. The interval determination compares the port health score with the classification threshold to obtain the classification result. The classification result is written into the root cause alarm set and associated with the port identifier and trigger timestamp. The notification and dispatch process is triggered based on the hierarchical classification results. The notification and dispatch process generates a work order identifier and writes it into the work order record. The work order record is associated with the port identifier and the root cause alarm set. Obtain the work order identifier corresponding to the work order processing result and write it into the feedback sample. The feedback sample includes the port identifier, port health score, classification result, and work order processing result. The work order processing result identifier includes the fault confirmation identifier and the fault resolution identifier. Within a sliding time window, the false alarm rate and false negative rate are statistically calculated based on feedback samples. The false alarm rate is obtained by dividing the number of troubleshooting identifiers by the number of feedback samples, and the false negative rate is obtained by dividing the number of confirmed fault identifiers and the number of classification results below the preset alarm level by the number of confirmed fault identifiers. The scoring weights and classification thresholds are updated using projective gradient descent. The update process includes calculating the gradient of the objective function based on feedback samples and updating the scoring weights and classification thresholds according to the learning rate. The projection process includes adjusting the scoring weights and classification thresholds so that the false alarm rate does not exceed the upper limit of the false alarm rate and the false negative rate does not exceed the upper limit of the false negative rate. A weight version number is generated and a correlation record is established between the weight version number and the scoring weight and classification threshold.

[0031] Example 1: To verify the feasibility of this invention in practice, it was applied to a hybrid network environment of a large campus network and a data center. The network consists of core switching equipment, aggregation switching equipment, access switching equipment, and border routing equipment, with 520 managed devices and 12,480 managed ports. Port types cover 10 Gigabit uplink ports, Gigabit access ports, and link aggregation ports. The service load exhibits obvious tidal characteristics, and common port-side anomalies include port jitter, sudden increases in packet error counts, single-port congestion, and inconsistent status of link aggregation member ports. Existing maintenance methods mainly rely on device-level monitoring and static threshold alarms. Alarms often manifest as abnormal overall device indicators, and port-level anomalies are easily masked by system-wide statistics. When short-term fluctuations occur in links, adjacent ports trigger alarms intensively within a similar time window. Maintenance personnel need to repeatedly check the topology, review logs, and compare port indicators to locate the actual fault point, resulting in frequent mis-dispatch and duplicate dispatching. The system adopted in this embodiment is organized in layers according to port monitoring, data collection, data processing, alarm and automatic handling, and visualization. The overall layered relationship and alarm handling location can be found in [reference needed]. Figure 2 From the collection of port metrics to alarm triggering and order dispatch, a closed-loop link is formed.

[0032] In this scenario, operations and maintenance personnel configure SNMP data collection templates via a web interface and distribute them in batches to managed devices. The templates maintain OID mappings between port status metrics and port performance metrics, and are configured with version numbers for tracking and rollback. The platform maintains network device identifiers and port identifiers in asset records, and obtains port connection data based on topology discovery results and protocol adjacency data based on protocol detection results. This allows for the construction of a port knowledge graph, which is then written into port connection and protocol adjacency relationships, providing a unified foundation for port structure relationships and port metrics. For details on the service boundaries and component deployment methods of the system's front-end and back-end, as well as its data collection, alarm, and configuration capabilities, please refer to [link to relevant documentation]. Figure 3Data collection scheduling, data collection and storage, alarm matching, and process dispatch are handled by different services. Kafka, Redis, and TimescaleDB serve as key components to ensure data collection throughput and storage query capabilities. To characterize the dependency propagation relationship between ports, the platform extracts a set of training triples from the port knowledge graph, uses TransE to train embedding vectors, obtains normalized distances based on vector distances and maps them to port dependency edge weights, and generates a port dependency subgraph, providing a computational graph basis for root cause analysis and explanation path calculation.

[0033] During the polling data collection phase, the platform triggers collection tasks according to the polling cycle and aligns the collection timestamps. When a collection request fails, retries are performed according to the number of retries and the retry interval. During the retry process, the proxy identifier is switched to avoid single collection exit limitations. Retry parameters are first read from Redis. If Redis is not found, the parameters are retrieved from the database and written back to Redis to ensure consistent parameter sources and controllable read costs. The raw port metrics enter the message queue from the collection end, and the processing pipeline for preprocessing, alarm matching, and database writing can be found in [link to relevant documentation]. Figure 4 Port time-series data is written to the TimescaleDB time-series database via a message queue. An index is built around the network device identifier, port identifier, OID, and collection timestamp to support time-window retrieval. When collection failures reach the retry limit, a collection anomaly alarm is generated. Collection anomaly alarms and port time-series data participate in alarm judgment within the same time window to avoid misjudgments due to data loss alone. The branches and anomaly closure loops of collection retries can be found at the process level. Figure 5 Starting from "round-robin data collection", the process proceeds through "Redis to obtain retry configuration" to enter the retry and counting branch. Successful paths push data to Kafka and store it in the database, while failed paths generate collection anomaly alarms and proceed to subsequent alarm policy judgment, thus providing a traceable process basis for collection reliability and data pipeline connection.

[0034] To verify the effectiveness of port-level alarms and root cause analysis, the statistical period was 30 consecutive days of operation. Collected metrics covered 18 types of port indicators, including port Up / Down status, inbound traffic, outbound traffic, packet loss count, packet error count, CRC error count, and port bandwidth utilization. Threshold rules were triggered when bandwidth utilization exceeded 90% for 300 seconds. Baseline rules were triggered when the relative baseline mean deviated from the baseline mean by more than 3 times the baseline standard deviation for 180 seconds. Trend rules were calculated by adjusting the change within the trend window to reflect the trend strength. The alarm is triggered when the threshold is exceeded and the duration is 120 seconds. The composite logic rules, within the time-aligned window of the same port identifier, perform AND logic, any true logic, and NOT logic combination judgments on threshold conditions, baseline conditions, trend conditions, and abnormal conditions. Compared to traditional device-level alarm schemes, the total number of candidate alarm events in this invention is 39210. After solving the root cause port set with the minimum cost through port dependency subgraph solution and suppressing aggregation, the output root cause alarm set is 6480, achieving an alarm compression ratio of 6.05. The total number of alarm events in the traditional scheme is 42630, of which 42630 are manually reviewed. 27,980 alarms were identified as duplicates and cascading. Fault location efficiency, measured by the time from the first alarm occurrence to pinpointing the specific port, showed that the traditional method had an average time of 18.7 minutes and a median of 15.3 minutes, while the proposed method had an average time of 5.2 minutes and a median of 4.6 minutes. The root cause port and explanation path can be directly provided in the alarm details, reducing the need for manual topology checks and metric comparisons. Data collection continuity was measured by the port time-series data missing rate. The traditional method, however, showed a lower rate of missing data under network jitter conditions. The failure rate was 3.8%, while the failure rate of the proposed solution was 0.9%. The abnormal acquisition alarm can be used to distinguish between "port indicator abnormality" and "acquisition link abnormality". In terms of closed-loop calibration, the notification dispatch generates a work order and collects the processing results to form a feedback sample. The projected gradient descent updates the scoring weights and classification thresholds within the sliding time window and meets the upper limits of the false alarm rate and the false negative rate. The false alarm rate decreased from 6.4% to 2.1%, and the false negative rate decreased from 5.7% to 2.4%. The scoring weight version number is used to track the batch of policy updates, which is convenient for auditing and backtracking analysis.

[0035] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any equivalent substitutions or modifications made by those skilled in the art within the scope of the technology disclosed in the present invention, based on the technical solution and inventive concept of the present invention, should be covered within the scope of protection of the present invention.

Claims

1. A method for monitoring and early warning of network port status based on knowledge graphs, characterized in that, Includes the following steps: Configure SNMP data collection templates and distribute them in batches via a web interface; Obtain network device identifiers and port identifiers, construct a port knowledge graph, and write port connection relationships and protocol adjacency relationships; Based on the port knowledge graph, TransE is used to train the embedding vectors, and the port dependency edge weights are calculated based on the vector distance to generate the port dependency subgraph. Based on the SNMP collection template, port status indicators and port performance indicators are collected according to the polling cycle, and port time sequence data is generated. If the collection fails, the collection is retried according to the number of retries and the retry interval, and a collection anomaly alarm is generated. Port timing data is written to the timing database via a message queue; Based on port time-series data and collected abnormal alarms, candidate alarm sets are generated according to threshold rules, baseline rules, trend rules, and composite logic rules and written into the port knowledge graph; Within a preset time window, the minimum cost root cause port set and explanation path are found for the candidate alarm set based on the port dependency subgraph. Suppression aggregation is performed on the candidate alarm set based on the root cause port set, and the root cause alarm set is generated. The port health score is calculated based on the root cause alarm set and the scoring weight, and the classification is completed based on the classification threshold. The notification is triggered to dispatch the work order and the work order processing result is obtained to form a feedback sample. The scoring weight and classification threshold are updated in the sliding time window using projective gradient descent and the upper limit of false alarm rate and the upper limit of false alarm rate are satisfied to generate the weight version number.

2. The network port status monitoring and early warning method based on knowledge graphs according to claim 1, characterized in that, The specific steps of configuring SNMP collection templates and batch distributing them via a web interface include: Create an SNMP data collection template in the web interface, generate a data collection template identifier, and set the data collection template version number; Configure the SNMP version field corresponding to the data collection template in the web interface; When the SNMP version field is set to SNMPv2c, configure the community string, target port number, timeout duration, and number of retries in the web interface; When the SNMP version field is set to SNMPv3, configure the security username, authentication protocol, authentication password, encryption protocol, and encryption password in the web interface. Configure the Trap receiver parameters and set the Trap trigger conditions in the web interface. The Trap receiver parameters include the receiver address and receiver port. Configure the OID list in the web interface and establish the correspondence between OIDs and port status indicators and port performance indicators; Select a set of network device identifiers and send SNMP collection templates to the set of network device identifiers in batches, recording the sending status and sending timestamp.

3. The network port status monitoring and early warning method based on knowledge graphs according to claim 1, characterized in that, The construction of the port knowledge graph specifically includes: Obtain the network device identifier and port identifier, and establish the subordinate association between the network device identifier and port identifier; Create a port knowledge graph, write the network device entity corresponding to the network device identifier into the port knowledge graph, and write the port entity corresponding to the port identifier into the port knowledge graph. Based on the subordinate relationship, the subordinate relationship between network device entities and port entities is written into the port knowledge graph; Obtain port connection data, which includes port identifier pairs. Write port connection relationships into the port knowledge graph based on the port identifier pairs. Obtain protocol adjacency data, which includes port identifiers and adjacent port identifiers. Write protocol adjacency relationships into the port knowledge graph based on the port identifiers and adjacent port identifiers, and perform consistency verification to complete the construction of the port knowledge graph.

4. The network port status monitoring and early warning method based on knowledge graphs according to claim 1, characterized in that, The generation of the port dependency subgraph specifically includes: Extract a set of training triples from the port knowledge graph. Each training triple contains a head entity identifier, a relation identifier, and a tail entity identifier. The head entity identifier uses the port identifier, the tail entity identifier uses the port identifier, and the relation identifier uses the port connection relation identifier and the protocol adjacency relation identifier. Initialize entity vectors for port identifiers in the training triplet set, and initialize relation vectors for port connection relation identifiers and protocol adjacency relation identifiers. The dimensions of entity vectors and relation vectors are kept consistent. A set of negative sample triples is generated based on the training triple set. The set of negative sample triples includes head-replaced negative sample triples and tail-replaced negative sample triples. The head-replaced negative sample triples are obtained by replacing the head entity identifier in the training triples with a port identifier that is different from the tail entity identifier. The tail-replaced negative sample triples are obtained by replacing the tail entity identifier in the training triples with a port identifier that is different from the head entity identifier. TransE is used to train the embedding vectors and perform iterative updates. The iterative update aims to make the sum of the head entity vector and the relation vector close to the tail entity vector. The vector distance is calculated by summing the absolute values ​​of the differences in each dimension. During the iterative update, the entity vectors are normalized to the unit length. For port connection relationships and protocol adjacency relationships in the port knowledge graph, read the header entity vector, relationship vector, and tail entity vector and calculate the vector distance; Normalization is performed on the set of vector distances. The normalization process includes obtaining the minimum and maximum values ​​of the vector distances, and calculating the normalized distance for each vector distance. The normalized distance is obtained by subtracting the minimum value of the vector distance from the vector distance and dividing by the minimum value of the vector distance from the maximum value of the vector distance. Create a port dependency subgraph, which contains port identifier nodes and port dependency edge weights. Calculate the port dependency edge weight for each normalized distance in the normalized distance set. The port dependency edge weight is obtained by subtracting the normalized distance from 1. Write the port identifier pairs and port dependency edge weights into the port dependency subgraph and complete the generation of the port dependency subgraph.

5. The network port status monitoring and early warning method based on knowledge graphs according to claim 1, characterized in that, The failure to generate and acquire port timing data specifically includes retrying according to the number of retries and the retry interval, and generating an acquisition anomaly alarm. Read the SNMP collection template, obtain the list of port status indicators OID and the list of port performance indicators OID, generate a collection task, and associate the collection task with network device identifier, port identifier, polling period, and collection timestamp; When the collection timestamp arrives, an SNMP collection request is initiated based on the SNMP collection template. When the SNMP version field is SNMPv2c, an SNMP collection request is initiated based on the community string. When the SNMP version field is SNMPv3, an SNMP collection request is initiated based on the security username, authentication information, and encryption information. Receive SNMP collection response and parse the corresponding indicator values ​​in the port status indicator OID list and the port performance indicator OID list, and write the port identifier, OID, collection timestamp, and indicator value into the port time series data; When an SNMP data collection request fails, the number of retries and the retry interval are read from Redis. If the number of retries and the retry interval are missing from Redis, the number of retries and the retry interval are read from the database and written to Redis. Retry is performed according to the number of retries and the retry interval. The retry process involves binding the SNMP data collection request to the agent identifier. If a single retry fails, the agent identifier is updated and a retry is performed. When the maximum number of retries is reached, a data collection anomaly alarm is generated. The data collection anomaly alarm is associated with the network device identifier, port identifier, data collection timestamp, and failure type.

6. The network port status monitoring and early warning method based on knowledge graph according to claim 1, characterized in that, The process of writing the port timing data into the timing database via a message queue specifically includes: Standardization processing is performed on port time-series data. This standardization process includes normalizing the port identifier field, normalizing the OID field, unifying the collection timestamp format, and unifying the unit of indicator values. A tracking identifier is generated based on the port identifier, OID, and collection timestamp, and the tracking identifier is written into the port time series data. The port time-series data written to the trace identifier is sent to the Kafka message queue, and the Kafka message queue performs partition writing according to the port identifier; Read port time-series data from the Kafka message queue and write it to the TimescaleDB time-series database. The fields written include network device identifier, port identifier, OID, collection timestamp, metric value, and tracking identifier. Create network device identifier index, port identifier index, OID index, and collection timestamp index in the TimescaleDB time series database; A collection log verification code is generated based on the port identifier, OID, collection timestamp, and indicator value. The collection log verification code is then associated with the tracking identifier and written into the collection log record.

7. The network port status monitoring and early warning method based on knowledge graph according to claim 1, characterized in that, The generation of the candidate alarm set specifically includes: Read port timing data and collect abnormal alarms, and form a port indicator sequence according to port identifier within a preset time window; Threshold determination is performed according to threshold rules, which include OID, threshold parameters, and duration parameters. Threshold determination includes comparing the indicator values ​​in the port indicator sequence with the threshold parameters. When the comparison result remains true within the duration specified by the duration parameters, a threshold candidate alarm is generated. Baseline determination is performed according to baseline rules, which include baseline window parameters, deviation threshold parameters, and duration parameters. Baseline determination includes calculating baseline statistics and deviation within the time period specified by the baseline window parameters. When the deviation remains within the duration specified by the duration parameters, a baseline candidate alarm is generated. Trend determination is performed according to trend rules. Trend rules include trend window parameters, trend threshold parameters, and duration parameters. Trend determination includes calculating the change and trend strength within the time period limited by the trend window parameters. When the trend strength meets the trend threshold parameters within the duration limited by the duration parameters, a trend candidate alarm is generated. Based on threshold candidate alarms, baseline candidate alarms, trend candidate alarms, and collection anomaly alarms, a composite judgment is performed according to composite logic rules. The composite logic rules include AND logic, any true logic, and NOT logic. When the composite judgment meets the triggering conditions, a composite candidate alarm is generated. The candidate alarm set is formed by aggregating threshold candidate alarms, baseline candidate alarms, trend candidate alarms, and composite candidate alarms. The candidate alarm set is associated with the port identifier and trigger timestamp and written into the port knowledge graph.

8. The network port status monitoring and early warning method based on knowledge graph according to claim 1, characterized in that, The generation of the root cause alarm set specifically includes: Read the port dependency subgraph and candidate alarm set, filter candidate alarms within a preset time window, and extract the port identifiers associated with the candidate alarms to form an alarm port set; In the port dependency subgraph, the interpretation path record is calculated for the alarm port set. The interpretation path record includes the starting port identifier, the ending port identifier, the interpretation path, and the interpretation path cost. The interpretation path is the directed path from the starting port identifier to the ending port identifier. The interpretation path cost is the sum of the weights of the port-dependent edges in the interpretation path. The ending port identifier is the port identifier within the alarm port set. The overriding relationship is defined based on the interpretation path record. The overriding relationship represents the interpretation path from the root cause port identifier to the alarm port identifier. The root cause port set is solved based on the coverage relationship. The root cause port set is a set of port identifiers. The coverage cost includes the cumulative cost of the interpretation path from the root cause port identifier to the alarm port identifier and the penalty term for the size of the root cause port set. The solution objective is to minimize the coverage cost and cover the alarm port set. Based on the root cause port set, the explanation path from the root cause port identifier to the alarm port identifier is selected from the explanation path record to form the explanation path set. Based on the root cause port set and the explanation path set, the candidate alarm set is suppressed and aggregated to generate the root cause alarm set. The root cause alarm set is associated with the root cause port identifier and the explanation path set.

9. The network port status monitoring and early warning method based on knowledge graphs according to claim 1, characterized in that, The generation of the calculation port health score and weight version number specifically includes: Based on the root cause alarm set, the root cause alarm features corresponding to the port identifier are extracted. The root cause alarm features include the importance of the network device, the scope of impact, and the duration. The root cause alarm features are weighted and aggregated based on the scoring weights, and a port health score is calculated. The port health score is associated with the port identifier and the trigger timestamp. Based on the graded threshold, the port health score is classified into grades, and the classification results are associated with the port identifier and written into the root cause alarm set. Based on the hierarchical classification results, a notification is triggered to dispatch work orders and generate work order identifiers. The work order identifiers are associated with port identifiers and root cause alarm sets. The work order identifier is used to obtain the work order processing result to form a feedback sample. The feedback sample includes the port identifier, port health score, hierarchical classification result, and work order processing result. Within the sliding time window, the false alarm rate and false negative rate are calculated based on the feedback samples. The scoring weights and classification thresholds are updated using projective gradient descent while satisfying the upper limits of the false alarm rate and false negative rate. The weight version number is generated and associated with the scoring weights and classification thresholds.

Images