Method and device for determining traffic alarm information and electronic equipment
By predicting the multi-dimensional traffic data of the containerized management platform and filtering the two-layer feedback mechanism, the problem of delayed traffic prediction and alarm time in the existing technology is solved, and accurate alarms and efficient operation and maintenance are achieved.
Patent Information
- Application Number
- CN202510821214.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-06-18
- Publication Date
- 2025-08-15
AI Technical Summary
In the prior art, the traffic prediction and alarm of the containerized management platform rely on real-time monitoring and threshold alarms, resulting in delayed timeliness, low accuracy, and inability to effectively filter alarms, forming an "alarm storm", which brings trouble to operation and maintenance personnel.
The two-layer feedback mechanism is used to predict and filter the multi-dimensional traffic data of the containerized management platform, including the prediction model to predict traffic data in future time periods, filter out abnormal traffic data through the first and second verification layers and generate alarm information.
It improves the accuracy of traffic prediction and the accuracy of alarms, reduces the false alarm rate, reduces the operation and maintenance costs, and improves the fault processing efficiency and resource utilization rate.
Smart Images

Figure CN120498964A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of cloud computing, and more specifically, to a method, device, and electronic device for determining traffic alarm information. Background Art
[0002] As enterprises deepen their digital transformation, the widespread adoption of containerization technology has become a core engine supporting the elasticity and agility of cloud-native businesses. However, the dynamic nature of container clusters, the complex inter-microservice call relationships, and the high fluctuations in user traffic present significant challenges in resource management and fault prevention. While existing technologies for monitoring containerized environments on containerized management platforms can provide real-time monitoring data, traffic forecasting and alerting solutions often rely on offline historical data analysis and static threshold-based alerting mechanisms. Operations teams periodically analyze traffic logs from the past few weeks or trigger alerts based on fixed thresholds (e.g., CPU usage exceeding 80%). This results in low data timeliness and inaccurate forecasts, making it difficult to meet real-time decision-making requirements. Furthermore, when traffic anomalies occur, the monitoring system triggers a large number of alerts, creating an "alert storm." These alerts are often highly correlated and redundant, placing an unnecessary burden on operations personnel and making it difficult to distinguish between alerts that truly require immediate action.
[0003] To address the above-mentioned problems, no effective solutions have been proposed so far. Summary of the Invention
[0004] The embodiments of the present application provide a method, device and electronic device for determining traffic alarm information, so as to at least solve the technical problem that traffic prediction and alarm of a containerized management platform rely solely on real-time monitoring and threshold alarms, and alarms are triggered only after a problem occurs and the alarms cannot be filtered, resulting in delayed traffic prediction and alarm timeliness and low accuracy.
[0005] According to one aspect of an embodiment of the present application, a method for determining traffic alarm information is provided, including: detecting multi-dimensional traffic data corresponding to a containerized management platform, wherein the multi-dimensional traffic data includes network traffic data and performance indicator data of a cluster managed by the containerized management platform; using a prediction model to predict the multi-dimensional traffic data for a future time period to obtain a predicted traffic data set corresponding to the multi-dimensional traffic data, wherein the predicted traffic data set includes a predicted value of the multi-dimensional traffic data at each predicted time point in the future time period; using the first verification layer in a two-layer feedback mechanism to filter the predicted traffic data set to obtain a sub-prediction traffic data set; using the second verification layer in the two-layer feedback mechanism to determine abnormal traffic data from the sub-prediction traffic data set, and determining the alarm information corresponding to the abnormal traffic data.
[0006] According to some embodiments of the present application, the first verification layer in the double-layer feedback mechanism is used to filter the predicted traffic data set to obtain a sub-predicted traffic data set, including: obtaining the actual traffic data corresponding to each multi-dimensional traffic data prediction value in the predicted traffic data set; determining the first error value corresponding to each multi-dimensional traffic data prediction value based on at least the multi-dimensional traffic data prediction value and the actual traffic data corresponding to each multi-dimensional traffic data prediction value; and combining the multi-dimensional traffic data prediction values in the predicted traffic data set whose first error value is greater than the first threshold into a sub-predicted traffic data set according to the arrangement order of the multi-dimensional traffic data prediction values in the predicted traffic data set.
[0007] According to some embodiments of the present application, the second verification layer in the double-layer feedback mechanism is used to determine abnormal traffic data from the sub-prediction traffic data set, including: determining the second error value between each multi-dimensional traffic data prediction value in the sub-prediction traffic data set and the corresponding actual traffic data through a prediction model, and forming each second error value into an error sequence according to the arrangement order of the multi-dimensional traffic data prediction value in the sub-prediction traffic data set; smoothing the error sequence to obtain a smoothed error sequence; for the smoothed error sequence, when the average value of multiple second error values in a preset continuous window is greater than a second threshold, determining multiple multi-dimensional traffic data prediction values corresponding to the multiple second error values in the preset continuous window as abnormal traffic data, wherein the second threshold is less than the first threshold, and the preset continuous window is used to indicate a sub-error sequence of a preset length in the smoothed error sequence.
[0008] According to some embodiments of the present application, the method also includes: determining the abnormal traffic data and the second error value corresponding to the abnormal traffic data as historical feedback data, and storing the historical feedback data in a database; obtaining the historical feedback data in the database and the historical multi-dimensional traffic data of the preset time period in the containerized management platform every preset time period; determining the historical feedback data and the historical multi-dimensional traffic data of the preset time period as an incremental training set; and re-training the prediction model based on the incremental training set to obtain an updated prediction model.
[0009] According to some embodiments of the present application, before using the prediction model to predict the multi-dimensional performance indicators based on the multi-dimensional traffic data, the method also includes: converting the data format of the multi-dimensional traffic data into a time series data format supported by the prediction model.
[0010] According to some embodiments of the present application, before using a prediction model to predict multi-dimensional traffic data for a future time period, the initial prediction model is trained in the following manner to obtain a prediction model: obtaining a historical data set of the containerized management platform, wherein the historical data set includes historical multi-dimensional traffic data corresponding to the containerized management platform within a historical preset time period; dividing the historical data set into a training set, a test set, and a validation set; and training the initial prediction model based on the training set, the test set, and the validation set to obtain a prediction model.
[0011] According to some embodiments of the present application, the training set includes multiple training instances, and the multiple training instances are determined in the following manner: a preset time sliding window is used to slide along the time axis in the training set, sliding one time point each time until all time points in the training set are traversed, and a training instance corresponding to each time point is obtained, wherein each time the historical time series data in the training set covered by the preset time sliding window is determined as the training instance of the corresponding time point.
[0012] According to another aspect of an embodiment of the present application, a device for determining traffic alarm information is also provided, including: a detection module for detecting multi-dimensional traffic data corresponding to a containerized management platform, wherein the multi-dimensional traffic data includes network traffic data and performance indicator data of a cluster managed by the containerized management platform; a prediction module for using a prediction model to predict multi-dimensional traffic data for a future time period, and obtain a predicted traffic data set corresponding to the multi-dimensional traffic data, wherein the predicted traffic data set includes a predicted value of multi-dimensional traffic data for each predicted time point in the future time period; a filtering module for using the first verification layer in a two-layer feedback mechanism to filter the predicted traffic data set to obtain a sub-predicted traffic data set; a determination module for using the second verification layer in the two-layer feedback mechanism to determine abnormal traffic data from the sub-predicted traffic data set, and determine the alarm information corresponding to the abnormal traffic data.
[0013] According to another aspect of an embodiment of the present application, a non-volatile storage medium is provided, in which a program is stored. When the program is running, the device where the non-volatile storage medium is located is controlled to execute the above method for determining traffic alarm information.
[0014] According to another aspect of an embodiment of the present application, an electronic device is further provided, including: a memory and a processor, the processor being configured to run a program stored in the memory, wherein the above method for determining traffic alarm information is executed when the program is running.
[0015] According to another aspect of an embodiment of the present application, a computer program product is further provided, including computer instructions, which implement the above method for determining traffic alarm information when the computer instructions are executed by a processor.
[0016] In an embodiment of the present application, multi-dimensional traffic data corresponding to a containerized management platform is detected, wherein the multi-dimensional traffic data includes network traffic data and performance indicator data of a cluster managed by the containerized management platform; a prediction model is used to predict the multi-dimensional traffic data in a future time period to obtain a predicted traffic dataset corresponding to the multi-dimensional traffic data, wherein the predicted traffic dataset includes a predicted value of the multi-dimensional traffic data at each predicted time point in the future time period; the predicted traffic dataset is filtered using a first verification layer in a two-layer feedback mechanism to obtain a sub-predicted traffic dataset; the second verification layer in the two-layer feedback mechanism is used to determine abnormal traffic data from the sub-predicted traffic dataset and determine alarm information corresponding to the abnormal traffic data. The multi-dimensional traffic data for the future time period is predicted using a prediction model to obtain a predicted traffic dataset corresponding to the multi-dimensional traffic data, thereby improving the accuracy of the prediction. The two-layer feedback mechanism is used to filter the predicted traffic dataset to determine the abnormal traffic data, thereby achieving the purpose of accurate alarming, thereby solving the technical problem that traffic prediction and alarming for the containerized management platform rely solely on real-time monitoring and threshold alarms, which triggers alarms only after a problem occurs and cannot filter alarms, resulting in delayed traffic prediction and alarming timeliness and low accuracy. BRIEF DESCRIPTION OF THE DRAWINGS
[0017] 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:
[0018] Figure 1 This is a hardware structure block diagram of a computer terminal for implementing a method for determining flow alarm information provided in an embodiment of the present application;
[0019] Figure 2 This is a flow chart of a method for determining traffic alarm information provided in an embodiment of the present application;
[0020] Figure 3 This is a diagram of the architecture of the first traffic alarm information system provided according to an embodiment of the present application;
[0021] Figure 4 This is a diagram of the architecture of the second traffic alarm information system provided in an embodiment of the present application;
[0022] Figure 5 This is an architecture diagram of a third traffic alarm information system provided according to an embodiment of the present application;
[0023] Figure 6 It is a structural diagram of a device for determining flow alarm information provided according to an embodiment of the present application. DETAILED DESCRIPTION
[0024] In order to enable those skilled in the art to better understand the present invention, the following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments in the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts should fall within the scope of protection of this application.
[0025] The information collected in the embodiments of the present application is information and data authorized by the user or fully authorized by all parties, and the collection, storage, use, processing, transmission, provision, disclosure and application of the relevant data comply with the relevant laws, regulations and standards of the relevant regions, take necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation entrances for users to choose to authorize or reject the automated decision results; if the user chooses to reject, the expert decision-making process will be entered.
[0026] It should also be noted that the models or software tools mentioned in the embodiments of this application are all open source or unrestricted models or tools, and other models or software tools can also be used as substitutes during the application process.
[0027] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequential order. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in a sequence other than those illustrated or described herein. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device comprising a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.
[0028] In the related art, when monitoring the containerized environment of the containerized management platform, although real-time monitoring data can be provided, the traffic prediction and alarm solutions mostly rely on offline historical data analysis and static threshold alarm mechanisms. The operation and maintenance team periodically analyzes the traffic logs of the past few weeks or triggers alarms based on fixed thresholds, which leads to problems such as low data timeliness and inaccurate prediction results. Therefore, there is a technical problem that traffic prediction and alarms for the containerized management platform rely only on real-time monitoring and threshold alarms, and alarms are only triggered after a problem occurs and the alarms cannot be filtered, resulting in delayed traffic prediction and alarm timeliness and low accuracy. In order to solve this problem, a relevant solution is provided in the embodiments of the present application, which is described in detail below.
[0029] According to an embodiment of the present application, an embodiment of a method for determining traffic alarm information is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.
[0030] The method embodiments provided in the embodiments of the present application can be executed in a computer terminal or a similar computing device. Figure 1 The hardware structure block diagram of a computer terminal for implementing a method for determining flow alarm information is shown. Figure 1 As shown, the computer terminal 10 may include one or more (illustrated as 102a, 102b, ..., 102n in the figure) processors 102 (the processor 102 may include but is not limited to a processing device such as a microprocessor MCU or a programmable logic device FPGA), a memory 104 for storing data, and a transmission device 106 for communication functions. In addition, it may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of the BUS bus), a network interface, a power supply and / or a camera. It will be understood by those skilled in the art that Figure 1 The structure shown is only for illustration and does not limit the structure of the above electronic device. Figure 1 More or fewer components than shown, or with Figure 1 Different configurations shown.
[0031] It should be noted that the one or more processors 102 and / or other data processing circuits described above may generally be referred to herein as "data processing circuitry." The data processing circuitry may be embodied in whole or in part as software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuitry may be a single, independent processing module, or may be incorporated in whole or in part into any of the other components of the computer terminal 10. As described in the embodiments of the present application, the data processing circuitry serves as a processor control (e.g., selection of a variable resistor terminal path connected to an interface).
[0032] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the method for determining the flow alarm information in the embodiment of the present application. The processor 102 executes various functional applications and data processing by running the software programs and modules stored in the memory 104, that is, realizes the above-mentioned method for determining the flow alarm information. The memory 104 may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include a memory remotely located relative to the processor 102, and these remote memories may be connected to the computer terminal 10 via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.
[0033] The transmission device 106 is configured to receive or transmit data via a network. A specific example of the aforementioned network may include a wireless network provided by the communications provider of the computer terminal 10. In one embodiment, the transmission device 106 includes a network interface controller (NIC), which can be connected to other network devices via a base station to enable communication with the Internet. In another embodiment, the transmission device 106 may be a radio frequency (RF) module, which is configured to communicate with the Internet wirelessly.
[0034] The display may be, for example, a touch screen liquid crystal display (LCD) that enables a user to interact with a user interface of the computer terminal 10 .
[0035] In the above-mentioned operating environment, an embodiment of the present application provides an embodiment of a method for determining traffic alarm information. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although the logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.
[0036] like Figure 2 FIG. 1 is a flow chart of a method for determining traffic alarm information according to an embodiment of the present application, including:
[0037] Step S202: Detect multi-dimensional traffic data corresponding to the containerized management platform.
[0038] In the technical solution provided in step S202, the multi-dimensional traffic data includes network traffic data and performance indicator data of the cluster managed by the containerized management platform.
[0039] As some optional embodiments of the present application, a containerized monitoring tool detects multi-dimensional traffic data corresponding to a containerized management platform (for example, Kubernetes, abbreviated as k8s, is an open source platform for automating the deployment, expansion and management of containerized applications). The containerized monitoring tool is, for example, Prometheus (Prometheus is an open source system monitoring and alerting tool suite, which is mainly used to collect, store, query and visualize indicator data from various data sources. It plays a core role in modern cloud-native environments and can effectively monitor and manage containerized management platforms for automating the deployment, expansion and management of containerized applications). The multi-dimensional traffic data specifically includes network traffic data and performance indicator data of a cluster (for example, a Kubernetes cluster) managed by the containerized management platform. The network traffic data and performance indicator data of a cluster managed by the containerized management platform specifically include the network traffic data and performance indicator data of the cluster and the network traffic data and performance indicator data of the components, containers and hosts in the cluster. Network traffic data is used to indicate data transmission between the cluster as a whole and its components (such as components, containers, and hosts), including but not limited to inbound traffic (referring to the amount of network data entering the cluster and its components), outbound traffic (referring to the amount of network data leaving the cluster and its components, which can be used to monitor data output rate and overall network bandwidth usage), packet transmission rate, number of connections (the number of active connections between services within and outside the cluster, which can reflect the frequency of interaction between services and resource pressure), etc. Performance indicator data reflects the resource utilization and operational efficiency of the cluster as a whole and its components, containers, and hosts, and provides resource usage and health status data. Performance indicator data includes but is not limited to CPU usage, memory usage, disk usage, number of container restarts, etc.
[0040] Step S204: Use the prediction model to predict the multi-dimensional traffic data for the future time period to obtain a predicted traffic data set corresponding to the multi-dimensional traffic data.
[0041] In the technical solution provided in step S204, the predicted traffic data set includes multi-dimensional traffic data prediction values at each predicted time point in the future time period.
[0042] Before using a prediction model to predict multi-dimensional traffic data for future time periods, the data format of the multi-dimensional traffic data needs to be converted into a time series data format supported by the prediction model. For example, the conversion can be performed in the following ways: First, the collected multi-dimensional traffic data is preprocessed, including data cleaning, removal of outliers, missing value filling, etc. This step ensures the quality of the data and avoids the impact of noise and missing values on the prediction model. Next, feature engineering is performed to extract features from the preprocessed multi-dimensional traffic data that are meaningful for prediction (such as timestamp, resource type, network direction (inbound or outbound), traffic size, CPU usage, memory usage, etc.), and organize these features into feature vector form. Feature engineering is a key process for converting multi-dimensional traffic data into a format that can be recognized by the prediction model. After feature engineering, perform time series normalization on feature vectors: This involves converting the timestamps of all feature vectors to a unified format and determining the data frequency of the multi-dimensional traffic data (e.g., every 5 seconds, 30 seconds, or 1 minute). This helps ensure data continuity and synchronization. Time series normalization provides temporal standardization for the features generated by feature engineering, ensuring that the data can be correctly indexed and parsed during prediction model training and forecasting. After time series normalization, the multi-dimensional traffic data is converted to a time series format supported by the prediction model and stored in a time series database in chronological order. The aforementioned prediction model is capable of efficiently processing massive amounts of time series data and is suitable for monitoring data prediction and alerting for container clusters such as Kubernetes in cloud computing environments. For example, the Lag-Llama model (a deep learning model used to process time series prediction tasks) requires converting the multi-dimensional traffic data into a dataset in a time series format compatible with GluonTS (an open-source Python library specifically for time series prediction that provides a set of standardized data formats and interfaces). The converted multi-dimensional traffic data is represented as a list of dictionaries, each representing a time series instance and containing a start date (the start time of the time series, such as the current time or the time point when the most recent preset time sliding window was reset), target data (a list of target values for the time series, representing the values observed at different time points, used to construct model input and make future predictions), and data frequency (the time interval between two adjacent data points, or the basic time unit for the movement of the preset time sliding window).
[0043] Before using the prediction model to predict multi-dimensional traffic data for a future time period, the initial prediction model is trained in the following manner to obtain the prediction model: obtaining a historical dataset from the containerized management platform, where the historical dataset includes historical multi-dimensional traffic data from the containerized management platform within a preset historical time period; dividing the historical dataset into a training set, a test set, and a validation set; and training the initial prediction model based on the training set, the test set, and the validation set to obtain the prediction model. Before training the initial prediction model based on the training set, the test set, and the validation set, the data in the training set, the test set, and the validation set must be converted to a format that is compatible with the initial prediction model. That is, during the training of the initial prediction model based on the training set, the test set, and the validation set, the historical time series data in the training set, the test set, and the validation set must be in a format that is compatible with the initial prediction model. The data conversion method for the training set, the test set, and the validation set is the same as the method for converting the multi-dimensional traffic data to a time series format compatible with the prediction model.
[0044] The training set includes multiple training instances, and the multiple training instances are determined in the following manner: a preset time sliding window is used to slide along the time axis in the training set, sliding one time point each time until all time points in the training set are traversed, and a training instance corresponding to each time point is obtained, wherein each time the historical time series data in the training set covered by the preset time sliding window is determined as the training instance of the corresponding time point.
[0045] As some embodiments of the present application, the model parameters of the initial prediction model are first initialized. For example, the preset time sliding window includes the context length (as the size of the input window, it refers to the time span of the historical data contained in the input of the initial prediction model. For example, the context length is set to 3 times the prediction length, that is, if the prediction length is 1440 time points (the next 2 hours, one prediction point every 5 seconds), the context length is 4320 time points) and the prediction length (as the size of the output window, it refers to the time span of the future data to be predicted by the output of the initial prediction model. For example, the prediction length is set to 2 hours, that is, 1440 time points, one prediction every 5 seconds), the number of layers of the initial prediction model and the input feature dimension of each layer (for example, the input feature dimension is 32), the number of attention heads in the attention mechanism of the initial prediction model (for example, 16), the initial learning rate, the number of training rounds (for example, 100 rounds), the batch sample size (for example, 648), and the number of gradient accumulation steps (for example, 2 steps), etc. A Bayesian optimization-based learning rate scheduler is also configured to automatically adjust the learning rate (i.e., the initial learning rate) based on the second-order derivative of the validation set loss (the loss function calculated on the validation set). This scheduler maintains an accuracy of ±0.0001, accelerating convergence by 25%. This ensures that dynamic learning rate adjustments are both precise and responsive to performance changes on the validation set. To avoid overfitting, an early stopping strategy is implemented (with a patience value of 10, meaning the number of consecutive rounds in which model performance has not improved): By monitoring performance on the validation set, training stops if the initial prediction model fails to improve the validation loss over 10 consecutive rounds of training, saving computing resources and preventing overtraining.
[0046] In terms of data engine drive, the processing layer has built a dual-engine drive mechanism: when using a prediction model to predict multi-dimensional traffic data for future time periods, the Streaming Data Simulator class (a key component designed specifically for real-time data processing, especially suitable for time series prediction tasks) implements real-time data flow simulation through a sliding window algorithm (involving a fixed-length preset time sliding window flowing along the time series data. As new data points flow in, the oldest data points in the window are removed and new data points are added, thereby maintaining the window size unchanged while updating the data content). It adopts a dynamic buffer update strategy (the buffer size can be dynamically adjusted based on the actual multi-dimensional traffic data of the input data) to support the dynamic adjustment of the input window of the preset time sliding window with new data. Through the continuously updated preset time sliding window, the prediction model can continuously receive the latest multi-dimensional traffic data, ensuring the timeliness of the prediction results. Whenever multi-dimensional traffic data corresponding to the containerized management platform is detected, it is immediately matched to the corresponding preset time sliding window, and the predicted traffic dataset corresponding to the multi-dimensional traffic data of the preset time sliding window is obtained. Each data sample in the training set (a time series sample, i.e., the historical time series data in the training set) is split into multiple training instances using the InstanceSplitter module (a tool specifically used to split instances in a dataset). A preset time sliding window is then slid along the time axis in the training set, sliding one time point at a time (a time point is the basic time unit of time series data, defining the sampling frequency of the data. In a time series (time axis), each time point corresponds to a timestamp of the acquired data) until all time points in the training set are traversed, obtaining a training instance corresponding to each time point. During each slide, the historical time series data in the training set covered by the preset time sliding window is determined as the training instance for the corresponding time point. Each training instance includes an input-output pair, where the input of the input-output pair is the historical time series data covered by the context length in the corresponding preset time sliding window, and the output is the historical time series data covered by the prediction length in the corresponding preset time sliding window. The input of the input-output pair serves as the input of the initial prediction model training process, and the output of the input-output pair serves as the output of the initial prediction model training process. By using the above steps to generate more training instances from a limited training set, the data augmentation efficiency is increased by 3.2 times, and the generalization ability of the prediction model is improved by 21%.
[0047] The initial prediction model is trained based on the training set, test set, and validation set. When the prediction model is obtained, the training set is used to train the initial prediction model. In each round of training, the initial prediction model will traverse all training instances on the training set. After a round of training, the initial prediction model uses the validation set to evaluate its performance and generalization ability. This step is mainly used to adjust the model's hyperparameters and trigger the early stopping mechanism. Once the performance of the initial prediction model (such as the value of the loss function) does not improve in several consecutive rounds (for example, 10), early stopping is triggered and training is stopped to avoid overfitting. The learning rate scheduler dynamically adjusts the learning rate based on the loss of the validation set, allowing the model to converge to the optimal solution faster. After the initial prediction model training is completed, the test set is used to verify the final generalization ability of the initial prediction model. After obtaining the prediction model, the prediction model is used to predict the multi-dimensional traffic data of the future time period to obtain the predicted traffic data set corresponding to the multi-dimensional traffic data, that is, the prediction model is used to predict the multi-dimensional traffic to obtain the multi-dimensional traffic data prediction value at each predicted time point (every 5 seconds in the next 2 hours as a predicted time point) in the future time period (for example, the next 2 hours). The method in this application automatically detects the multi-dimensional traffic data at every preset time (for example, every 5 seconds), and matches the corresponding preset time sliding window, and uses the prediction model to predict the predicted traffic data set corresponding to the multi-dimensional traffic data of the future time period, that is, every preset time, the prediction model will automatically predict the predicted traffic data set corresponding to the multi-dimensional traffic data of the time period, to achieve high-frequency, low-latency online prediction, and ensure that the prediction results keep up with the latest trends.
[0048] Step S206: Filter the predicted traffic data set using the first verification layer in the double-layer feedback mechanism to obtain a sub-predicted traffic data set.
[0049] In the technical solution provided in step S206, the first verification layer in the double-layer feedback mechanism is used to filter the predicted traffic data set, and there are multiple ways to implement the sub-predicted traffic data set, for example: obtaining the actual traffic data corresponding to each multi-dimensional traffic data prediction value in the predicted traffic data set; determining the first error value corresponding to each multi-dimensional traffic data prediction value based on at least the multi-dimensional traffic data prediction value and the actual traffic data corresponding to each multi-dimensional traffic data prediction value; combining the multi-dimensional traffic data prediction values in the predicted traffic data set whose first error value is greater than the first threshold into a sub-predicted traffic data set according to the arrangement order of the multi-dimensional traffic data prediction values in the predicted traffic data set.
[0050] Step S208: The second verification layer in the double-layer feedback mechanism is used to determine abnormal traffic data from the sub-predicted traffic data set, and to determine alarm information corresponding to the abnormal traffic data.
[0051] In the technical solution provided in step S208, there are many ways to implement the use of the second verification layer in the double-layer feedback mechanism to determine abnormal traffic data from the sub-prediction traffic data set, for example: determining the second error value between each multi-dimensional traffic data prediction value in the sub-prediction traffic data set and the corresponding actual traffic data through a prediction model, and forming an error sequence of each second error value according to the arrangement order of the multi-dimensional traffic data prediction value in the sub-prediction traffic data set; smoothing the error sequence to obtain a smoothed error sequence; for the smoothed error sequence, when the average value of multiple second error values in a preset continuous window is greater than a second threshold, determining multiple multi-dimensional traffic data prediction values corresponding to the multiple second error values in the preset continuous window as abnormal traffic data, wherein the second threshold is less than the first threshold, and the preset continuous window is used to indicate a sub-error sequence of a preset length in the smoothed error sequence.
[0052] The two-layer feedback mechanism includes a first verification layer and a second verification layer. In the first verification layer, the goal is to filter out multi-dimensional traffic data prediction values that may have anomalies from the predicted traffic data set, providing a basis for the subsequent second-layer in-depth analysis and anomaly confirmation. The following are the specific implementation steps: The first-layer verification calculates the real-time error (i.e., the first error value mentioned above) through the relative error formula, filters out obviously normal data, and obtains the corresponding real traffic data (i.e., the traffic data actually detected when the predicted time point corresponding to the multi-dimensional traffic data prediction value arrives) for each multi-dimensional traffic data prediction value in the predicted traffic data set. The relative error formula is determined by the multi-dimensional traffic data prediction value, the real traffic data corresponding to each multi-dimensional traffic data prediction value, and a preset coefficient (a preset constant used to avoid division by zero). For example, the first error value corresponding to each multi-dimensional traffic data prediction value is equal to the quotient of (the absolute value of the difference between the multi-dimensional traffic data prediction value and the real traffic data) and (the sum of the real traffic data and the preset coefficient). After obtaining the first error value corresponding to each multidimensional traffic data prediction value in the predicted traffic data set, the first error value corresponding to each multidimensional traffic data prediction value is compared with a first threshold (for example, 0.1), and all multidimensional predicted traffic data prediction values whose first error values exceed the first threshold are retained and combined into a new data set, namely, a sub-predicted traffic data set, according to their original order in the predicted traffic data set.
[0053] The second verification layer is designed to deeply analyze and confirm which multi-dimensional predicted traffic data prediction values are indeed abnormal from the preliminarily screened sub-prediction traffic data sets, and generate corresponding alarm information. The second verification layer determines the local average error (i.e., the above-mentioned second error value) between each multi-dimensional traffic data prediction value in the sub-prediction traffic data set and the corresponding actual traffic data through the prediction model, and arranges all calculated second error values in chronological order to form an error sequence. The error sequence is smoothed by sliding average or other smoothing techniques (such as exponential moving average) to obtain a smoothed error sequence to eliminate the influence of short-term fluctuations or abnormal points. For a smoothed error sequence, if the average of multiple second error values within a preset continuous window (e.g., three consecutive windows, each window representing a fixed sliding interval, and the preset continuous window being used to slide through the smoothed error sequence, with each sliding window consisting of three windows) is greater than a second threshold (where the second threshold is less than the first threshold), the multiple multi-dimensional traffic data prediction values corresponding to the multiple second error values within the preset continuous window are determined to be abnormal traffic data. That is, once the average error within a preset continuous window exceeds the second threshold, all predicted traffic data within that set of preset continuous windows are marked as abnormal. The preset continuous window is used to indicate a sub-error sequence of a preset length within the smoothed error sequence, e.g., a sub-error sequence of three consecutive windows within the smoothed error sequence. The alarm information contains specific details of the abnormal traffic data, such as timestamp, container ID, and degree of abnormality, to facilitate subsequent troubleshooting and response. The alarm information corresponding to the abnormal traffic data is determined and pushed, and the multi-dimensional traffic data, the corresponding predicted traffic data set, the alarm information, and a visualization are simultaneously displayed.
[0054] In order to ensure the accuracy of the prediction model, the prediction model is continuously updated in the following manner: the abnormal traffic data and the second error value corresponding to the abnormal traffic data are determined as historical feedback data, and after the historical feedback data is converted into the format of time series data (for example, the data is converted into a structured format containing a timestamp, a target value (abnormal traffic data), and an error value (second error value)), it is stored in a database (for example, a time series database); every preset time period (for example, one month), the historical feedback data in the database and the historical multi-dimensional traffic data of the preset time period in the containerized management platform are obtained; the historical feedback data and the historical multi-dimensional traffic data of the preset time period are determined as an incremental training set; the prediction model is retrained based on the incremental training set to obtain an updated prediction model. When retraining the prediction model based on the incremental training set, a dynamic learning rate strategy (i.e., the above-mentioned learning rate scheduler based on Bayesian optimization) is used to adjust the learning rate according to the performance of the prediction model on the validation set to ensure that the prediction model can quickly learn new knowledge in incremental training without being overly constrained by old data. During training, configuring the gradient accumulation strategy (for example, setting the number of gradient accumulation steps) to simulate a larger batch size helps stabilize gradient updates during prediction model training and prevents training instability caused by small batches of data. Based on the constructed incremental training set, after configuring the dynamic learning rate and number of gradient accumulation steps, a specified number of model retraining rounds are performed. In each training round, the prediction model adjusts its parameters based on the incremental training set to optimize its ability to predict abnormal traffic data. After training, the updated prediction model parameters are applied to the prediction model in real time to improve its prediction accuracy, resulting in an updated prediction model.
[0055] The following is an example of a business system anomaly: During holidays, when the traffic of the business system on the cloud surges, customer perception will drop significantly. Since the cloud business adopts containerized deployment, the fault location chain is extended, and the operation and maintenance personnel need to check layer by layer from the host, cluster to the container, which takes a significant amount of time. In this scenario, the monitoring tool triggers a large number of related alarms when the traffic surges, such as node CPU saturation, service delay surge, etc., forming an alarm storm, making it difficult for operation and maintenance personnel to quickly locate the root cause, and the fault handling time is extended, further affecting the customer experience. In the above scenario, the method in this application targets the core pain points of traffic management in containerized environments. By real-time detection of multi-dimensional traffic data, it can accurately capture the traffic fluctuation patterns in complex scenarios such as business peaks and service call chain anomalies. Based on the joint analysis of historical and multi-dimensional traffic data, the prediction model can dynamically adapt to business change trends and predict multi-dimensional traffic data for future time periods. For example, it predicts container resource requirements 2 hours in advance to provide a scientific basis for automatic scaling. At the same time, a two-layer feedback mechanism for predicted traffic data sets is introduced to significantly reduce the false alarm rate and avoid resource shocks caused by invalid alarms. Predictive resource scheduling can reduce cloud resource waste by 20%-30%, directly reducing enterprise O&M costs. In terms of business O&M, automated closed-loop management frees O&M teams from repetitive monitoring tasks, allowing them to focus on high-value decision-making and reducing manpower input by over 50%. In terms of customer perception, the alarm information push mechanism can proactively identify faults, reducing user churn and brand reputation damage caused by service interruptions by approximately 40%. This enables closed-loop management from prediction to decision-making, effectively improving cluster resource utilization and proactive fault prevention capabilities, and providing highly reliable intelligent O&M support for cloud-native systems.
[0056] Figure 3This is the architecture diagram of the first traffic alarm information system provided according to the embodiment of the present application. Taking the Prometheus server as an example (but not limited to this), it shows the architecture diagram of the traffic alarm information system in the related technology. From the collection of various types of information, to data storage and processing, to alarms, visual display and other links, a monitoring system is built to realize the monitoring and management of the system operation status. Prometheus server (Prometheus server): The core server of the Prometheus monitoring system is responsible for capturing data, storing it in a time series database, providing a query interface, interacting with the alarm component, providing real-time data and historical data for the early warning module, as well as query interfaces and external services. It is the hub of the entire monitoring system. The Retrieval module in the Prometheus server is used to proactively pull (crawl) monitoring metric data (i.e., the aforementioned multi-dimensional traffic data) from various data collection sources according to configured rules (such as collection interval and destination address). For example, Node Exporter hardware information refers to server hardware-level metrics (such as CPU usage and memory usage) collected when Node Exporter is deployed on server nodes in a Kubernetes cluster. Kube-state-metrics cluster status information is collected for Kubernetes clusters using Kubernetes state metrics (a monitoring data collection tool for Kubernetes cluster status), reflecting the overall health of the Kubernetes cluster. cAdvisor container information refers to container information collected by cAdvisor, which includes resource usage and performance data and network traffic data for containers in a Kubernetes cluster, including CPU usage, memory consumption, and network traffic. Apiserver and etcd component status information (i.e., APIServer (one of the core components of Kubernetes, responsible for providing the Kubernetes API interface) and distributed key-value store database (abbreviated as etcd, a key component for storing cluster configuration and status data)). Apiserver and etcd component status information is collected performance indicator data for the core Kubernetes components Apiserver and etcd.The Time Series Database (TSDB) stores captured monitoring data with timestamps. It specifically optimizes the writing and query performance of time series data, supports rapid data retrieval by time range, metric dimension, and other factors, and provides persistent storage for subsequent analysis and queries. The HTTP server provides an HTTP-based interface. This allows external queries of the monitoring data in TSDB (i.e., the multi-dimensional traffic data converted into a data format supported by the prediction model) using the Prometheus Query Language (promQL). The Prometheus Web UI (Prometheus's built-in web interface, based on PromQL, can be used for simple data queries and visualizations, including viewing trends and current values of monitoring metrics (i.e., multi-dimensional traffic data)), Grafana (a professional visualization tool that connects to Prometheus's PromQL interface to flexibly configure rich and beautiful monitoring dashboards, displaying charts and reports of various monitoring metrics (i.e., multi-dimensional traffic data), and API clients (various client programs that call the Prometheus API, used for secondary development, data integration, and other scenarios) all rely on PromQL. The AlertManager receives push alerts from the Prometheus server, performs deduplication and grouping on them, and then sends alert notifications through configured channels (such as the Short Message Service Gateway (SMS Gateway) and the Configuration Management Database (CMDB)), allowing operations and maintenance personnel to be notified of system anomalies in a timely manner. Node represents a server node. HDD (hard disk drive) / SSD (solid-state drive) is the storage device on the node. The data stored in TSDB will be persisted to these local storage media.
[0057] Figure 4 The second flow alarm information system provided by the embodiment of the present application is a schematic diagram; the system of the method in the present application is schematic diagram, as shown in the figure, showing the Figure 3The improvement of the shown architecture introduces a large prediction model (i.e., the above-mentioned prediction model). In the large prediction model (i.e., the above-mentioned prediction model), the large model obtains the multi-dimensional traffic data detected by the capture module and the historical multi-dimensional traffic data in the TSDB. By performing data segmentation and data conversion, the multi-dimensional traffic data and the historical multi-dimensional traffic data are converted into the data format required for model training and prediction. Through model training, the training of the initial prediction model is completed to obtain the prediction model. Model training also includes model updates. The prediction model is used to perform predictions to obtain a predicted traffic data set corresponding to the multi-dimensional traffic data. And through the feedback mechanism (i.e., the above-mentioned two-layer feedback mechanism), the first verification layer in the two-layer feedback mechanism is used to filter the predicted traffic data set to obtain a sub-prediction traffic data set; the second verification layer in the two-layer feedback mechanism is used to determine abnormal traffic data from the sub-prediction traffic data set and determine the alarm information corresponding to the abnormal traffic data.
[0058] Figure 5 This is a diagram of the architecture of the third traffic alarm information system provided by the embodiment of the present application. Figure 4Further refinement of the illustrated architecture shows that Metrics (the metrics collection layer, which is the metrics module) collects Node-exporter hardware information, Kube-state-metrics cluster status information, Apiserver and etcd component status information, and cAdvisor container information (i.e., real-time and historical data). The implementation data refers to the multi-dimensional traffic data corresponding to the containerized management platform detected at the latest time point, and the historical data refers to the historical data set of the containerized management platform). The Retrieval module in the Prometheus server (Prometheusserver) pulls metrics to obtain multi-dimensional traffic data according to the aggregation rules configured in the PrometheusConfiguration (Promconfig for short) (which define how Prometheus aggregates collected metrics, such as aggregating the CPU usage of multiple instances into the overall CPU usage of the cluster), and stores it in the TSDB time series database in the correct format. Prometheus monitoring hot update (Prom-reloader monitoring hot update) is used to monitor changes in Promconfig aggregation rules. When the aggregation rules are adjusted, the new rules can be dynamically loaded without restarting the Prometheus service to achieve hot updates, ensuring that the monitoring configuration can take effect in a timely manner and improving operation and maintenance efficiency. Reload is an operation triggered by Prom-reloader. When the configuration such as aggregation rules changes, the Reload action is executed to allow Prometheus to apply the new configuration to ensure that the monitoring logic is consistent with the configuration. PredictionModule (prediction module) introduces the Lag-Llama base model (Lag-Llama basic model, that is, the above-mentioned Lag–Llama model, the prediction model in this application can be the Lag–Llama model) for deep processing and prediction of data. It is the core enhancement link for realizing intelligent monitoring. Prediction Module is based on the Lag-Llama large model (that is, the Lag–Llama model, as a prediction model), and realizes container traffic trend prediction and anomaly detection through data segmentation, conversion, training and feedback mechanism. DataStriping divides the data obtained from Prometheus into real-time Set (i.e., the multi-dimensional traffic data corresponding to the above-mentioned detection and container management platform), Training Set, Validation Set, and Test Set (i.e., the above-mentioned historical data set is divided into training set, test set, and validation set).Data Conversion performs Data Cleaning and Feature Vector on the segmented data (i.e., the feature engineering mentioned above is performed to extract features that are meaningful for prediction from the pre-processed multi-dimensional traffic data, and organize these features into feature vector form). The converted multi-dimensional traffic data is converted into Start Date, Target Data, and Data Frequency in a time series format. Model Training completes the training of the initial prediction model through Model Context (model context, environmental information provided to the model, parameter settings during training, etc.) and Model Building (model construction, used to train the initial prediction model based on the training set, test set, and validation set) to obtain a prediction model. Model Prediction is used to use a prediction model to predict multi-dimensional traffic data for future time periods and obtain a predicted traffic data set corresponding to the multi-dimensional traffic data. Feedback Mechanism (the two-layer feedback mechanism mentioned above) uses the first verification layer in the two-layer feedback mechanism to filter the predicted traffic data set to obtain a sub-predicted traffic data set; the second verification layer in the two-layer feedback mechanism is used to determine abnormal traffic data from the sub-predicted traffic data set, and determine the alarm information corresponding to the abnormal traffic data. The alarm information is pushed to Alert Tools (alarm tool layer). Alert Tools is an alarm module. The Alertmanager alarm notification in Alert Tools is the core component of alarm processing. It receives alarm information and distributes it to the SMS Gateway SMS alarm platform or Cloud Eye (an alarm platform customized by the enterprise or team). Client Tools (client tool layer) is a visualization module used by users (operation and maintenance personnel, etc.) to query, visualize, and analyze monitoring data, assist in system status judgment and decision-making, and provide users with an intuitive monitoring data display and operation interface to help users intuitively analyze monitoring data. It includes the following components: CMDB, Grafana, and Prometheus Web ui.
[0059] The following is an example of the algorithm implementation for the Mode Training module: Model parameters are defined: The prediction length for the preset time window is set to 2 hours, with predictions made every 5 seconds (i.e., a total of 1440 prediction time points). The context length for the preset time window is set to 3 times the prediction length, or 4320 time points, to include more historical information for prediction. Training rounds and batch size are set: The initial prediction model will be trained for a total of 100 rounds, with each batch containing 648 data points. Gradient accumulation and early stopping: The number of gradient accumulation steps is set to 2, meaning that the model will only update its parameters after every two iterations. This ensures more stable model updates with limited computing resources. The patience value for the early stopping mechanism is set to 10, terminating training early if the performance of the initial prediction model on the validation set no longer improves, thus preventing overfitting. The historical dataset is divided into training, validation, and test sets, with 60% of the training set, 20% of the validation set, and the remainder used as the test set. This proportional distribution ensures effective model training and reliable validation. The StreamingDataSimulator class is defined to process real-time data streams. It maintains a buffer initially filled with 1000 data points. As new data (the latest detected multi-dimensional traffic data) is added, the buffer is dynamically updated to ensure real-time and fresh data. This means the prediction model continuously receives the latest multi-dimensional traffic data, ensuring the timeliness of prediction results. Upon detecting multi-dimensional traffic data corresponding to the containerized management platform, it is immediately matched to the corresponding preset time sliding window and a predicted traffic dataset corresponding to the multi-dimensional traffic data in that preset time sliding window is obtained. The following is an example implementation algorithm for the Feedback Mechanism (the two-layer feedback mechanism described above): When the feedback mechanism module is initialized, the first threshold, second threshold, and number of retraining rounds must be set. First, the first error between the model's predicted value and the true value is calculated. If the first error exceeds the first threshold, a secondary validation of the large model is performed to check for persistent anomalies. The secondary verification uses a sliding window mechanism, with the preset window size (i.e., the preset continuous window) set to 3. This checks whether the average error of the past three data points exceeds the second threshold. If the average error of any window exceeds this threshold, then a true anomaly is considered to exist. This is the same as the above (using the first verification layer in the two-layer feedback mechanism to filter the predicted traffic data set to obtain a sub-predicted traffic data set, and using the second verification layer in the two-layer feedback mechanism to determine abnormal traffic data from the sub-predicted traffic data set). Once an anomaly is confirmed, the system will generate an alarm message including the current time, monitoring indicators (such as network throughput), the latest actual and predicted values, the maximum error, the set threshold, and data window information.This information is formatted and printed. In practice, this step triggers an alert notification, such as an email, text message, or notification via an alert tool. The training data loader retrains the model after detecting an anomaly (i.e., obtaining historical feedback data from the database and historical multi-dimensional traffic data for a preset time period from the containerized management platform; determining the historical feedback data and historical multi-dimensional traffic data for the preset time period as an incremental training set; and retraining the prediction model based on the incremental training set to obtain an updated prediction model).
[0060] The embodiment of the present application also provides a structural diagram of a device for determining flow alarm information, such as Figure 6 Shown, including:
[0061] A detection module 602 is configured to detect multi-dimensional traffic data corresponding to the containerized management platform, wherein the multi-dimensional traffic data includes network traffic data and performance indicator data of the cluster managed by the containerized management platform;
[0062] The prediction module 604 is configured to use the prediction model to predict the multi-dimensional traffic data in the future time period, and obtain a predicted traffic data set corresponding to the multi-dimensional traffic data, wherein the predicted traffic data set includes the predicted value of the multi-dimensional traffic data at each predicted time point in the future time period;
[0063] A filtering module 606 is configured to filter the predicted traffic data set using the first verification layer in the two-layer feedback mechanism to obtain a sub-predicted traffic data set;
[0064] The determination module 608 is configured to determine abnormal traffic data from the sub-predicted traffic data set using the second verification layer in the dual-layer feedback mechanism, and determine alarm information corresponding to the abnormal traffic data.
[0065] It should be noted that Figure 6 The flow alarm information determination device shown is used to perform Figure 2 The method for determining the traffic alarm information shown is as follows: Figure 2 The relevant explanations in the method for determining the flow alarm information in also apply to the device for determining the flow alarm information, and will not be repeated here.
[0066] It should be noted that the various modules in the above-mentioned traffic alarm information determination device can be a program module (for example, a set of program instructions that implement a certain specific function) or a hardware module. For the latter, it can be expressed in the following form, but is not limited to this: the expression form of each of the above-mentioned modules is a processor, or the functions of each of the above-mentioned modules are implemented by a processor.
[0067] An embodiment of the present application also provides a non-volatile storage medium, which includes a stored program, wherein when the program is running, the device where the non-volatile storage medium is located is controlled to execute the method for determining traffic alarm information of any one of the above embodiments.
[0068] An embodiment of the present application further provides an electronic device, which includes a processor, and the processor is used to run a program, wherein the method for determining traffic alarm information of any one of the above embodiments is executed when the program is running.
[0069] According to another aspect of the embodiments of the present application, a computer program product is further provided, including a computer program, which, when executed by a processor, implements the method for determining traffic alarm information of any one of the above embodiments.
[0070] In the above embodiments of the present application, the description of each embodiment has its own focus. For parts that are not described in detail in a certain embodiment, please refer to the relevant description of other embodiments.
[0071] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. Among them, the device embodiments described above are only exemplary. For example, the division of the units can be a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of units or modules, which can be electrical or other forms.
[0072] The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple units. Some or all of the units may be selected according to actual needs to achieve the purpose of the present embodiment.
[0073] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.
[0074] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application is essentially or the part that contributes to the relevant technology or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions for enabling a computer device (which can be a personal computer, a server or a network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk or an optical disk.
[0075] The above is only a preferred embodiment of the present application. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present application. These improvements and modifications should also be regarded as the scope of protection of the present application.
Claims
1. A method for determining traffic alarm information, characterized in that: include: Detecting multi-dimensional traffic data corresponding to the containerized management platform, wherein the multi-dimensional traffic data includes network traffic data and performance indicator data of the cluster managed by the containerized management platform; Using a prediction model to predict multi-dimensional traffic data in a future time period, obtaining a predicted traffic data set corresponding to the multi-dimensional traffic data, wherein the predicted traffic data set includes a predicted value of the multi-dimensional traffic data at each predicted time point in the future time period; The predicted traffic data set is filtered using the first verification layer in the double-layer feedback mechanism to obtain a sub-predicted traffic data set; The second verification layer in the double-layer feedback mechanism is used to determine abnormal traffic data from the sub-predicted traffic data set, and to determine alarm information corresponding to the abnormal traffic data.
2. The method according to claim 1, characterized in that The first verification layer in the two-layer feedback mechanism is used to filter the predicted traffic data set to obtain a sub-predicted traffic data set, including: Obtaining actual traffic data corresponding to each of the multi-dimensional traffic data prediction values in the predicted traffic data set; Determining a first error value corresponding to each multi-dimensional traffic data prediction value at least based on the multi-dimensional traffic data prediction value and the actual traffic data corresponding to each multi-dimensional traffic data prediction value; The multi-dimensional traffic data prediction values whose first error value is greater than the first threshold in the predicted traffic data set are combined into the sub-predicted traffic data set according to the arrangement order of the multi-dimensional traffic data prediction values in the predicted traffic data set.
3. The method according to claim 2, characterized in that Determining abnormal traffic data from the sub-predicted traffic data set using the second verification layer in the dual-layer feedback mechanism includes: Determine, by using the prediction model, a second error value between each multi-dimensional traffic data prediction value in the sub-prediction traffic data set and the corresponding actual traffic data, and form an error sequence by arranging the respective second error values in the order of the multi-dimensional traffic data prediction values in the sub-prediction traffic data set; performing smoothing on the error sequence to obtain a smoothed error sequence; For the error sequence after smoothing, when the average value of multiple second error values of a preset continuous window is greater than a second threshold, multiple multi-dimensional traffic data prediction values corresponding to the multiple second error values of the preset continuous window are determined as the abnormal traffic data, wherein the second threshold is less than the first threshold, and the preset continuous window is used to indicate a sub-error sequence of a preset length in the error sequence after smoothing.
4. The method according to claim 3, characterized in that The method further comprises: Determining the abnormal flow data and the second error value corresponding to the abnormal flow data as historical feedback data, and storing the historical feedback data in a database; Every preset time period, obtaining historical feedback data from the database and historical multi-dimensional traffic data of the preset time period in the containerized management platform; Determining the historical feedback data and the historical multi-dimensional traffic data of the preset time period as an incremental training set; The prediction model is retrained based on the incremental training set to obtain an updated prediction model.
5. The method according to claim 1, characterized in that Before using the prediction model to predict the multi-dimensional traffic data in the future time period, the method further includes: converting the data format of the multi-dimensional traffic data into a time series data format supported by the prediction model.
6. The method according to claim 1, characterized in that Before using the prediction model to predict multi-dimensional traffic data for a future time period, the initial prediction model is trained in the following manner to obtain the prediction model: Obtain a historical data set of the containerized management platform, wherein the historical data set includes historical multi-dimensional traffic data corresponding to the containerized management platform within a historical preset time period; Dividing the historical data set into a training set, a test set, and a validation set; The initial prediction model is trained based on the training set, the test set and the validation set to obtain the prediction model.
7. The method according to claim 6, characterized in that The training set includes multiple training instances, and the multiple training instances are determined in the following manner: a preset time sliding window is used to slide along the time axis in the training set, sliding one time point each time until all time points in the training set are traversed, and a training instance corresponding to each time point is obtained, wherein each time the historical time series data in the training set covered by the preset time sliding window is determined as the training instance of the corresponding time point.
8. A device for determining flow alarm information, characterized in that: include: A detection module, configured to detect multi-dimensional traffic data corresponding to the containerized management platform, wherein the multi-dimensional traffic data includes network traffic data and performance indicator data of the cluster managed by the containerized management platform; A prediction module, configured to use a prediction model to predict multi-dimensional traffic data for a future time period, and obtain a predicted traffic data set corresponding to the multi-dimensional traffic data, wherein the predicted traffic data set includes a predicted value of the multi-dimensional traffic data at each predicted time point in the future time period; A filtering module, configured to filter the predicted traffic data set using the first verification layer in the double-layer feedback mechanism to obtain a sub-predicted traffic data set; A determination module is used to determine abnormal traffic data from the sub-prediction traffic data set using the second verification layer in the double-layer feedback mechanism, and to determine alarm information corresponding to the abnormal traffic data.
9. A non-volatile storage medium, characterized in that: The non-volatile storage medium stores a program, wherein when the program is running, the device where the non-volatile storage medium is located is controlled to execute the method for determining traffic alarm information according to any one of claims 1 to 7.
10. An electronic device, characterized in that: include: A memory and a processor, wherein the processor is used to run a program stored in the memory, wherein the method for determining traffic alarm information according to any one of claims 1 to 7 is executed when the program is run.
11. A computer program product comprising computer instructions, characterized in that When the computer instructions are executed by a processor, the method for determining traffic alarm information according to any one of claims 1 to 7 is implemented.