A method and device for integration testing of a distributed network traffic security monitoring system

Abstract

The present application relates to the field of network communication, and relates to a distributed network traffic security monitoring system integration test method and device, in response to the received integration test instruction, calling a multi-point constraint rule from a preset constraint rule library, which specifies a quantitative relationship that should be met by at least two monitoring nodes in the system for the same test traffic; calling a test excitation flow associated with the multi-point constraint rule from a preset test excitation library, and injecting it into the system, the test excitation flow carrying identification information that can be recognized by the at least two monitoring nodes; obtaining monitoring data generated by each monitoring node based on the test excitation flow, the monitoring data including node identification, time stamp and constraint observation value; according to the multi-point constraint rule, performing consistency verification on the monitoring data from different monitoring nodes, judging whether the quantitative relationship is met; outputting the verification result, if not met, locating the abnormal node or link, and if met, outputting a pass indication.

Description

Technical Field

[0001] This application relates to the field of network communication technology, and in particular to an integrated testing method and apparatus for a distributed network traffic security monitoring system. Background Technology

[0002] In distributed network traffic security monitoring systems, multiple monitoring nodes are typically deployed to work collaboratively. To ensure the correctness of the overall system functionality, integration testing of these nodes is necessary. Existing integration testing methods mostly follow the traditional single-node testing approach: for example, replaying pre-recorded attack traffic to each node to check if each node independently generates the expected alarm; or verifying node online status and connectivity by sending test packets. These methods can detect obvious faults in individual nodes, but they lack systematic verification methods for the collaborative working status between multiple nodes, such as whether there is a expected correlation between the processing results of different nodes on the same traffic.

[0003] In complex real-world network environments, there are special cases that are easily overlooked by existing testing methods, leading to distorted test results. For example, when multiple integration test commands are executed concurrently, test stimulus streams may be injected into the system simultaneously, causing congestion in the monitoring node processing queues. In this case, even if the system functions perfectly, the timestamps of the nodes processing packets will experience unpredictable delays due to queuing. If the testing method requires the timestamps of different nodes to meet a strict difference range, false positives can easily occur, meaning the system is fine, but the test reports a failure. Existing practices often involve serializing tests to avoid conflicts, but this sacrifices testing efficiency; or artificially increasing the time tolerance, but this reduces the ability to detect real faults. Summary of the Invention

[0004] To address one or more problems in the prior art, the main objective of this application is to provide an integrated testing method and apparatus for a distributed network traffic security monitoring system.

[0005] To achieve the above-mentioned objectives, this application proposes an integrated testing method for a distributed network traffic security monitoring system, the method comprising: In response to the received integration test command, a multi-point constraint rule is called from the preset constraint rule library, wherein the multi-point constraint rule specifies the quantitative relationship that should be satisfied between at least two monitoring nodes in the distributed network traffic security monitoring system for the same test traffic; The test incentive stream associated with the multi-point constraint rule is called from the preset test incentive library and injected into the distributed network traffic security monitoring system. The test incentive stream carries identification information that can be recognized by the at least two monitoring nodes. Acquire monitoring data generated by at least two of the monitoring nodes based on the test stimulus stream; the monitoring data includes node identifiers, timestamps, and constraint observations. Based on the multi-point constraint rules, the consistency of monitoring data from different monitoring nodes is verified to determine whether the quantitative relationship is satisfied. Output the verification results. If the consistency verification determines that the quantization relationship is not satisfied, then locate the abnormal node or abnormal link. When the consistency verification determines that the quantization relationship is satisfied, a pass indicator is output.

[0006] This application also provides an integrated testing device for a distributed network traffic security monitoring system, comprising: The receiving module is used to respond to the received integrated test command and call multi-point constraint rules from the preset constraint rule library. The multi-point constraint rules specify the quantitative relationship that should be satisfied between at least two monitoring nodes in the distributed network traffic security monitoring system for the same test traffic. The calling module is used to call the test incentive stream associated with the multi-point constraint rule from the preset test incentive library, and inject the test incentive stream into the distributed network traffic security monitoring system, wherein the test incentive stream carries identification information that can be identified by the at least two monitoring nodes; The acquisition module is used to acquire monitoring data generated by at least two of the monitoring nodes based on the test stimulus stream; the monitoring data includes node identifiers, timestamps, and constraint observations. The verification module is used to perform consistency verification on monitoring data from different monitoring nodes according to the multi-point constraint rules, so as to determine whether the quantification relationship is satisfied. The judgment module is used to output the verification result. When the consistency verification is determined to be inconsistent with the quantization relationship, the abnormal node or abnormal link is located. The output module is used to output a pass indicator when the consistency verification determines that the quantization relationship is satisfied.

[0007] This application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of any of the methods described above.

[0008] This application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of any of the methods described above.

[0009] This application presents an integration testing method and apparatus for a distributed network traffic security monitoring system. This solution automates and systematizes the integration testing of the distributed network traffic security monitoring system. First, constraint rules and test stimulus flows are pre-stored in a library and directly invoked during testing. This not only avoids the tedious process of constructing test cases on an ad-hoc basis each time but also ensures the consistency and reusability of the test logic. Second, this method is no longer limited to the functional verification of a single node but uses multi-point constraint rules to perform unified consistency checks on the monitoring data reported by multiple monitoring nodes. This effectively identifies collaborative defects such as data mismatches and timing misalignments between nodes, compensating for the blind spots of traditional single-node testing. When verification fails, it can automatically locate the specific abnormal node or link, eliminating the need for testers to check logs one by one, significantly shortening fault diagnosis time. The entire testing process is automatically executed in response to integration test commands, reducing manual intervention, improving testing efficiency and accuracy, and making the integration testing of the distributed security monitoring system more reliable and easier to maintain. Attached Figure Description

[0010] Figure 1 This is a flowchart illustrating an integration testing method for a distributed network traffic security monitoring system according to an embodiment of this application. Figure 2 This is a flowchart illustrating an integration testing method for a distributed network traffic security monitoring system according to an embodiment of this application. Figure 3 This is a schematic block diagram of the integrated testing device for a distributed network traffic security monitoring system according to an embodiment of this application; Figure 4 This is a schematic block diagram of the structure of a computer device according to an embodiment of this application.

[0011] The realization of the purpose, functional features and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0012] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0013] Reference Figure 1 This application provides an integration testing method for a distributed network traffic security monitoring system, the method comprising: S1. In response to the received integration test command, call multi-point constraint rules from the preset constraint rule library, wherein the multi-point constraint rules specify the quantitative relationship that should be satisfied between at least two monitoring nodes in the distributed network traffic security monitoring system for the same test traffic; S2. Call the test incentive stream associated with the multi-point constraint rule from the preset test incentive library, and inject the test incentive stream into the distributed network traffic security monitoring system, wherein the test incentive stream carries identification information that can be identified by the at least two monitoring nodes; S3. Obtain monitoring data generated by at least two of the monitoring nodes based on the test stimulus stream; the monitoring data includes node identifiers, timestamps, and constraint observations. S4. Based on the multi-point constraint rules, perform consistency verification on the monitoring data from different monitoring nodes to determine whether the quantification relationship is satisfied. S5. Output the verification result. If the consistency verification determines that the quantization relationship is not satisfied, then locate the abnormal node or abnormal link. S6. When the consistency verification determines that the quantization relationship is satisfied, output a pass indicator.

[0014] As described in steps S1-S2 above, this method can run in a test controller, which communicates with each monitoring node in the system. The entire testing process can be initiated in response to an integration test command issued by the tester or the automated testing platform. First, the test controller receives an integration test command. This command can come from the command line, a graphical interface, or a continuous integration pipeline. Upon receiving the command, the controller does not construct test rules on the spot, but instead retrieves the corresponding multi-point constraint rules from a pre-built constraint rule library. Multi-point constraint rules are essentially descriptions of the relationships between multiple monitoring nodes in the system. For example, a rule might stipulate that the difference in timestamps between the records of the same network traffic segment by node A and node B cannot exceed 5 milliseconds, or that the number of packets counted by node A should be equal to the sum of the number of packets counted by node B and node C. These rules are defined and stored in the rule library before testing, thus separating the test logic from the specific test data and facilitating subsequent reuse. Next, the test controller will find the associated test stimulus flow from a pre-prepared test stimulus library based on the invoked multi-point constraint rules. A test stimulus stream is a manually constructed sequence of network packets that mimics real business or attack traffic. The controller injects this test stimulus stream into the running distributed network traffic security monitoring system. To ensure that different monitoring nodes in the system can identify this traffic as being for testing, the test stimulus stream carries specific identification information. This identifier can be a special protocol field, a specific sequence number range, or a custom label, designed to allow each node to distinguish it from ordinary background traffic. After the test stimulus stream is injected, all relevant monitoring nodes in the system process this traffic according to their normal processing logic. Each node records its own node identifier, the timestamp of the received packet, and constraint observations extracted according to the test requirements. Constraint observations can be packet counts, field hashes, connection counts, etc. The test controller then retrieves this monitoring data from each monitoring node. This retrieval can be done through active polling or by nodes proactively reporting their data.

[0015] As described in steps S4-S6 above, after obtaining monitoring data from at least two nodes, the test controller performs consistency verification on this data according to the previously invoked multi-point constraint rules. The core of the verification is to determine whether the observations of each node satisfy the quantization relationship specified in the rules. For example, if the rule requires that the difference between the timestamps of node A and node B be less than 5 milliseconds, then the controller checks whether the actual difference is indeed within 5 milliseconds. If the rule requires that the count of node A be equal to the sum of the counts of node B and node C, then the controller verifies whether the equation holds. This step connects the isolated data scattered across the nodes, examining the correctness of the collaborative work from the perspective of the entire system. Finally, the test controller outputs the verification results. If the consistency verification confirms that the observations of each node satisfy the preset quantization relationship, a pass indication is output, indicating that the integration test has passed successfully. Conversely, if any node is found to not satisfy the quantization relationship, the controller will not only report the test failure but also attempt to locate abnormal nodes or abnormal links. The location can be based on which node's observation deviates most from the expectation, or which node is marked as a contradiction point multiple times in the constraint network. This location capability significantly reduces the time testers spend troubleshooting, directly pointing to potentially faulty nodes or communication links. This method combines pre-configured test resources, automated testing processes, and intelligent fault location, effectively identifying functional defects in the collaborative operation of nodes in a distributed monitoring system, thus overcoming the shortcomings of traditional single-node testing methods.

[0016] As described above, this solution automates and systematizes the integration testing of a distributed network traffic security monitoring system. First, constraint rules and test stimulus flows are pre-stored in a library and directly invoked during testing. This not only avoids the tedious process of constructing test cases on an ad-hoc basis each time but also ensures the consistency and reusability of the test logic. Second, this method is no longer limited to the functional verification of a single node but uses multi-point constraint rules to perform unified consistency checks on the monitoring data reported by multiple monitoring nodes. This effectively identifies collaborative defects such as data mismatches and timing misalignments between nodes, compensating for the blind spots of traditional single-node testing. When verification fails, it can automatically locate the specific abnormal node or link, eliminating the need for testers to check logs one by one, significantly shortening fault diagnosis time. The entire testing process is automatically executed in response to integration test commands, reducing manual intervention, improving testing efficiency and accuracy, and making the integration testing of the distributed security monitoring system more reliable and easier to maintain.

[0017] Reference Figure 2 In one embodiment, the method of calling a test stimulus stream associated with the multi-point constraint rule from a preset test stimulus library and injecting the test stimulus stream into the distributed network traffic security monitoring system includes: S21. Parse the multi-point constraint rule and extract the identification information of at least two monitoring nodes involved in the rule and the position of the monitoring nodes in the distributed network topology; S22. Based on the extraction results, determine at least one injection node; S23. Retrieve the test stimulus flow template associated with the multi-point constraint rule from the test stimulus library; S24. Analyze the positional relationship between the at least two monitoring nodes, and dynamically fill the sequence number field in the template according to the positional relationship between the at least two monitoring nodes to generate the final test stimulus stream; S25. According to the preset injection scheduling strategy, the test stimulus stream is injected from the injection node into the distributed network traffic security monitoring system, wherein the injection scheduling strategy is a single injection mode, a pulse injection mode, or a delayed chain injection mode.

[0018] As described above, in practice, the test controller first parses the invoked multi-point constraint rules, extracting the identification information of each monitoring node involved in the rules and their specific locations in the network topology. This is to clarify which nodes need to be monitored in this test and their upstream / downstream or bypass relationships. Next, the controller selects a suitable injection node based on the extracted node location information. The selection of the injection node is not arbitrary; it is typically chosen in the topology where the test stimulus flow can be observed sequentially or simultaneously by all nodes under test, avoiding situations where some nodes fail to receive the test flow due to an improper injection point. Then, the controller retrieves the test stimulus flow template associated with the rule from the test stimulus library. This template defines basic characteristics such as message length, protocol type, and payload content, but the sequence number field is left blank or used as a placeholder. The controller further analyzes the positional relationships of each monitoring node; for example, node A is upstream of node B, or node C and node D are parallel mirror ports. Based on this positional relationship, the sequence number field in the template is dynamically filled. For example, the sequence number value can increment with the node's hop count, or different sequence number ranges can be assigned according to the path order. The resulting final test stimulus stream inherently contains the relative order information of each node within its sequence number, facilitating subsequent verification to determine whether nodes processed packets in the expected order. Finally, the controller sends the complete test stimulus stream from the selected injection node to the system according to a preset injection scheduling strategy. Three scheduling strategies are available: single injection mode sends only one test stream, suitable for simple verification; burst injection mode continuously sends multiple identical test streams within a short period to observe the node's processing stability under burst traffic; and delayed chain injection mode copies the test stream and injects it sequentially through different paths or with different delays, simulating scenarios in real networks where traffic arrives via multiple paths and experiences out-of-order or duplicate traffic. This flexible scheduling strategy allows integration testing to cover a wider range of network behaviors.

[0019] As described above, this step addresses the shortcomings of traditional testing methods, which are fixed and unable to adapt to different node topologies. By dynamically determining the injection node and its location-related sequence number filling, it ensures that the test stimulus flow can be effectively identified and tracked by all relevant nodes. Furthermore, it introduces multiple injection modes, particularly delayed chain injection, providing the test with the ability to combat out-of-order delivery and latency differences.

[0020] In one embodiment, the method of performing consistency verification on monitoring data from different monitoring nodes according to the multi-point constraint rules to determine whether the quantification relationship is satisfied includes: The monitoring data is parsed, and based on the parsing results, the constrained observations from different monitoring nodes are arranged in the order of node identifiers to obtain an observation sequence. The difference between any two adjacent observations in the observation sequence is calculated sequentially to obtain the difference sequence. The absolute value of each difference in the difference sequence is compared with a preset threshold. If the absolute value of all differences in the difference sequence is less than or equal to the threshold, then the quantization relationship is satisfied; otherwise, the quantization relationship is not satisfied.

[0021] In the specific execution of consistency verification, this embodiment adopts a judgment method based on sorting and comparison of adjacent differences. The test controller first parses the monitoring data collected from each monitoring node, extracts the constraint observations, and arranges these observations into a sequence according to the fixed order of the node identifiers. The advantage of this is that it eliminates the randomness of the reporting order of different nodes, so that each verification has a unified reference benchmark. Next, the controller calculates the difference between every two adjacent observations in the sequence, forming a set of difference sequences. For example, if there are observations of nodes A, B, and C in the sequence, the difference between A and B, and the difference between B and C are calculated. The reason for only calculating adjacent differences instead of all pairwise combinations is that the difference between adjacent items under ordered arrangement can already reflect the fluctuation of the entire sequence, and the computational load is small and the logic is simple. Then, the absolute value of each difference in the difference sequence is compared with a preset threshold. This threshold can be preset according to the rigor of the test, such as 5 milliseconds, 10 messages, etc. Only when the absolute values ​​of all differences do not exceed the threshold are the observations deemed to satisfy the quantization relationship, meaning that the processing results of each node for the same test traffic are consistent; otherwise, if any difference exceeds the threshold, it is deemed not to satisfy the relationship. The significant advantage of this verification method is that it does not require the observations of each node to be exactly equal, but allows them to fluctuate within a controllable deviation range, thus adapting to minor differences that may exist in real networks, such as clock drift and quantization errors between different nodes. Furthermore, comparing all adjacent differences pairwise can capture any local abnormal fluctuations in the sequence, which is more precise than simply checking the difference between the maximum and minimum values. Overall, this method provides a computationally simple and sensitive consistency verification tool for distributed monitoring systems, effectively solving the problem of misjudging the entire system failure due to minor deviations of individual nodes.

[0022] In one embodiment, the method of performing consistency verification on monitoring data from different monitoring nodes according to the multi-point constraint rules to determine whether the quantification relationship is satisfied further includes: Determine whether different deviation thresholds are configured for different node pairs among the at least two monitoring nodes in the multi-point constraint rule; If so, then obtain the mapping relationship between the node pairs and the deviation threshold recorded in the multi-point constraint rules; Extract the constrained observation values ​​of each monitoring node from the monitoring data; Based on the mapping relationship, for each pair of nodes that need to be compared, a corresponding deviation threshold is selected; Calculate the deviation between the two constraint observations of the node pair, and compare the deviation with the corresponding deviation threshold based on the calculation result; If the deviation values ​​of all node pairs are less than or equal to their respective deviation thresholds, then the quantization relationship is deemed to be satisfied; otherwise, it is deemed not satisfied.

[0023] In practical implementation, this embodiment further extends the consistency verification steps to address scenarios where different node pairs may have different tolerance requirements. The test controller first checks whether the currently invoked multi-point constraint rules have configured their respective deviation thresholds for different node pairs. For example, for two closely spaced core nodes, the rule might require their timestamp difference to be no more than 1 millisecond; while for two geographically separated edge nodes, the rule only requires the difference to be no more than 50 milliseconds. If such differentiated configurations exist in the rules, the controller extracts the mapping relationship between node pairs and deviation thresholds, for example, recording that the threshold for node A and node B is 1 millisecond, and the threshold for node B and node C is 50 milliseconds. Subsequently, the controller extracts constraint observations from the monitoring data of each monitoring node and, based on the previously obtained mapping relationship, selects the corresponding deviation threshold for each node pair to be compared. Then, it calculates the deviation value between the constraint observations of each pair of nodes and compares this deviation value with the selected threshold. Only when the deviation values ​​of all node pairs do not exceed their respective thresholds is the quantification relationship considered satisfied; if the deviation value of any pair of nodes exceeds its specific threshold, the relationship is considered unsatisfactory. This differentiated threshold design takes into account the objective differences between nodes in a distributed system caused by factors such as physical distance, processing power, and network link quality. Compared to using a uniform fixed threshold, this method avoids false positives caused by overly stringent local requirements leading to excessively strict overall testing, and also prevents overlooking the fine-grained testing of critical nodes while favoring lenient nodes. This allows integration testing to better reflect actual deployment environments, improving the rationality and practicality of test results while ensuring detection sensitivity.

[0024] It's worth noting that in actual testing, multiple integration test commands may be executed simultaneously. For example, testers might simultaneously initiate verification tasks targeting different security rules, and the test controller might then continuously inject multiple test stimulus streams from different injection points or the same injection point. After these stimulus streams are transmitted through the network, they may converge at the same monitoring node, such as a mirror port probe of a core switch. This monitoring node needs to process these almost simultaneously arriving test packets sequentially, causing congestion in its processing queue. As a result, the timestamps recorded by this node for each test stream experience unpredictable additional delays; some packets are delayed by tens of milliseconds, others by hundreds of milliseconds, and this delay is not a fixed offset. In this situation, even if the entire monitoring system's detection function is completely normal, the timestamp difference between nodes will exceed the previously preset threshold due to congestion, leading to consistency verification failure and the output of incorrect failure indications. Even more problematic is that when the test controller attempts to locate abnormal nodes, it may incorrectly mark the node with the most severe congestion as a faulty node. Traditional approaches either abandon concurrent testing and switch to serial execution to avoid conflicts, but this will multiply the total testing time; or manually increase the timestamp tolerance threshold, but doing so will reduce the sensitivity to detecting real timing defects, which is counterproductive.

[0025] To address the false positive issue caused by concurrent congestion, this embodiment adds the following preprocessing step before consistency verification. This embodiment proposes that, before the step of performing consistency verification on monitoring data from different monitoring nodes according to the multi-point constraint rules to determine whether the quantification relationship is satisfied, the method further includes: Determine if multiple integration test commands are being executed concurrently. If so, obtain the timestamp from the monitoring data reported by each monitoring node, and obtain the injection timestamp when the test stimulus stream is injected; For each monitoring node, the difference between the injected timestamp and the timestamp reported by the monitoring node is calculated, and the result of the calculation is used as the end-to-end delay corresponding to the monitoring node. The minimum value among the end-to-end delays of all monitoring nodes is selected as the baseline delay; For each monitoring node, the timestamp reported by each monitoring node is subtracted from the baseline delay to obtain the compensated timestamp; The compensated timestamp is used as the constraint observation value of the monitoring data, and consistency verification is performed according to the multi-point constraint rules to determine whether the quantization relationship is satisfied.

[0026] As described above, considering the potential congestion issues at monitoring nodes caused by the simultaneous execution of multiple integration test commands, this embodiment adds a preprocessing step before the consistency verification step. The test controller first determines whether multiple integration test commands are currently executing concurrently. This can be done by checking if the number of incomplete commands in the test command queue is greater than one. If concurrency exists, the controller collects the timestamps from the monitoring data reported by each monitoring node and simultaneously obtains the injection timestamp of the test stimulus flow at the injection moment. For each monitoring node, the difference between the injection timestamp and the timestamp reported by that node is calculated. This difference reflects the total latency experienced by the test stimulus flow from the injection point to the node and its completion of processing, including network transmission, queuing, and processing time. Subsequently, the controller selects the minimum value from the end-to-end latency of all nodes as the baseline latency. The minimum value is chosen because it is closest to the transmission latency under ideal conditions with no congestion and no queuing, and can be considered as the time baseline corresponding to the fastest processing path in the entire system. After obtaining the baseline latency, the controller compensates for the timestamp reported by each node by subtracting the baseline latency from the node's timestamp. This operation is equivalent to aligning the timestamps of all nodes to the same congestion-free virtual timeline, eliminating the additional queuing delay differences introduced by concurrent congestion. Finally, the compensated timestamps are used as constraint observations, and consistency verification is performed according to the aforementioned multi-point constraint rules. In this way, even when multiple test streams are injected concurrently, causing congestion in the node processing queue, this method can still effectively filter out latency noise caused by congestion, preventing normal system functions from being misjudged as abnormal. Compared to traditional serialized testing or manually relaxing thresholds, this solution retains testing efficiency while maintaining the original detection sensitivity, improving the accuracy of integration testing under high load environments.

[0027] In one embodiment, before the step of performing consistency verification on monitoring data from different monitoring nodes according to the multi-point constraint rules to determine whether the quantification relationship is satisfied, the method further includes: Determine whether the multi-point constraint rule includes a sampling deviation parameter, which is used to characterize the allowable deviation range of the observed values ​​caused by different sampling rates at each monitoring node; If the multi-point constraint rule includes a sampling deviation parameter, then the sampling deviation parameter is obtained, and a probability distribution model of the expected observation value of each monitoring node is constructed based on the sampling deviation parameter. Based on the results from the institution, the constrained observation values ​​of each monitoring node are input into the corresponding expected observation value probability distribution model, the cumulative probability value of each observation value is calculated, and the calculated result is output through the expected observation value probability distribution model. Based on the output calculation results, determine whether all cumulative probability values ​​are within the preset confidence interval; If so, then the consistency of the monitoring data from different monitoring nodes is verified to determine whether the quantification relationship is satisfied; If not, then the quantification relationship is not satisfied.

[0028] As described above, this embodiment further considers the scenario where different nodes in a distributed monitoring system may use different sampling rates. For example, nodes located in core positions have higher performance and use full sampling, while edge nodes may use random sampling at a ratio of 1:1000 to save resources. When the test stimulus stream passes through these nodes, the observation value of the nodes with full sampling is a fixed value, while the observation value of the sampling nodes will fluctuate within a probability range. If it is forced that the observation values ​​of all nodes be approximately equal or meet a strict difference relationship, it is easy to cause test failure due to the randomness of sampling, even though the system function is actually working correctly. To address this scenario, this embodiment adds a preprocessing step based on a probability model before consistency verification. The test controller first determines whether the currently invoked multi-point constraint rule contains sampling bias parameters. These parameters describe the allowable range of observation deviation for each monitoring node due to different sampling rates, such as sampling ratio, confidence level, etc. If the rule does contain these parameters, the controller constructs an expected observation probability distribution model for each node based on them. For example, for a node with a sampling rate of 1:1000, given the total number of test stimulus stream messages, the distribution of its actual sample count can be approximated as a binomial or Poisson distribution. After obtaining the probability distribution model for each node, the controller inputs the actual collected constraint observations into the corresponding models to calculate the cumulative probability value of each observation. The cumulative probability value reflects the likelihood of observing the current value or a more extreme value under a given sampling rate and random fluctuations. Next, the controller determines whether all these cumulative probability values ​​fall within a pre-defined confidence interval, commonly ranging from 2.5% to 97.5%, corresponding to a 95% confidence level. If the cumulative probability values ​​of all nodes are within this interval, it indicates that the actual observations of each node match the sampling bias model, and they can be considered to have passed the probabilistic consistency test. At this point, the controller continues to execute subsequent verification steps, such as further judgment based on the difference comparison described above. Conversely, if the cumulative probability value of any node falls outside the confidence interval, it is directly determined that the quantization relationship is not satisfied, and the test fails. This step no longer uses a fixed threshold to rigidly compare the observations of each node. Instead, it introduces the concept of hypothesis testing from statistics, taking into account the randomness introduced by sampling. This method effectively avoids misjudging system faults due to sampling fluctuations, and is also more scientific and sensitive than simply relaxing the tolerance threshold. It enables integration testing to adapt to the non-uniform sampling scenarios commonly found in real-world deployments.

[0029] In one feasible embodiment, in certain fault scenarios, each monitoring node may function normally individually, but problems arise in the collaboration between nodes. For example, node A is responsible for extracting 5-tuple information from network traffic, and node B is responsible for performing session counting based on the 5-tuples. Due to a rare byte order error in the interface protocol between node A and node B, the source port field in the 5-tuple received by node B is misinterpreted. As a result, the hash value of the 5-tuple reported by node A is correct, and the session count calculated by node B based on the incorrect 5-tuple is logically consistent, but cross-node comparison reveals that the hash values ​​of node A and node B are inconsistent. In this case, if conventional majority voting or simple deviation comparison is used, the test controller may not be able to determine whether node A or node B is wrong, and may even randomly mark one of them as an anomaly, leading to incorrect fault location. A more complex situation is that the observation values ​​of the three nodes A, B, and C are required to be equal. The actual fault occurs at node B, but nodes A and C are normal, and the data of A and C are equal, so majority voting can correctly determine B as an anomaly. However, if the fault involves nodes A and C simultaneously exhibiting opposite deviations—for example, A overcounts and C undercounts, but their values ​​are exactly equal, while node B is normal—the majority vote will incorrectly classify node B as abnormal. These confusing faults demonstrate that relying solely on comparisons between nodes is insufficient, necessitating a more reliable fault localization method.

[0030] To address this issue, this embodiment proposes that locating abnormal nodes or abnormal links includes: Obtain the expected observation benchmark associated with the test stimulus stream; Calculate the deviation between the constrained observation value and the expected observation value benchmark for each monitoring node; If the deviation value of only one monitoring node is greater than the preset single-point deviation tolerance, then the monitoring node is identified as an abnormal node. If the deviation values ​​of multiple monitoring nodes are greater than the single-point deviation tolerance, then the sign of the deviation values ​​of the multiple monitoring nodes is analyzed. If the deviation values ​​of the multiple monitoring nodes have the same sign, it is determined to be a global anomaly, and a link failure indication is output. If the deviation values ​​of the multiple monitoring nodes have different signs, the ratio of the sum of the absolute values ​​of each deviation value to the expected observation value benchmark is calculated. When the ratio is greater than a preset second ratio threshold, it is determined that the inter-node cooperation interface is abnormal, and the identifiers of the multiple monitoring nodes are output.

[0031] To address the aforementioned issues, this embodiment provides a fault location method based on expected baselines and deviation pattern analysis. The test controller first retrieves the expected observation baseline associated with the current test stimulus flow from the test stimulus library. This baseline can be understood as the standard value that each node should report under ideal conditions, such as a known total number of packets, a preset hash value, or a standard time length. With this absolute reference, fault location no longer relies on mutual voting between nodes, but rather has an objective benchmark. The controller then calculates the deviation between the actual constraint observation of each monitoring node and this baseline, obtaining the degree of deviation for each node. Next, the deviation value of each node is compared with a preset single-point deviation tolerance. If only one node's deviation value exceeds this tolerance, it indicates that other nodes are in line with the baseline, and the problem is likely with the deviating node itself; therefore, this node is directly marked as an abnormal node. This situation corresponds precisely to the scenario described above where a single node fails, such as a probe counter malfunctioning or time synchronization failing. If multiple nodes' deviation values ​​exceed the tolerance, the controller further analyzes the signs of these deviation values, i.e., whether they are positive or negative deviations. If all deviation values ​​have the same sign, it means that each node either overreported the value or underreported the value. This situation is often not a problem with a single node, but may be due to an error in the baseline of the test stimulus flow itself, or a problem with the global configuration of the system, such as a drift in the time source shared by all nodes. Therefore, the controller determines it as a global anomaly and outputs an indication of link failure or system configuration failure. If the deviation values ​​of multiple nodes are both positive and negative, that is, some nodes' observations are higher than the baseline and some are lower than the baseline, then the problem is likely in the cooperation interface between nodes. For example, the aforementioned byte order error may cause node A to be correct while node B is incorrect, or uneven traffic distribution may cause one node to have a high count and another node to have a low count. To quantify the degree of this cooperation anomaly, the controller calculates the sum of the absolute values ​​of each deviation value and divides it by the expected observation baseline to obtain a ratio. When this ratio exceeds a preset second ratio threshold, it indicates that the total deviation is no longer negligible, thus determining it as an anomaly in the inter-node cooperation interface, and outputting the identifiers of all involved nodes. This approach effectively avoids the misidentification of faults in traditional majority voting under confusing fault conditions. For example, in the aforementioned three nodes, A and C have opposite directions and equal values, while B is normal. This method will detect that the deviation values ​​of A and C have opposite signs, and the sum of their absolute values ​​may exceed a threshold compared to the baseline. Therefore, it correctly marks A and C as having abnormal cooperation, rather than incorrectly pointing to the normal node B. Through the aforementioned location mechanism based on expected baseline and deviation sign analysis, this embodiment can clearly distinguish between single-point faults, global faults, and inter-node cooperation faults, providing testers with accurate fault types and fault scopes.

[0032] Reference Figure 3This application also provides an integrated testing device for a distributed network traffic security monitoring system, comprising: The receiving module 1 is used to respond to the received integrated test command and call multi-point constraint rules from the preset constraint rule library. The multi-point constraint rules specify the quantitative relationship that should be satisfied between at least two monitoring nodes in the distributed network traffic security monitoring system for the same test traffic. Module 2 is invoked to call a test incentive stream associated with the multi-point constraint rule from a preset test incentive library and inject the test incentive stream into the distributed network traffic security monitoring system, wherein the test incentive stream carries identification information that can be identified by the at least two monitoring nodes; The acquisition module 3 is used to acquire monitoring data generated by at least two of the monitoring nodes based on the test stimulus stream; the monitoring data includes node identifiers, timestamps, and constraint observations; Verification module 4 is used to perform consistency verification on monitoring data from different monitoring nodes according to the multi-point constraint rules, so as to determine whether the quantification relationship is satisfied. Judgment module 5 is used to output the verification result. When the consistency verification is determined to be inconsistent with the quantization relationship, the abnormal node or abnormal link is located. Output module 6 is used to output a pass indicator when the consistency verification determines that the quantization relationship is satisfied.

[0033] As described above, it is understood that each component of the integrated testing device for the distributed network traffic security monitoring system proposed in this application can realize the function of any one of the integrated testing methods for the distributed network traffic security monitoring system described above, and the specific structure will not be described in detail.

[0034] Reference Figure 4 This application also provides a computer device, which may be a server, and its internal structure may be as follows: Figure 4 As shown, the computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores monitoring data and other data. The network interface is used for communication with external terminals via a network connection. When the computer program is executed by the processor, it implements an integrated testing method for a distributed network traffic security monitoring system.

[0035] The processor described above executes the integration testing method of the distributed network traffic security monitoring system, comprising: responding to a received integration testing instruction, calling a multi-point constraint rule from a preset constraint rule library, wherein the multi-point constraint rule specifies a quantitative relationship that should be satisfied between at least two monitoring nodes in the distributed network traffic security monitoring system for the same test traffic; calling a test incentive stream associated with the multi-point constraint rule from a preset test incentive library, and injecting the test incentive stream into the distributed network traffic security monitoring system, wherein the test incentive stream carries identification information that can be identified by the at least two monitoring nodes; acquiring monitoring data generated by each of the at least two monitoring nodes based on the test incentive stream; the monitoring data includes node identifier, timestamp, and constraint observation value; performing consistency verification on the monitoring data from different monitoring nodes according to the multi-point constraint rule to determine whether the quantitative relationship is satisfied; outputting the verification result; when the consistency verification determines that the quantitative relationship is not satisfied, locating an abnormal node or abnormal link; when the consistency verification determines that the quantitative relationship is satisfied, outputting a pass indication.

[0036] One embodiment of this application also provides a computer-readable storage medium storing a computer program thereon. When executed by a processor, the computer program implements an integration testing method for a distributed network traffic security monitoring system, comprising the steps of: responding to a received integration testing instruction, calling a multi-point constraint rule from a preset constraint rule library, wherein the multi-point constraint rule specifies a quantization relationship that should be satisfied between at least two monitoring nodes in the distributed network traffic security monitoring system for the same test traffic; calling a test incentive stream associated with the multi-point constraint rule from a preset test incentive library and injecting the test incentive stream into the distributed network traffic security monitoring system, wherein the test incentive stream carries identification information that can be identified by the at least two monitoring nodes; acquiring monitoring data generated by each of the at least two monitoring nodes based on the test incentive stream; the monitoring data includes node identifier, timestamp, and constraint observation value; performing consistency verification on the monitoring data from different monitoring nodes according to the multi-point constraint rule to determine whether the quantization relationship is satisfied; outputting the verification result; when the consistency verification determines that the quantization relationship is not satisfied, locating an abnormal node or abnormal link; when the consistency verification determines that the quantization relationship is satisfied, outputting a pass indication.

[0037] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in this application and in the embodiments can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

[0038] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, apparatus, article, or method that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, apparatus, article, or method. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, apparatus, article, or method that includes that element.

[0039] The above description is only a preferred embodiment of this application and does not limit the patent scope of this application. Any equivalent structural or procedural changes made based on the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. An integration testing method for a distributed network traffic security monitoring system, characterized in that, The method includes: In response to the received integration test command, a multi-point constraint rule is called from the preset constraint rule library, wherein the multi-point constraint rule specifies the quantitative relationship that should be satisfied between at least two monitoring nodes in the distributed network traffic security monitoring system for the same test traffic; The test incentive stream associated with the multi-point constraint rule is called from the preset test incentive library and injected into the distributed network traffic security monitoring system. The test incentive stream carries identification information that can be recognized by the at least two monitoring nodes. Acquire monitoring data generated by at least two of the monitoring nodes based on the test stimulus stream; the monitoring data includes node identifiers, timestamps, and constraint observations. Based on the multi-point constraint rules, the consistency of monitoring data from different monitoring nodes is verified to determine whether the quantitative relationship is satisfied. Output the verification results. If the consistency verification determines that the quantization relationship is not satisfied, then locate the abnormal node or abnormal link. When the consistency verification determines that the quantization relationship is satisfied, a pass indicator is output; The process of locating abnormal nodes or abnormal links includes: obtaining the expected observation benchmark associated with the test stimulus flow; calculating the deviation between the constraint observation of each monitoring node and the expected observation benchmark; if only one monitoring node has a deviation greater than a preset single-point deviation tolerance, then the monitoring node is identified as an abnormal node; if multiple monitoring nodes have deviations greater than the single-point deviation tolerance, then the signs of the deviations of the multiple monitoring nodes are analyzed; if the deviations of the multiple monitoring nodes have the same sign, then a global anomaly is determined, and a link failure indication is output; if the deviations of the multiple monitoring nodes have different signs, then the ratio of the sum of the absolute values ​​of each deviation value to the expected observation benchmark is calculated, and when the ratio is greater than a preset second ratio threshold, an inter-node cooperation interface anomaly is determined, and the identifiers of the multiple monitoring nodes are output.

2. The integration testing method for the distributed network traffic security monitoring system according to claim 1, characterized in that, The method of retrieving a test stimulus stream associated with the multi-point constraint rule from a preset test stimulus library and injecting the test stimulus stream into the distributed network traffic security monitoring system includes: The multi-point constraint rules are parsed to extract the identification information of at least two monitoring nodes involved in the rules and the positions of the monitoring nodes in the distributed network topology; Based on the extraction results, at least one injection node is identified; Retrieve the test stimulus flow template associated with the multi-point constraint rule from the test stimulus library; Analyze the positional relationship between the at least two monitoring nodes, and dynamically fill the sequence number field in the template according to the positional relationship between the at least two monitoring nodes to generate the final test stimulus stream; According to a preset injection scheduling strategy, the test stimulus stream is injected from the injection node into the distributed network traffic security monitoring system, wherein the injection scheduling strategy is a single injection mode, a pulse injection mode, or a delayed chain injection mode.

3. The integration testing method for the distributed network traffic security monitoring system according to claim 1, characterized in that, The method of verifying the consistency of monitoring data from different monitoring nodes according to the multi-point constraint rules to determine whether the quantification relationship is satisfied includes: The monitoring data is parsed, and based on the parsing results, the constrained observations from different monitoring nodes are arranged in the order of node identifiers to obtain an observation sequence. The difference between any two adjacent observations in the observation sequence is calculated sequentially to obtain the difference sequence. The absolute value of each difference in the difference sequence is compared with a preset threshold. If the absolute value of all differences in the difference sequence is less than or equal to the threshold, then the quantization relationship is satisfied; otherwise, the quantization relationship is not satisfied.

4. The integration testing method for the distributed network traffic security monitoring system according to claim 3, characterized in that, The method further includes verifying the consistency of monitoring data from different monitoring nodes according to the multi-point constraint rules to determine whether the quantification relationship is satisfied. Determine whether different deviation thresholds are configured for different node pairs among the at least two monitoring nodes in the multi-point constraint rule; If so, then obtain the mapping relationship between the node pairs and the deviation threshold recorded in the multi-point constraint rules; Extract the constrained observation values ​​of each monitoring node from the monitoring data; Based on the mapping relationship, for each pair of nodes that need to be compared, a corresponding deviation threshold is selected; Calculate the deviation between the two constraint observations of the node pair, and compare the deviation with the corresponding deviation threshold based on the calculation result; If the deviation values ​​of all node pairs are less than or equal to their respective deviation thresholds, then the quantization relationship is deemed to be satisfied; otherwise, it is deemed not satisfied.

5. The integration testing method for the distributed network traffic security monitoring system according to claim 3, characterized in that, Before the step of performing consistency verification on monitoring data from different monitoring nodes according to the multi-point constraint rules to determine whether the quantification relationship is satisfied, the method further includes: Determine if multiple integration test commands are being executed concurrently. If so, obtain the timestamp from the monitoring data reported by each monitoring node, and obtain the injection timestamp when the test stimulus stream is injected; For each monitoring node, the difference between the injected timestamp and the timestamp reported by the monitoring node is calculated, and the result of the calculation is used as the end-to-end delay corresponding to the monitoring node. The minimum value among the end-to-end delays of all monitoring nodes is selected as the baseline delay; For each monitoring node, the timestamp reported by each monitoring node is subtracted from the baseline delay to obtain the compensated timestamp; The compensated timestamp is used as the constraint observation value of the monitoring data, and consistency verification is performed according to the multi-point constraint rules to determine whether the quantization relationship is satisfied.

6. The integration testing method for the distributed network traffic security monitoring system according to claim 3, characterized in that, Before the step of performing consistency verification on monitoring data from different monitoring nodes according to the multi-point constraint rules to determine whether the quantification relationship is satisfied, the method further includes: Determine whether the multi-point constraint rule includes a sampling deviation parameter, which is used to characterize the allowable deviation range of the observed values ​​caused by different sampling rates at each monitoring node; If the multi-point constraint rule includes a sampling deviation parameter, then the sampling deviation parameter is obtained, and a probability distribution model of the expected observation value of each monitoring node is constructed based on the sampling deviation parameter. Based on the constructed results, the constrained observation values ​​of each monitoring node are input into the corresponding expected observation value probability distribution model, the cumulative probability value of each observation value is calculated, and the calculated results are output through the expected observation value probability distribution model. Based on the output calculation results, determine whether all cumulative probability values ​​are within the preset confidence interval; If so, then the consistency of the monitoring data from different monitoring nodes is verified to determine whether the quantification relationship is satisfied; If not, then the quantification relationship is not satisfied.

7. An integrated testing device for a distributed network traffic security monitoring system, used to execute the method described in any one of claims 1-6, characterized in that, include: The receiving module is used to respond to the received integrated test command and call multi-point constraint rules from the preset constraint rule library. The multi-point constraint rules specify the quantitative relationship that should be satisfied between at least two monitoring nodes in the distributed network traffic security monitoring system for the same test traffic. The calling module is used to call the test incentive stream associated with the multi-point constraint rule from the preset test incentive library, and inject the test incentive stream into the distributed network traffic security monitoring system, wherein the test incentive stream carries identification information that can be identified by the at least two monitoring nodes; The acquisition module is used to acquire monitoring data generated by at least two of the monitoring nodes based on the test stimulus stream; the monitoring data includes node identifiers, timestamps, and constraint observations. The verification module is used to perform consistency verification on monitoring data from different monitoring nodes according to the multi-point constraint rules, so as to determine whether the quantification relationship is satisfied. The judgment module is used to output the verification result. When the consistency verification is determined to be inconsistent with the quantization relationship, the abnormal node or abnormal link is located. The output module is used to output a pass indicator when the consistency verification determines that the quantization relationship is satisfied.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

Images