Network traffic anomaly detection method and device, storage medium and computer equipment

Abstract

The invention relates to the technical field of internet, finance and medical health, and particularly discloses a network traffic anomaly detection method and device, a storage medium and computer equipment, and the method comprises the steps: calling a network traffic monitoring tool in response to a network traffic anomaly detection instruction, and obtaining network communication data based on the network traffic monitoring tool; performing statistics on the network communication data according to a first preset time interval, and dynamically constructing time sequence data of each container calling combination according to a statistical result and a preset time window length; for each container calling combination, determining whether the calling state of the container calling combination is abnormal or not through a preset abnormal state detection model based on the time sequence data of the container calling combination in sequence; and when the calling state of any container calling combination is abnormal, generating an abnormal propagation path of any container calling combination through the container calling relation graph based on the source container and the target container contained in any container calling combination.

Description

Technical Field

[0001] The present application relates to the fields of Internet, finance, and medical health technology, and in particular to a method and apparatus for detecting anomalies in network traffic, a storage medium, and a computer device. Background Art

[0002] With the rapid development of modern cloud computing, containerization technology, with its significant advantages such as lightweight, portability, and high resource utilization, has been widely adopted in fields such as finance and healthcare. Currently, Kubernetes clusters (i.e., containerized clusters) have become a core tool for service deployment and management in financial business systems and healthcare information systems. In the financial sector, Kubernetes clusters enable financial institutions to quickly and flexibly deploy various financial applications, such as online payment systems, risk assessment models, and investment trading platforms, to cope with the increasingly complex and volatile financial market environment and diverse customer needs. It also plays a crucial role in healthcare, becoming a key tool for service deployment and management in healthcare information systems. In Kubernetes clusters, services are typically deployed as pods. These pods, as the basic operating units of containerized applications, communicate with each other through a complex network topology, supporting the smooth operation of key business processes such as capital flow and data exchange in the financial sector, as well as business processes such as patient information management, secure transmission of medical images, and accurate electronic medical record recording in the healthcare sector.

[0003] To effectively monitor and manage network communications between containers within a Kubernetes cluster and ensure the stability and security of financial business systems and medical information systems, advanced network traffic monitoring tools such as Hubble have emerged. These tools can capture and visually display the network traffic topology between containers in a cluster in real time, detailing the direction and scale of traffic between services, providing operations and maintenance personnel with valuable insights into network status.

[0004] However, with the increasing penetration of microservice architectures in the financial and healthcare sectors, and the increasing complexity of containerized applications, real-time detection and precise location of network anomalies have become key challenges in ensuring stable system operation. Traditional network traffic anomaly detection methods often rely too heavily on static, rule-based detection strategies. While these methods demonstrate some effectiveness in addressing known network anomaly patterns, their limitations become apparent when faced with dynamically changing microservice architectures. In a microservice architecture, the call relationships between services are complex and constantly adapt to the rapid iteration of business needs. This makes fixed-rule-based anomaly detection methods difficult to adapt to this rapidly changing environment, resulting in high false positive and false negative rates. This makes it impossible to meet the urgent needs of financial business systems and healthcare information systems for real-time, accurate network anomaly detection. Summary of the Invention

[0005] In view of this, the present application provides a network traffic anomaly detection method and device, storage medium, and computer equipment. The network traffic monitoring tool in the containerized cluster is used to collect network communication data. There is no need to deploy additional network traffic monitoring tools, which reduces the complexity of the solution implementation. By dynamically constructing time series data and using a preset abnormal state detection model to analyze the time series data to obtain call state detection results, real-time detection and precise positioning of network anomalies are achieved. The abnormal propagation path is generated by the container call relationship graph, and the abnormal propagation relationship can be quickly identified. The embodiments of the present application can not only effectively cope with the complexity of network anomaly detection under the microservice architecture, but also significantly improve the accuracy and efficiency of anomaly detection.

[0006] According to one aspect of the present application, a method for detecting anomalies in network traffic is provided, which is applied to a containerized cluster. The method includes:

[0007] In response to a network traffic anomaly detection instruction for the containerized cluster, calling a network traffic monitoring tool for the containerized cluster, and obtaining network communication data corresponding to the containerized cluster based on the network traffic monitoring tool;

[0008] At a first preset time interval, statistics are performed on the network communication data, and time series data corresponding to each container call combination in the containerized cluster is dynamically constructed based on the statistical results and a preset time window length, wherein the container call combination includes a source container and a target container having a call relationship, and the time series data includes communication volume statistics corresponding to multiple time intervals;

[0009] For each container call combination, determine whether the call state corresponding to the container call combination is abnormal based on the time series data corresponding to the container call combination and using a preset abnormal state detection model;

[0010] When an exception occurs in the call state corresponding to any container call combination, an exception propagation path corresponding to the any container call combination is generated based on the source container and the target container included in the any container call combination and through the container call relationship graph corresponding to the containerized cluster.

[0011] According to another aspect of the present application, a network traffic anomaly detection device is provided, which is applied to a containerized cluster. The device includes:

[0012] a data acquisition module, configured to, in response to a network traffic anomaly detection instruction for the containerized cluster, call a network traffic monitoring tool for the containerized cluster, and acquire network communication data corresponding to the containerized cluster based on the network traffic monitoring tool;

[0013] A time series data construction module is used to collect statistics on the network communication data according to a first preset time interval, and dynamically construct time series data corresponding to each container call combination in the containerized cluster based on the statistical results and a preset time window length, wherein the container call combination includes a source container and a target container having a call relationship, and the time series data includes communication volume statistics corresponding to multiple time intervals;

[0014] A call status determination module is configured to determine, for each container call combination, whether the call status corresponding to the container call combination is abnormal based on the time series data corresponding to the container call combination and using a preset abnormal state detection model;

[0015] The exception propagation path generation module is used to generate the exception propagation path corresponding to any container call combination based on the source container and target container included in any container call combination and the container call relationship graph corresponding to the containerized cluster when there is an exception in the call status corresponding to the any container call combination.

[0016] According to another aspect of the present application, a storage medium is provided, on which a computer program is stored. When the program is executed by a processor, the above-mentioned network traffic anomaly detection method is implemented.

[0017] According to another aspect of the present application, a computer device is provided, including a storage medium, a processor, and a computer program stored on the storage medium and executable on the processor, wherein the processor implements the above-mentioned network traffic anomaly detection method when executing the program.

[0018] By means of the above technical solution, the present application provides a network traffic anomaly detection method and device, storage medium, and computer equipment. When a network traffic anomaly detection instruction is received, the method can respond to the instruction and call a pre-deployed network traffic monitoring tool in the containerized cluster to obtain network communication data from the network traffic monitoring tool. Afterwards, the network communication data can be segmented and counted according to a first preset time interval. Then, based on the statistical results and the preset time window length, time series data is constructed for each container call combination. Furthermore, for a series of time series data corresponding to each container call combination, the time series data can be sequentially input into a preset abnormal state detection model according to the generation time of the time series data, and the preset abnormal state detection model is used to determine whether the time series data reflects that the call state corresponding to the container call combination at this time is abnormal. If the preset abnormal state detection model identifies that a certain time series data indicates that the container call combination has an abnormal call state at the corresponding time, then the source container and target container corresponding to the container call combination can be determined, and then the abnormal propagation path can be generated based on the container call relationship graph of the containerized cluster. The embodiment of the present application utilizes network traffic monitoring tools in a containerized cluster to collect network communication data, eliminating the need for additional network traffic monitoring tools and reducing the complexity of the solution implementation. By dynamically constructing time series data and analyzing the time series data using a preset abnormal state detection model to obtain call state detection results, real-time detection and precise location of network anomalies are achieved. By generating abnormal propagation paths through a container call relationship graph, abnormal propagation relationships can be quickly identified. The embodiment of the present application can not only effectively address the complexity of network anomaly detection under a microservice architecture, but also significantly improve the accuracy and efficiency of anomaly detection.

[0019] The above description is only an overview of the technical solution of the present application. In order to more clearly understand the technical means of the present application, it can be implemented in accordance with the contents of the specification. In order to make the above and other purposes, features and advantages of the present application more obvious and easy to understand, the specific implementation methods of the present application are listed below. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0021] Figure 1 A schematic diagram of a flow chart of a method for detecting anomalies in network traffic provided by an embodiment of the present application is shown;

[0022] Figure 2 A schematic diagram illustrating a flow chart of another method for detecting anomalies in network traffic provided by an embodiment of the present application is shown;

[0023] Figure 3 A schematic diagram of the structure of a network traffic anomaly detection device provided in an embodiment of the present application is shown;

[0024] Figure 4 A schematic diagram of the device structure of a computer device provided in an embodiment of the present application is shown. DETAILED DESCRIPTION

[0025] The present application will be described in detail below with reference to the accompanying drawings and in combination with embodiments. It should be noted that, unless there is a conflict, the embodiments and features in the embodiments of the present application can be combined with each other.

[0026] In this embodiment, a method for detecting anomalies in network traffic is provided, which is applied to a containerized cluster. Figure 1 As shown, the method includes:

[0027] Step 101: In response to a network traffic anomaly detection instruction for the containerized cluster, a network traffic monitoring tool of the containerized cluster is called, and network communication data corresponding to the containerized cluster is obtained based on the network traffic monitoring tool.

[0028] Step 102: Statistics are performed on the network communication data according to a first preset time interval, and time series data corresponding to each container call combination in the containerized cluster is dynamically constructed based on the statistical results and the preset time window length, wherein the container call combination includes a source container and a target container with a call relationship, and the time series data includes communication volume statistics corresponding to multiple time intervals.

[0029] Step 103 : For each container call combination, determine whether the call state corresponding to the container call combination is abnormal based on the time series data corresponding to the container call combination and by using a preset abnormal state detection model.

[0030] Step 104: When an exception occurs in the call state corresponding to any container call combination, an exception propagation path corresponding to the any container call combination is generated based on the source container and the target container included in the any container call combination and through the container call relationship graph corresponding to the containerized cluster.

[0031] A network traffic anomaly detection method provided in an embodiment of the present application can be applied to a containerized cluster, such as a Kubernetes cluster. When an operation and maintenance personnel or an automated system issues a network traffic anomaly detection instruction, the instruction can be responded to and the network traffic anomaly detection process can be started. The network traffic anomaly detection instruction can be generated based on a scheduled task (such as once an hour), an event trigger (such as detecting a sudden increase in network traffic), or a manual trigger. After responding to the instruction, a network traffic monitoring tool pre-deployed in the containerized cluster can be called. Here, the network traffic monitoring tool can be an existing tool in the containerized cluster, such as Hubble UI. The network traffic monitoring tool can collect network communication data between different containers in the containerized cluster, wherein each piece of network communication data can include an identifier of the source container (the container that initiates the communication request), an identifier of the target container (the container that receives the communication request) (the identifier can be a container ID, service name, etc.), a communication timestamp (recording the time when the data packet is sent or received), and other information. Here, the network communication data can be obtained in real time or at a preset frequency.

[0032] After acquiring network communication data, it can be segmented and statistically analyzed according to a first preset time interval (e.g., 5 seconds, 10 seconds). The selection of the first preset time interval can be determined by balancing real-time performance with computational overhead. Assuming the first preset time interval is 5 seconds, the network communication data within each 5-second period can be grouped according to the communication timestamp for subsequent statistical analysis. This statistical analysis can include traffic volume statistics, such as request counts. Next, based on the statistical results and a preset time window length (e.g., 30 seconds, 1 minute), time series data is constructed for each container call combination. Time series data is an ordered set of data points, each corresponding to traffic statistics within a time interval. For example, if the preset time window length is 30 seconds and the first preset time interval is 5 seconds, each time series data item can include traffic statistics for six time intervals, specifically represented as (A, B, C, D, E, F), where A through F represent traffic statistics corresponding to adjacent time intervals. Furthermore, as time passes, time series data can be continuously generated for each container call combination according to a preset window sliding rule. For example, if the preset window sliding rule is to slide 3 time intervals each time, then the next time series data of the time series data (A, B, C, D, E, F) can be expressed as (D, E, F, G, H, I). In this way, time series data can be dynamically constructed for each container call combination.

[0033] Furthermore, the time series data corresponding to each container call combination can be sequentially input into a preset abnormal state detection model according to the time the time series data was generated. The preset abnormal state detection model then determines whether the time series data indicates that the call state corresponding to the container call combination at that time is abnormal. The preset abnormal state detection model can be constructed based on statistical methods, machine learning algorithms, or deep learning models. Call state anomalies can manifest as a sudden increase or decrease in communication volume within a certain time interval, or abnormal peaks in periodic fluctuations.

[0034] If the preset abnormal state detection model identifies that a certain time series data indicates that the container call combination has a call state abnormality at the corresponding time, then the source container and target container corresponding to the container call combination can be determined. Then, based on the container call relationship graph of the containerized cluster, a path search algorithm (such as depth-first search, breadth-first search) is used to generate an abnormal propagation path. This path may involve multiple upstream containers and call relationships. This is because the current container call combination has an abnormality. It may be that the container call combination itself has a call abnormality, or it may be that the upstream call has an abnormality that indirectly causes the container call combination to detect a call abnormality. Here, the container call relationship graph can be pre-built or dynamically generated to represent the call relationship between containers in the containerized cluster. The container call relationship graph can be a directed graph, in which nodes represent containers and edges represent call relationships between containers. The generated abnormal propagation path can be displayed to operation and maintenance personnel in graphical or textual form to help them quickly understand how the abnormality propagates between containers.

[0035] In a specific embodiment in the healthcare field, large-scale medical information systems are typically implemented using containerized clusters, where each container represents a different medical application module in the medical information system (e.g., an electronic medical record system, an imaging diagnostic system, a pharmacy management system, patient monitoring equipment, etc.). These modules collaborate with each other through data communication (network traffic) to jointly provide medical services. When the medical information system's operations and maintenance personnel or security monitoring system issues a network traffic anomaly detection command, a network traffic monitoring tool in the medical information system can be invoked to collect network communication data between the various medical application modules. This data may include transmission time, source module and destination module identifiers, etc. The collected network communication data is then statistically analyzed at a first predetermined time interval (e.g., every minute, every hour). Based on the statistical results and a predetermined time window length (e.g., one day, one week), time series data is constructed for each medical application module call combination (container call combination). The time series data records the communication volume (e.g., the number of data transmissions) between two medical application modules within different time intervals. For each medical application module call combination (container call combination), the time series data is analyzed using a predetermined anomaly detection model (e.g., a machine learning-based anomaly detection algorithm). The model can determine whether there are any anomalies in the call relationship, such as a sudden increase in communication volume (which may indicate a data leak or malicious attack) or an abnormal communication pattern (which may indicate a system failure or configuration error). When a call status anomaly is detected in a medical application module call combination, an abnormal propagation path is generated based on the module call relationship graph. This helps operations and maintenance personnel quickly locate the source of the problem and take appropriate measures to repair or prevent it. The module call relationship graph can be pre-built or dynamically generated by the medical information system, representing the call and dependency relationships between various medical application modules.

[0036] By applying the technical solution of this embodiment, when a network traffic anomaly detection instruction is received, the network traffic monitoring tool pre-deployed in the containerized cluster can be called in response to the instruction to obtain network communication data from the network traffic monitoring tool. Afterwards, these network communication data can be segmented and counted according to the first preset time interval. Then, based on the statistical results and the preset time window length, time series data is constructed for each container call combination. Furthermore, for a series of time series data corresponding to each container call combination, they can be input into the preset abnormal state detection model in sequence according to the generation time of the time series data, and the preset abnormal state detection model is used to determine whether the time series data reflects that the call state corresponding to the container call combination at this time is abnormal. If the preset abnormal state detection model identifies that a certain time series data indicates that the container call combination has a call state abnormality at the corresponding time, then the source container and target container corresponding to the container call combination can be determined at this time, and then the abnormal propagation path can be generated based on the container call relationship graph of the containerized cluster. The embodiment of the present application utilizes network traffic monitoring tools in a containerized cluster to collect network communication data, eliminating the need for additional network traffic monitoring tools and reducing the complexity of the solution implementation. By dynamically constructing time series data and analyzing the time series data using a preset abnormal state detection model to obtain call state detection results, real-time detection and precise location of network anomalies are achieved. By generating abnormal propagation paths through a container call relationship graph, abnormal propagation relationships can be quickly identified. The embodiment of the present application can not only effectively address the complexity of network anomaly detection under a microservice architecture, but also significantly improve the accuracy and efficiency of anomaly detection.

[0037] Furthermore, as a refinement and extension of the specific implementation of the above embodiment, in order to fully illustrate the specific implementation process of this embodiment, another network traffic anomaly detection method is provided, which is applied to a containerized cluster, such as Figure 2 As shown, the method includes:

[0038] Step 201: In response to a network traffic anomaly detection instruction for the containerized cluster, a network traffic monitoring tool of the containerized cluster is called, and network communication data corresponding to the containerized cluster is obtained based on the network traffic monitoring tool.

[0039] Step 202: Determine the number of time intervals included in the preset time window length according to the first preset time interval and the preset time window length.

[0040] Step 203: For each first preset time interval, identify the source container and target container corresponding to each piece of network communication data based on the network communication data within the first preset time interval, generate a container call combination based on the source container and the target container, and count the number of container call combinations corresponding to each container call combination to obtain communication volume statistics corresponding to each container call combination.

[0041] Step 204 : For each container call combination, dynamically construct time series data corresponding to the container call combination based on a preset window sliding rule according to the number of time intervals included in the preset time window length and the communication volume statistics corresponding to each time interval.

[0042] In this embodiment, first, the number of time intervals included in the preset time window length is determined. Specifically, a first preset time interval (e.g., 5 seconds) and a preset time window length (e.g., 1 minute) are determined. The preset time window length is divided by the first preset time interval to obtain the number of time intervals included in the time window. For example, if the preset time window length is 1 minute (60 seconds) and the first preset time interval is 5 seconds, then 12 time intervals are included in the preset time window length. This calculation provides a basis for the subsequent construction of time series data and determines the time range covered by each time series data point.

[0043] Next, count the container call combinations and communication volume within each time interval. Specifically, for each first preset time interval, traverse all network communication data within the time interval. For each piece of network communication data, identify the source container that sends the data and the target container that receives the data. Combine the source container and the target container to form a container call combination. For example, if the source container is "electronic medical record system" and the target container is "imaging diagnosis system", the generated container call combination is "electronic medical record system → imaging diagnosis system". For each container call combination, count the communication volume indicators such as the number of communications that occurred within the time interval to obtain the communication volume statistics corresponding to various container call combinations within each time interval.

[0044] Subsequently, the time series data corresponding to the container call combination is dynamically constructed. Specifically, a sliding window is defined, which slides forward according to the preset time interval. After each slide, the window contains a set of continuous time intervals and their corresponding communication volume statistics. For each container call combination, a time series data is constructed based on the number of time intervals contained in the preset time window length and the communication volume statistics corresponding to each time interval. Each data point in the time series data corresponds to the communication volume statistics within a time interval. As new network communication data arrives, the time series data is updated according to the preset window sliding rules. In other words, the time series data is dynamically constructed and can reflect the latest situation of inter-container calls.

[0045] The embodiments of the present application can achieve fine-grained monitoring of inter-container calls by statistics and construction of time series data based on a first preset time interval; the dynamic construction of time series data enables the system to adapt to dynamic changes in containerized clusters, such as the creation, destruction or migration of containers; by analyzing abnormal patterns in time series data (such as sudden increases in communication volume, abnormal peaks in periodic fluctuations, etc.), potential security threats or system failures can be discovered and handled in a timely manner.

[0046] Step 205: For each time series data corresponding to the container call combination, a preset abnormal state detection model is used to identify the first growth rate of the communication volume statistics data corresponding to each adjacent time interval in the time series data, and the second growth rate of the communication volume statistics data corresponding to the first time interval and the last time interval in the time series data, and determine whether the call state corresponding to the container call combination is abnormal based on each first growth rate and the second growth rate; or, for each time series data corresponding to the container call combination, obtain multiple historical sequence data corresponding to the time series data, and based on the multiple historical sequence data, obtain the predicted sequence data corresponding to the time series data through a preset abnormal state detection model, and compare the time series data and the predicted sequence data, and determine whether the call state corresponding to the container call combination is abnormal based on the comparison result, wherein the time interval corresponding to the predicted sequence data is the same as the time interval corresponding to the time series data.

[0047] In this embodiment, a preset abnormal state detection model is used to analyze the time series data corresponding to each container call combination to determine whether its call state is abnormal. The preset abnormal state detection model can detect call state anomalies based on growth rate analysis or comparison with historical sequence data predictions.

[0048] Specifically, the analysis method based on growth rate is as follows: First, for each of the multiple time series data corresponding to a certain container call combination, the time series data is input into the preset abnormal state detection model, and the growth rate of the traffic statistics data corresponding to each two adjacent time intervals in the time series data is calculated by the preset abnormal state detection model. For example, if the time series data is traffic statistics data arranged in chronological order (such as Q1, Q2, Q3, ..., Q n ), then the first growth rate can be (Q i+1- Q i ) / Q i (For i=1,2,...,n -1). In the financial field, different application modules in various financial business systems interact frequently, and the communication volume (such as the number of data transmissions) of their application module call combinations (such as an investment trading system calling a risk assessment system) within a specific time period is in a state of constant dynamic change. Similarly, in the medical and health field, for example, the communication volume (such as the number of data transmissions) of a certain medical application module call combination in a medical information system (such as an electronic medical record system calling an imaging diagnosis system) within a period of time is constantly changing. The preset abnormal state detection model can calculate the first growth rate of the communication volume in adjacent time intervals in the time series data of the application module call combination. In addition, the growth rate of the communication volume statistics corresponding to the first time interval and the last time interval in the time series data can also be calculated, that is, (Q n- Q1) / Q1, is called the second growth rate. In the financial field or the medical and health field, the second growth rate of the communication volume in the first time interval and the last time interval in the time series data of the above-mentioned application module call combination can also be calculated. Reasonable thresholds can be set in advance for the first growth rate and the second growth rate. These thresholds can be determined based on historical data, business needs or expert experience. The preset abnormal state detection model compares the calculated first growth rate and second growth rate with the set threshold. If any growth rate exceeds the threshold, or the growth rate pattern does not match expectations (such as a sudden large increase or decrease), it may indicate that there is an abnormality in the call state of the container call combination. The embodiment of the present application is intuitive and easy to understand through growth rate analysis, and can quickly identify abnormal changes in communication volume. In addition, the threshold can be adjusted according to different business scenarios and needs to adapt to different anomaly detection needs.

[0049] Comparison method based on historical sequence data prediction: First, for each of the multiple time series data corresponding to a container call combination, the time series data is input into a preset anomaly detection model. The preset anomaly detection model then retrieves the corresponding multiple historical series data. These historical series data can be time series data constructed over a period of time. For example, the multiple historical series data retrieved can be the n historical series data that occurred before and closest to the current time. Next, a preset anomaly detection model (such as a time series prediction model, such as ARIMA or LSTM) is used to extract features from these historical series data to learn the traffic variation pattern. Based on the learned variation pattern, predicted series data is predicted to match the current time series data. The time interval corresponding to the predicted series data is the same as the time interval corresponding to the current time series data. Subsequently, the current time series data is compared with the predicted series data, and the difference (such as mean squared error or absolute error) between the two is calculated. If the difference exceeds a set threshold or the difference pattern does not match the expected pattern, it may indicate that the call status of the container call combination is abnormal. The prediction method based on historical sequence data in the embodiment of the present application can more accurately capture the changing trend of communication volume, thereby improving the accuracy of anomaly detection; it can adapt to complex patterns such as seasonality and trend in communication volume changes, thereby improving the robustness of anomaly detection.

[0050] It should be noted that in practical applications, the two methods can also be combined for comprehensive judgment to improve the accuracy and reliability of anomaly detection.

[0051] Step 206: When there is an exception in the call status corresponding to any container call combination, a call relationship subgraph is constructed based on the source container and the target container included in the any container call combination, and the call relationship subgraph is located from the container call relationship graph corresponding to the containerized cluster according to the subgraph matching algorithm; based on the positioning of the call relationship subgraph in the container call relationship graph, the first upstream propagation path of the first preset level corresponding to the source container and the downstream propagation path of the second preset level corresponding to the target container are determined, and based on the first upstream propagation path and the downstream propagation path, the abnormal propagation path corresponding to the any container call combination is generated.

[0052] In this embodiment, if the call status corresponding to a certain container call combination is determined to be abnormal, then the source container and target container contained in the container call combination can be determined. Based on the source container and the target container, a call relationship subgraph is constructed. This call relationship subgraph only contains the direct call relationship from the source container to the target container. For example, if the source container is the "investment trading system" and the target container is the "risk assessment system", the call relationship subgraph only contains the edge "investment trading system → risk assessment system". For another example, if the source container is the "electronic medical record system" and the target container is the "imaging diagnosis system", the call relationship subgraph only contains the edge "electronic medical record system → imaging diagnosis system". Then, a subgraph matching algorithm (such as the VF2 algorithm, the Ullmann algorithm, etc.) is used to locate the part that matches the constructed call relationship subgraph from the container call relationship graph. The purpose of this step is to confirm the specific position of the source container and the target container in the overall call relationship.

[0053] Then, based on the first preset level, starting from the source container and tracing upstream, a first upstream propagation path corresponding to the source container is generated. For example, if the first preset level is 2, a first upstream propagation path such as "electronic medical record system ← patient monitoring device ← pharmacy management system" can be generated. Here, the first preset level refers to the preset hierarchical depth upstream of the source container, that is, the number of levels traced upstream from the source container (i.e., other containers that call the source container).

[0054] At the same time, based on the second preset level, starting from the target container and tracing downstream, a downstream propagation path corresponding to the target container can be generated. For example, if the second preset level is 1, a downstream propagation path such as "Imaging Diagnostic System → Report Generation System" can be generated. Here, the second preset level refers to the hierarchical depth downstream of the preset target container, that is, the number of levels traced downstream (i.e., other containers called by the target container) from the target container.

[0055] Next, a complete anomaly propagation path is generated based on the first upstream and downstream propagation paths. For example, the anomaly propagation path might be "pharmacy management system → patient monitoring equipment → electronic medical record system → imaging diagnostic system → report generation system." This path illustrates the anomaly's propagation from source to target, helping operations personnel quickly locate the problem and implement appropriate remediation measures.

[0056] By generating an exception propagation path, the embodiments of the present application allow operation and maintenance personnel to clearly see how the exception propagates in the containerized cluster, thereby quickly locating the source of the problem and improving the stability, reliability and operation and maintenance efficiency of the system.

[0057] Step 207: Input the exception detection time corresponding to any container call combination and the exception propagation path into the big model, so as to call the containerized cluster exception knowledge base through the big model, and output the exception cause corresponding to the exception propagation path based on the exception detection time, the exception propagation path and the containerized cluster exception knowledge base; generate a visualization analysis report based on the exception detection time, the exception propagation path and the exception cause, and send the visualization analysis report to the visualization display platform.

[0058] In this embodiment, after generating the exception propagation path corresponding to the container call combination, the large model and the containerized cluster anomaly knowledge base can be further used to analyze the cause of the anomaly and generate a visual analysis report for display. Specifically, the anomaly detection time corresponding to the container call combination (i.e., the time when the anomaly occurred, which can be determined based on time series data) and the anomaly propagation path can be input into the large model. After receiving these inputs, the large model can call the containerized cluster anomaly knowledge base. This knowledge base can contain information such as various historical anomaly cases, anomaly causes, and solutions. The large model can then match and infer historical cases similar to the current anomaly based on the input anomaly detection time and anomaly propagation path in the containerized cluster anomaly knowledge base to find historical cases. Through comparison and analysis, the large model can output the anomaly cause corresponding to the anomaly propagation path. For example, in the healthcare field, if the anomaly propagation path indicates an anomaly in the communication between the "electronic medical record system → imaging diagnostic system", the large model may analyze the anomaly cause as "an overload of the imaging diagnostic system interface" or "data transmission failure due to network delay." It should be noted that through anomaly detection time, the large model can determine whether the current time is a platform promotion day, discount day, etc., thereby further improving the accuracy of anomaly cause analysis. Among them, the containerized cluster anomaly knowledge base can store corresponding special time (platform promotion day, discount day, etc.) nodes.

[0059] Furthermore, a visual analysis report is generated based on the anomaly detection time, anomaly propagation path, and anomaly causes output by the large model. This report can include the time the anomaly occurred, the combination of container calls affected by the anomaly, the specific anomaly propagation path, and the analyzed anomaly causes. To more intuitively display the anomaly, the report can also include visual elements such as charts and flowcharts. For example, a flowchart can be used to illustrate the anomaly propagation path, and a bar chart or line chart can be used to display the changes in communication volume before and after the anomaly occurred. The generated visual analysis report is then sent to a visualization display platform. This platform can be a web interface, mobile application, or other display tool. Operations and maintenance personnel can use this platform to monitor the operating status of the containerized cluster in real time and receive timely warnings and detailed anomaly analysis reports when an anomaly occurs, allowing them to take timely countermeasures. For example, increasing the processing capacity of the "imaging diagnostic system" or optimizing request scheduling strategies.

[0060] In an embodiment of the present application, optionally, the method further includes: obtaining first historical communication data within a target historical time period corresponding to the containerized cluster according to a second preset time interval, extracting container call relationships based on the first historical communication data, and dynamically constructing a first container call relationship graph corresponding to the containerized cluster based on the container call relationships; before "calling the network traffic monitoring tool of the containerized cluster" in step 201, the method further includes: obtaining all second historical communication data of the containerized cluster, and constructing a second container call relationship graph corresponding to the containerized cluster based on the second historical communication data; accordingly, "locating the call relationship subgraph from the container call relationship graph corresponding to the containerized cluster according to the subgraph matching algorithm" in step 206 includes: locating the call relationship subgraph from the latest first container call relationship graph corresponding to the containerized cluster according to the subgraph matching algorithm; when the latest first container call relationship graph does not contain the call relationship subgraph, locating the call relationship subgraph from the second container call relationship graph corresponding to the containerized cluster.

[0061] In this embodiment, the container call relationship graph may include a first container call relationship graph and a second container call relationship graph. The first container call relationship graph may be dynamically constructed. Specifically, the first historical communication data of the containerized cluster within the target historical time period may be obtained at a second preset time interval (such as every hour or every day). These data include communication status data between containers within the target historical time period. Here, the target historical time period may be the same as the second preset time interval, or may be greater than the second preset time interval, and may be determined based on actual needs. The target historical time period may be a period of time between the current time. Then, based on the first historical communication data, the call relationship between the containers is extracted. For example, in the field of medical health, the communication data between various medical application modules may be extracted. Subsequently, based on the extracted container call relationship, the first container call relationship graph corresponding to the containerized cluster is dynamically constructed. This graph reflects the call relationship of the containerized cluster within the target historical time period. Dynamic here means that the first container call relationship graph is constructed once every second preset time interval.

[0062] Furthermore, a static and unchanging second container call relationship graph can be constructed. Specifically, before invoking the network traffic monitoring tool for the containerized cluster, all second historical communication data for the containerized cluster is obtained. This data includes all communication records within the containerized cluster before the network traffic monitoring tool is invoked. Subsequently, based on the second historical communication data, a second container call relationship graph corresponding to the containerized cluster is constructed. This graph provides a more comprehensive and long-term container call relationship.

[0063] When locating a call relationship subgraph, first perform subgraph matching from the latest first container call relationship graph. For example, in the healthcare field, you can first locate the call relationship subgraph "Electronic Medical Record System → Imaging Diagnosis System" from the latest first container call relationship graph. If the latest first container call relationship graph does not contain the required call relationship subgraph (for example, no calls occurred within the target historical time period), fall back to the second container call relationship graph for positioning. This ensures that even when certain call relationships are missing from the latest relationship graph, accurate analysis can still be performed through the historical relationship graph.

[0064] The embodiment of the present application dynamically constructs the first container call relationship graph on a regular basis, which is suitable for situations where the microservice architecture continuously adjusts the call relationship, ensures the real-time and accuracy of the relationship graph, and helps to promptly discover and handle abnormal situations; when the call relationship cannot be found in the latest relationship graph, it can fall back to the second container call relationship graph, thereby improving the flexibility and reliability of the system.

[0065] In an embodiment of the present application, optionally, the "generating an abnormal propagation path corresponding to any container call combination based on the first upstream propagation path and the downstream propagation path" in step 206 includes: if, among the remaining container call combinations included in the first upstream propagation path, there is at least one container call combination whose corresponding call status is normal, then marking each container call combination in the first upstream propagation path with the corresponding call status detection result, and generating an abnormal propagation path corresponding to any container call combination based on the marked first upstream propagation path and the downstream propagation path; if, among the remaining container call combinations included in the first upstream propagation path, the corresponding call status of each container call combination is abnormal, then determining the source container in the upstreammost container call combination in the first upstream propagation path, and based on the container call relationship graph, determining the second upstream propagation path of the first preset level corresponding to the source container in the upstreammost container call combination, updating the first upstream propagation path according to the second upstream propagation path, and generating an abnormal propagation path corresponding to any container call combination based on the updated first upstream propagation path and the downstream propagation path.

[0066] In this embodiment, the abnormal propagation path should include the source of the abnormality, while the upstream propagation path of the first preset level may not include the source of the abnormality, that is, the source of the abnormality is further away from the source container. Therefore, when generating the abnormal propagation path, the state of the container call combination in the first upstream propagation path can be first detected to determine whether it includes the source of the abnormality. Specifically, first, the call state (normal or abnormal) of each container call combination in the first upstream propagation path is determined. According to the call state detection result, different strategies are adopted to generate the abnormal propagation path.

[0067] If there is at least one container call combination whose call status is normal among the remaining container call combinations included in the first upstream propagation path, the corresponding call status detection result is marked for each container call combination in the first upstream propagation path. Subsequently, based on the marked first upstream propagation path (which contains markings of normal and abnormal states) and the downstream propagation path, a complete abnormal propagation path is generated. This path can clearly indicate how the abnormality propagates from the source to the target, and can also identify which container call combinations are in a normal state, thereby accurately identifying the source of the abnormality.

[0068] Suppose that in a medical information system in the medical and health field, there are the following container call combinations: patient information management system → drug inventory management system (used to query drug inventory), drug inventory management system → pharmacy dispensing system (used to generate dispensing instructions), pharmacy dispensing system → patient medicine collection window (used to notify patients to pick up medicine). Suppose that the preset abnormal state detection model detects that the container call combination of "pharmacy dispensing system → patient medicine collection window" has an abnormality, resulting in the patient being unable to pick up medicine in time. The first preset level is 2, then the first upstream propagation path corresponding to the container call combination of "pharmacy dispensing system → patient medicine collection window" is: patient information management system → drug inventory management system → pharmacy dispensing system. If the detection finds that the call status of "patient information management system → drug inventory management system" is normal, the call status of "drug inventory management system → pharmacy dispensing system" is also normal, but the call status of "pharmacy dispensing system → patient medicine collection window" is abnormal, then the status of these three container call combinations is marked, and an abnormal propagation path is generated (downstream propagation path is not considered): , indicating that the source of the exception is the container call combination of "Pharmacy Dispensing System" → "Patient Medication Collection Window".

[0069] If the call status of each container call combination in the remaining container call combinations included in the first upstream propagation path is abnormal, further tracing the source of the abnormality is necessary. First, determine the source container in the most upstream container call combination in the first upstream propagation path. Based on the container call relationship graph, determine a second upstream propagation path at the first preset level corresponding to the source container in the most upstream container call combination. This path may involve containers or services further upstream. Next, merge the second upstream propagation path with the first upstream propagation path, updating the first upstream propagation path to include more complete abnormality propagation information. Furthermore, a complete abnormality propagation path is generated based on the updated first upstream propagation path and the downstream propagation path. During this process, it is also necessary to determine whether at least one container call combination in the remaining container call combinations included in the updated first upstream propagation path has a normal call status. If so, a complete abnormality propagation path is generated based on the updated first upstream propagation path and the downstream propagation path. If not, a new second upstream propagation path is determined until at least one container call combination in the remaining container call combinations included in the updated first upstream propagation path has a normal call status.

[0070] In the aforementioned medical information system, if the detection finds that the calling status of the three container call combinations of "patient information management system → drug inventory management system", "drug inventory management system → pharmacy dispensing system" and "pharmacy dispensing system → patient medicine collection window" are all abnormal, it is necessary to further trace the source of the abnormality. Specifically, the "patient information management system" is determined to be the source container in the upstream container call combination, and based on the container call relationship graph, its second upstream propagation path of the first preset level (for example, tracing back to the first preset level) is determined, that is, "appointment guidance system → patient appointment system → patient information management system". Then the updated first upstream propagation path is: appointment guidance system → patient appointment system → patient information management system → drug inventory management system → pharmacy dispensing system. If the detection finds that the calling status of "appointment guidance system → patient appointment system" is normal and the calling status of "patient appointment system → patient information management system" is abnormal, then the status of these four container call combinations is marked, and an abnormal propagation path is generated (without considering the downstream propagation path): , indicating that the source of the exception is the container call combination of "patient appointment system → patient information management system".

[0071] Further, as Figure 1 The specific implementation of the method, the embodiment of the present application provides a network traffic anomaly detection device, which is applied to a containerized cluster, such as Figure 3 As shown, the device includes:

[0072] a data acquisition module, configured to, in response to a network traffic anomaly detection instruction for the containerized cluster, call a network traffic monitoring tool for the containerized cluster, and acquire network communication data corresponding to the containerized cluster based on the network traffic monitoring tool;

[0073] A time series data construction module is used to collect statistics on the network communication data according to a first preset time interval, and dynamically construct time series data corresponding to each container call combination in the containerized cluster based on the statistical results and a preset time window length, wherein the container call combination includes a source container and a target container having a call relationship, and the time series data includes communication volume statistics corresponding to multiple time intervals;

[0074] A call status determination module is configured to determine, for each container call combination, whether the call status corresponding to the container call combination is abnormal based on the time series data corresponding to the container call combination and using a preset abnormal state detection model;

[0075] The exception propagation path generation module is used to generate the exception propagation path corresponding to any container call combination based on the source container and target container included in any container call combination and the container call relationship graph corresponding to the containerized cluster when there is an exception in the call status corresponding to the any container call combination.

[0076] Optionally, the time series data construction module is used to:

[0077] Determining the number of time intervals included in the preset time window length according to the first preset time interval and the preset time window length;

[0078] For each first preset time interval, identifying the source container and target container corresponding to each piece of network communication data based on the network communication data within the first preset time interval, generating a container call combination based on the source container and the target container, and counting the number of calls corresponding to each container call combination to obtain communication volume statistics corresponding to each container call combination;

[0079] For each container call combination, according to the number of time intervals contained in the preset time window length and the communication volume statistics corresponding to each time interval, based on the preset window sliding rule, the time series data corresponding to the container call combination is dynamically constructed.

[0080] Optionally, the calling state determination module is configured to:

[0081] For each time series data corresponding to the container call combination, a first growth rate of the communication volume statistics data corresponding to each adjacent time interval in the time series data and a second growth rate of the communication volume statistics data corresponding to the first time interval and the last time interval in the time series data are identified by a preset abnormal state detection model, and based on each first growth rate and the second growth rate, it is determined whether the call state corresponding to the container call combination is abnormal; or

[0082] For each time series data corresponding to the container call combination, multiple historical sequence data corresponding to the time series data are obtained, and based on the multiple historical sequence data, predicted sequence data corresponding to the time series data is obtained by using a preset abnormal state detection model, and the time series data and the predicted sequence data are compared. According to the comparison result, it is determined whether the call state corresponding to the container call combination is abnormal, wherein the time interval corresponding to the predicted sequence data is the same as the time interval corresponding to the time series data.

[0083] Optionally, the abnormal propagation path generation module is used to:

[0084] Based on the source container and the target container included in any container call combination, a call relationship subgraph is constructed, and according to a subgraph matching algorithm, the call relationship subgraph is located in the container call relationship graph corresponding to the containerized cluster;

[0085] Based on the positioning of the call relationship subgraph in the container call relationship graph, a first upstream propagation path of a first preset level corresponding to the source container and a downstream propagation path of a second preset level corresponding to the target container are determined, and based on the first upstream propagation path and the downstream propagation path, an abnormal propagation path corresponding to any container call combination is generated.

[0086] Optionally, the device further comprises:

[0087] a relationship graph generation module, configured to obtain, at a second preset time interval, first historical communication data within a target historical time period corresponding to the containerized cluster, extract container call relationships based on the first historical communication data, and dynamically construct a first container call relationship graph corresponding to the containerized cluster based on the container call relationships;

[0088] The relationship diagram generating module is further used for:

[0089] Before calling the network traffic monitoring tool of the containerized cluster, obtaining all second historical communication data of the containerized cluster, and constructing a second container call relationship graph corresponding to the containerized cluster based on the second historical communication data;

[0090] Accordingly, the abnormal propagation path generation module is used to:

[0091] Locating the call relationship subgraph from the latest first container call relationship graph corresponding to the containerized cluster according to a subgraph matching algorithm;

[0092] When the latest first container call relationship graph does not include the call relationship subgraph, the call relationship subgraph is located from the second container call relationship graph corresponding to the containerized cluster.

[0093] Optionally, the abnormal propagation path generation module is used to:

[0094] If, among the remaining container call combinations included in the first upstream propagation path, at least one container call combination has a normal call status, each container call combination in the first upstream propagation path is marked with the corresponding call status detection result, and an abnormal propagation path corresponding to any container call combination is generated based on the marked first upstream propagation path and the downstream propagation path;

[0095] If the call status corresponding to each container call combination in the remaining container call combinations included in the first upstream propagation path is an abnormal state, determine the source container in the upstreammost container call combination in the first upstream propagation path, and based on the container call relationship graph, determine the second upstream propagation path of the first preset level corresponding to the source container in the upstreammost container call combination, update the first upstream propagation path according to the second upstream propagation path, and generate the abnormal propagation path corresponding to any container call combination based on the updated first upstream propagation path and the downstream propagation path.

[0096] Optionally, the apparatus further comprises a report generating module; the report generating module is configured to:

[0097] After generating the exception propagation path corresponding to any container call combination, the exception detection time corresponding to any container call combination and the exception propagation path are input into the large model, so as to call the containerized cluster exception knowledge base through the large model, and output the exception cause corresponding to the exception propagation path based on the exception detection time, the exception propagation path and the containerized cluster exception knowledge base;

[0098] A visualization analysis report is generated based on the anomaly detection time, the anomaly propagation path, and the anomaly cause, and the visualization analysis report is sent to a visualization display platform.

[0099] It should be noted that for other corresponding descriptions of the functional units involved in the network traffic anomaly detection device provided in the embodiment of the present application, please refer to Figures 1 to 2 The corresponding description in the method will not be repeated here.

[0100] The present application also provides a computer device, which can be a personal computer, a server, a network device, etc. Figure 4 As shown, the computer device includes a bus, a processor, a memory, and a communication interface, and may also include an input / output interface and a display device. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program, and a database. The internal memory provides an environment for the operation of the operating system and computer program in the non-volatile storage medium. The database of the computer device is used to store location information. The network interface of the computer device is used to communicate with an external terminal via a network connection. When the computer program is executed by the processor, the steps of each method embodiment are implemented.

[0101] Those skilled in the art will understand that Figure 4The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than shown in the figure, or combine certain components, or have a different component arrangement.

[0102] In one embodiment, a computer-readable storage medium is provided. The computer-readable storage medium may be non-volatile or volatile, and stores a computer program thereon. When the computer program is executed by a processor, the steps in the above-mentioned method embodiments are implemented.

[0103] In one embodiment, a computer program product is provided, including a computer program, which implements the steps in the above method embodiments when executed by a processor.

[0104] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties.

[0105] Those skilled in the art will appreciate that all or part of the processes in the above-mentioned embodiment methods can be implemented by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, database or other media used in the embodiments provided in this application may include at least one of non-volatile and volatile memory. Non-volatile memory may include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory may include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The database involved in the various embodiments provided herein may include at least one of a relational database and a non-relational database. Non-relational databases may include, but are not limited to, distributed databases based on blockchains. The processor involved in the various embodiments provided herein may be, but are not limited to, a general-purpose processor, a central processing unit, a graphics processing unit, a digital signal processor, a programmable logic unit, a data processing logic unit based on quantum computing, and the like.

[0106] The technical features of the above embodiments can be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0107] The above-described embodiments merely represent several implementation methods of the present application. While the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the present application. It should be noted that a person of ordinary skill in the art may make various modifications and improvements without departing from the spirit of the present application, and these modifications and improvements fall within the scope of protection of the present application. Therefore, the scope of protection of the present application shall be determined by the appended claims.

Claims

1. A method for detecting anomalies in network traffic, characterized in that: Applied to a containerized cluster, the method includes: In response to a network traffic anomaly detection instruction for the containerized cluster, calling a network traffic monitoring tool for the containerized cluster, and obtaining network communication data corresponding to the containerized cluster based on the network traffic monitoring tool; At a first preset time interval, statistics are performed on the network communication data, and time series data corresponding to each container call combination in the containerized cluster is dynamically constructed based on the statistical results and a preset time window length, wherein the container call combination includes a source container and a target container having a call relationship, and the time series data includes communication volume statistics corresponding to multiple time intervals; For each container call combination, determine whether the call state corresponding to the container call combination is abnormal based on the time series data corresponding to the container call combination and using a preset abnormal state detection model; When an exception occurs in the call state corresponding to any container call combination, an exception propagation path corresponding to the any container call combination is generated based on the source container and the target container included in the any container call combination and through the container call relationship graph corresponding to the containerized cluster.

2. The method according to claim 1, characterized in that The method of performing statistics on the network communication data according to the first preset time interval, and dynamically constructing time series data corresponding to each container call combination in the containerized cluster based on the statistical results and the preset time window length, includes: Determining the number of time intervals included in the preset time window length according to the first preset time interval and the preset time window length; For each first preset time interval, identifying the source container and target container corresponding to each piece of network communication data based on the network communication data within the first preset time interval, generating a container call combination based on the source container and the target container, and counting the number of calls corresponding to each container call combination to obtain communication volume statistics corresponding to each container call combination; For each container call combination, according to the number of time intervals contained in the preset time window length and the communication volume statistics corresponding to each time interval, based on the preset window sliding rule, the time series data corresponding to the container call combination is dynamically constructed.

3. The method according to claim 1, characterized in that For each container call combination, determining whether a call state corresponding to the container call combination is abnormal based on the time series data corresponding to the container call combination and using a preset abnormal state detection model includes: For each time series data corresponding to the container call combination, a first growth rate of the communication volume statistics data corresponding to each adjacent time interval in the time series data and a second growth rate of the communication volume statistics data corresponding to the first time interval and the last time interval in the time series data are identified by a preset abnormal state detection model, and based on each first growth rate and the second growth rate, it is determined whether the call state corresponding to the container call combination is abnormal; or For each time series data corresponding to the container call combination, multiple historical sequence data corresponding to the time series data are obtained, and based on the multiple historical sequence data, predicted sequence data corresponding to the time series data is obtained by using a preset abnormal state detection model, and the time series data and the predicted sequence data are compared. According to the comparison result, it is determined whether the call state corresponding to the container call combination is abnormal, wherein the time interval corresponding to the predicted sequence data is the same as the time interval corresponding to the time series data.

4. The method according to claim 1, wherein The generating, based on the source container and the target container included in any container call combination and through the container call relationship graph corresponding to the containerized cluster, an exception propagation path corresponding to any container call combination includes: Based on the source container and the target container included in any container call combination, a call relationship subgraph is constructed, and according to a subgraph matching algorithm, the call relationship subgraph is located in the container call relationship graph corresponding to the containerized cluster; Based on the positioning of the call relationship subgraph in the container call relationship graph, a first upstream propagation path of a first preset level corresponding to the source container and a downstream propagation path of a second preset level corresponding to the target container are determined, and based on the first upstream propagation path and the downstream propagation path, an abnormal propagation path corresponding to any container call combination is generated.

5. The method according to claim 4, characterized in that The method further comprises: According to a second preset time interval, first historical communication data within a target historical time period corresponding to the containerized cluster is obtained, and container call relationships are extracted based on the first historical communication data, and a first container call relationship graph corresponding to the containerized cluster is dynamically constructed based on the container call relationships; Before calling the network traffic monitoring tool of the containerized cluster, the method further includes: Acquire all second historical communication data of the containerized cluster, and construct a second container call relationship graph corresponding to the containerized cluster based on the second historical communication data; Accordingly, locating the call relationship subgraph from the container call relationship graph corresponding to the containerized cluster according to the subgraph matching algorithm includes: Locating the call relationship subgraph from the latest first container call relationship graph corresponding to the containerized cluster according to a subgraph matching algorithm; When the latest first container call relationship graph does not include the call relationship subgraph, the call relationship subgraph is located from the second container call relationship graph corresponding to the containerized cluster.

6. The method according to claim 4 or 5, characterized in that Generating the exception propagation path corresponding to any container call combination according to the first upstream propagation path and the downstream propagation path includes: If, among the remaining container call combinations included in the first upstream propagation path, at least one container call combination has a normal call status, each container call combination in the first upstream propagation path is marked with the corresponding call status detection result, and an abnormal propagation path corresponding to any container call combination is generated based on the marked first upstream propagation path and the downstream propagation path; If the call status corresponding to each container call combination in the remaining container call combinations included in the first upstream propagation path is an abnormal state, then determine the source container in the most upstream container call combination in the first upstream propagation path, and based on the container call relationship graph, determine the second upstream propagation path of the first preset level corresponding to the source container in the most upstream container call combination, update the first upstream propagation path according to the second upstream propagation path, and generate the abnormal propagation path corresponding to any container call combination based on the updated first upstream propagation path and the downstream propagation path.

7. The method according to claim 1, characterized in that After generating the exception propagation path corresponding to any container call combination, the method further includes: Inputting the anomaly detection time corresponding to any container call combination and the anomaly propagation path into the large model, so as to call the containerized cluster anomaly knowledge base through the large model, and outputting the anomaly cause corresponding to the anomaly propagation path based on the anomaly detection time, the anomaly propagation path, and the containerized cluster anomaly knowledge base; A visualization analysis report is generated based on the anomaly detection time, the anomaly propagation path, and the anomaly cause, and the visualization analysis report is sent to a visualization display platform.

8. A network traffic anomaly detection device, characterized in that: Applied to a containerized cluster, the device includes: a data acquisition module, configured to, in response to a network traffic anomaly detection instruction for the containerized cluster, call a network traffic monitoring tool for the containerized cluster, and acquire network communication data corresponding to the containerized cluster based on the network traffic monitoring tool; A time series data construction module is used to collect statistics on the network communication data according to a first preset time interval, and dynamically construct time series data corresponding to each container call combination in the containerized cluster based on the statistical results and a preset time window length, wherein the container call combination includes a source container and a target container having a call relationship, and the time series data includes communication volume statistics corresponding to multiple time intervals; A call status determination module is configured to determine, for each container call combination, whether the call status corresponding to the container call combination is abnormal based on the time series data corresponding to the container call combination and using a preset abnormal state detection model; The exception propagation path generation module is used to generate the exception propagation path corresponding to any container call combination based on the source container and target container included in any container call combination and the container call relationship graph corresponding to the containerized cluster when there is an exception in the call status corresponding to the any container call combination.

9. A storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the method according to any one of claims 1 to 7 is implemented.

10. A computer device comprising a storage medium, a processor, and a computer program stored in the storage medium and executable on the processor, wherein: When the processor executes the computer program, the method according to any one of claims 1 to 7 is implemented.

Images