Index anomaly detection method, system and equipment based on multiple models and storage medium

Abstract

The embodiment of the invention discloses an index anomaly detection method, system and device based on multiple models and a storage medium. According to the technical scheme provided by the embodiment of the invention, various types of target index data corresponding to the to-be-detected index are acquired; a pre-constructed arrangement model is determined according to the to-be-detected index, the arrangement model carries out model arrangement and combination in advance based on detection models corresponding to the target index data of all types, and the arrangement model comprises a combination script of calculation results of all the detection models; inputting each type of target index data into an arrangement model, calculating a multi-model calculation result of each type of target index data based on a combination script of the arrangement model, comparing the multi-model calculation result based on pre-configured index judgment information, and performing index anomaly judgment on the to-be-detected index according to the comparison result. And outputting a corresponding judgment result. By adopting the technical means, the efficient detection of the index anomaly can be realized, and the index anomaly detection cost and time consumption are reduced.

Description

Technical Field

[0001] The embodiments of the present application relate to the field of computer technologies, and in particular, to a multi-model-based metric anomaly detection method, system, device, and storage medium. Background Art

[0002] Currently, in the operation and maintenance scenarios of various types of application systems, AIOps (Artificial Intelligence for IT Operations) technology is often used to optimize and automate IT operation and maintenance management. AIOps collects and analyzes a large amount of operation and maintenance data, identifies anomalies and potential problems in the system, and provides intelligent operation and maintenance decisions. In the application scenarios of AIOps, multiple different machine learning or algorithm models are used for anomaly detection, classification, or analysis. Each model is based on different algorithms, data sets, or parameter settings and is suitable for processing specific metrics or scenarios. By using multiple models to detect different types of anomalies, the comprehensive effect of system anomaly detection is improved.

[0003] However, due to the diversity of metrics, different metrics often require different combinations of detection models for anomaly analysis and processing. With the expansion of business and the continuous refinement of detection requirements, the number of combinations of different metrics and different models is increasing continuously. When performing anomaly detection by integrating multiple models, it is necessary to manually combine the detection results of different models to comprehensively judge the anomaly detection results. The whole process is cumbersome and time-consuming, and the anomaly detection efficiency is relatively low. Summary of the Invention

[0004] The embodiments of the present application provide a multi-model-based metric anomaly detection method, system, device, and storage medium, which can adapt to the combination of different metrics and multiple models for efficient metric anomaly detection, improve the metric anomaly detection efficiency, and solve the technical problem that the process of comprehensively judging the anomaly detection results by multiple models is cumbersome and time-consuming.

[0005] In a first aspect, the embodiments of the present application provide a multi-model-based metric anomaly detection method, including:

[0006] Obtain target metric data of each type corresponding to the metric to be detected;

[0007] Determine a pre-constructed orchestration model according to the metric to be detected. The orchestration model is pre-orchestrated and combined based on the detection models corresponding to the target metric data of each type, and the orchestration model includes a combination script of the calculation results of each detection model;

[0008] Input the target index data of each type into the orchestration model, and calculate the multi-model calculation results of the target index data of each type based on the combination script of the orchestration model. The multi-model calculation results are a combination of different calculation results of the target index data of each type;

[0009] Compare the multi-model calculation results based on the pre-configured index determination information, and perform index anomaly determination on the index to be detected according to the comparison result, and output the corresponding determination result.

[0010] In a second aspect, an embodiment of the present application provides a multi-model-based index anomaly detection system, including:

[0011] An acquisition module configured to acquire the target index data of each type corresponding to the index to be detected;

[0012] A model determination module configured to determine a pre-constructed orchestration model according to the index to be detected. The orchestration model is pre-based on the detection models corresponding to the target index data of each type for model orchestration and combination, and the orchestration model includes a combination script of the calculation results of each detection model;

[0013] A model detection module configured to input the target index data of each type into the orchestration model, and calculate the multi-model calculation results of the target index data of each type based on the combination script of the orchestration model. The multi-model calculation results are a combination of different calculation results of the target index data of each type;

[0014] A judgment module configured to compare the multi-model calculation results based on the pre-configured index determination information, and perform index anomaly determination on the index to be detected according to the comparison result, and output the corresponding determination result.

[0015] In a third aspect, an embodiment of the present application provides a multi-model-based index anomaly detection device, including:

[0016] A memory and one or more processors;

[0017] The memory is configured to store one or more programs;

[0018] When the one or more programs are executed by the one or more processors, the one or more processors implement the multi-model-based index anomaly detection method as described in the first aspect.

[0019] In a fourth aspect, an embodiment of the present application provides a non-volatile computer-readable storage medium, and the non-volatile computer-readable storage medium stores computer-executable instructions, and the computer-executable instructions are configured to execute the multi-model-based index anomaly detection method as described in the first aspect when executed by a computer processor.

[0020] In a fifth aspect, an embodiment of the present application provides a computer program product, which contains instructions that, when running on a computer or a processor, cause the computer or the processor to execute the multi-model-based metric anomaly detection method as described in the first aspect.

[0021] In the embodiment of the present application, by obtaining target metric data of various types corresponding to the metric to be detected; determining a pre-constructed orchestration model according to the metric to be detected, the orchestration model is pre-orchestrated and combined based on detection models corresponding to target metric data of various types, and the orchestration model includes a combination script of calculation results of each detection model; inputting target metric data of various types into the orchestration model, calculating a multi-model calculation result of target metric data of various types based on the combination script of the orchestration model, the multi-model calculation result is a combination of different calculation results of target metric data of various types; comparing the multi-model calculation result with pre-configured metric determination information, and determining the metric anomaly of the metric to be detected according to the comparison result, and outputting the corresponding determination result. By adopting the above technical means, an orchestration model is obtained by pre-orchestrating and combining detection models corresponding to target metric data of various types, and the calculation results of target metric data of various types of the metric to be detected are combined into a multi-model calculation result in combination with the combination script of the calculation results of the detection models, so as to determine the metric anomaly of the metric to be detected, so as to realize the efficient detection of metric anomalies, simplify the cumbersome process of manually comprehensively judging metric anomalies by combining the detection results of different models, reduce the cost and time consumption of metric anomaly detection, and improve the flexibility and scalability of metric anomaly detection. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] Figure 1 is a flowchart of a multi-model-based metric anomaly detection method provided by an embodiment of the present application;

[0023] Figure 2 is a flowchart of the construction and detection of the orchestration model in the embodiment of the present application;

[0024] Figure 3 is a schematic diagram of the simulation verification of the orchestration model in the embodiment of the present application;

[0025] Figure 4 is a flowchart of the anomaly detection of the orchestration model in the embodiment of the present application;

[0026] Figure 5 is a schematic structural diagram of a multi-model-based metric anomaly detection system provided by an embodiment of the present application;

[0027] Figure 6 is a schematic structural diagram of a multi-model-based metric anomaly detection device provided by an embodiment of the present application. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0028] To make the objectives, technical solutions, and advantages of this application clearer, the following provides a more detailed description of specific embodiments of this application with reference to the accompanying drawings. It can be understood that the specific embodiments described herein are merely for explaining this application and not for limiting it. Additionally, it should be noted that for ease of description, only parts related to this application rather than all content are shown in the drawings. Before discussing exemplary embodiments in more detail, it should be mentioned that some exemplary embodiments are described as processes or methods depicted as flowcharts. Although the flowcharts describe the operations (or steps) as sequential processes, many of the operations can be implemented in parallel, concurrently, or simultaneously. In addition, the order of the operations can be rearranged. The process can be terminated when its operations are completed, but it can also have additional steps not included in the drawings. The process can correspond to a method, function, procedure, subroutine, subprogram, etc.

[0029] The multi-model based metric anomaly detection method provided by this application aims to obtain an orchestrated model by pre-orchestrating and combining detection models based on the detection models corresponding to the target metric data of each type, and combining the calculation results of the target metric data of each type of the metric to be detected into a multi-model calculation result through a combination script of the calculation results of the detection models, so as to perform metric anomaly determination on the metric to be detected, in order to achieve efficient detection of metric anomalies and simplify the cumbersome process of manually comprehensively judging metric anomalies by combining the detection results of different models.

[0030] Among them, anomaly detection refers to identifying abnormal patterns or phenomena deviating from the normal state in data or system behavior through algorithms or models. It can be applied to various types of data, such as time series data, network traffic data, log data, etc., to discover potential problems or abnormal situations. Anomaly detection is particularly important in AIOps, which can help quickly discover performance bottlenecks, fault points, abnormal behaviors, etc. in the system, so as to perform timely processing to ensure the stability and reliability of the system.

[0031] In the multi-model anomaly detection process of an AIOps system, the metrics for which anomaly detection needs to be performed are usually diverse, and different metrics often require different combinations of detection models for analysis and processing. At the same time, even for the same model, when it faces different metrics, it is very likely that different parameter settings need to be adopted. Such a situation results in various different combinations of detection results.

[0032] With the expansion of business and the continuous refinement of detection requirements, the complex relationships of different combinations of indicators and models, as well as different parameters and different detection result combinations, are increasing in number. If we still rely on manual investigation to handle these complex combination situations, a large amount of human resources will be required. The whole process will consume a lot of time and the work efficiency will be extremely low.

[0033] Based on this, an indicator anomaly detection method based on multiple models is provided to solve the technical problem of the cumbersome and time-consuming process of comprehensively judging anomaly detection results with multiple models. It can easily arrange the combination methods of the detection results of multiple models reasonably. By arranging the models, the effectiveness of the multi-model algorithm can be quickly verified, thereby greatly improving the iteration speed of the algorithm combination, enabling the algorithm to be more efficiently applied in actual scenarios, improving the indicator anomaly detection efficiency, and ultimately achieving the purpose of improving the overall work efficiency.

[0034] Among them, orchestration refers to coordinating and managing multiple tasks, processes or components in a system so that they work according to certain rules or sequences. In AIOps, orchestration is usually used for the combination and management of multi-model results, allowing users to customize the work processes of different models, the fusion methods of output results, etc. to meet specific business requirements. Through orchestration, the collaborative work between models can be flexibly adjusted, improving the processing efficiency and flexibility of the system.

[0035] Embodiment:

[0036] Figure 1 The flowchart of an indicator anomaly detection method based on multiple models provided by the embodiment of the present application is given. The indicator anomaly detection method based on multiple models provided in this embodiment can be executed by an indicator anomaly detection device based on multiple models. The indicator anomaly detection device based on multiple models can be implemented in software and / or hardware. The indicator anomaly detection device based on multiple models can be composed of two or more physical entities, or can be composed of one physical entity. Generally speaking, the indicator anomaly detection device based on multiple models can be a processing device such as a server host for anomaly detection.

[0037] The following takes the indicator anomaly detection device based on multiple models as the main body for executing the indicator anomaly detection method based on multiple models as an example for description. Refer to Figure 1 , the indicator anomaly detection method based on multiple models specifically includes:

[0038] S110. Obtain target indicator data of each type corresponding to the indicator to be detected.

[0039] When performing anomaly detection on the metrics to be detected in this application, by obtaining various types of parameters that affect the health status of the metrics to be detected, the obtained parameters are defined as target metric data, so as to facilitate anomaly detection of various types of target metric data.

[0040] Before that, it is necessary to clarify the specific content and scope of the metrics to be detected. These metrics may include system performance parameters (such as CPU usage rate, memory occupancy rate), network traffic data, user behavior data, etc. According to different anomaly detection scenarios, the metrics to be detected and their corresponding target metric data can be configured adaptively.

[0041] By determining the specific sources of obtaining target metric data, the data sources can be different locations such as inside the application system,

[0042] external monitoring systems, databases, and log files. After determining the data sources, target metric data is obtained through data collection methods such as API interfaces, database queries, and log analysis.

[0043] Optionally, after collecting the target metric data, corresponding preprocessing work can also be performed to ensure the accuracy and availability of the data.

[0044] Taking a network latency metric as an example, the target metric data can involve multiple parameters related to network performance and user experience, such as a series of related parameters affecting network latency, such as network bandwidth, throughput, latency, jitter, packet loss rate, etc. In actual applications, multiple of the above parameters can be selected as target metric data according to the specific network environment and business requirements to perform anomaly determination of network latency.

[0045] Optionally, obtaining various types of target metric data corresponding to the metrics to be detected includes:

[0046] Obtaining various types of target metric data corresponding to the metrics to be detected from the first Kafka message queue pre-constructed for the metrics to be detected. Each type of target metric data is collected through the intelligent operation and maintenance platform corresponding to the metrics to be detected, and the target metric data is written into the first Kafka message queue.

[0047] During the anomaly detection process of the metrics to be detected, through the built-in collection tools of the AIOps intelligent operation and maintenance platform, various types of target metric data associated with the metrics to be detected are collected in real time. Then these data are written into the Kafka message queue, and the Kafka message queue is responsible for data storage and transmission to ensure that the data can reach the subsequent processing and analysis links in real time and reliably. Subsequently, during the anomaly detection process of the metrics to be detected, by sequentially obtaining various types of target metric data corresponding to the metrics to be detected from the pre-constructed first Kafka message queue, the subsequent anomaly determination process of the metrics is executed.

[0048] S120. Determine a pre-constructed orchestration model according to the index to be detected. The orchestration model is pre-orchestrated and combined based on the detection models corresponding to the target index data of each type. The orchestration model includes a combination script for the calculation results of each detection model.

[0049] Furthermore, the present application detects the target index data through a pre-configured orchestration model. It can be understood that for different indexes to be detected, their target index data are different, and the detection models for calculating the target index data are also different. Therefore, the present application pre-constructs a model combination (i.e., an orchestration model) based on each detection model for detecting the target index data of the index to be detected. It orchestrates and combines multiple detection models according to certain logic and rules according to the requirements of the index to be detected. In the orchestration model, each detection model is regarded as an independent component, and they work together according to the logic and rules of the orchestration model. The orchestration model defines the input, output of each detection model, and the dependencies between them. In addition, the orchestration model includes one or more combination scripts, which are used to process the calculation results of each detection model and combine them into a comprehensive analysis result. The combination script can include functions such as data aggregation, result judgment, and anomaly marking. According to the output results of each detection model, the calculation results are combined, comprehensively analyzed, and the index anomalies are determined according to certain logic and rules.

[0050] Among them, an orchestration engine is used to construct the orchestration model. The orchestration engine freely combines different detection models and their parameters according to different business scenarios and index requirements, and provides a unified interface to define the combination method of detection results. Through this engine, the combination method of the detection model can be quickly iterated without modifying the underlying code, thereby improving the construction efficiency and flexibility of the entire AIOps system.

[0051] Specifically, refer to Figure 2 to provide the construction and detection flowcharts of the orchestration model of the present application.

[0052] The construction process of the orchestration model includes:

[0053] Determine the corresponding detection models based on the target index data of each type;

[0054] Orchestrate and combine each detection model based on the network detection addresses of each detection model to generate an orchestration model;

[0055] After generating the orchestration model, it further includes:

[0056] Construct a combination script for combining the calculation results of each detection model based on the script combination method of the specified scripting language, and add the combination script to the orchestration model;

[0057] Configure the metric determination information of the orchestration model based on the set metric determination rules.

[0058] Among them, based on the target metric data of each type, determine the corresponding detection model. The model can perform detection calculations on the target metric data based on technologies such as statistics, machine learning, and deep learning. Furthermore, based on the network detection addresses of each detection model, combine and orchestrate them to generate an orchestration model.

[0059] Optionally, each detection model is an http detection address, uniformly provided by the detection service of Aiops. The configuration of the detection model includes default timeouts, data structures of input and output parameters, etc. When these parameters are not carried in the input data, the default parameters of the model will be used. During the entire detection process, the calculation results of each model will be carried along and passed into the output data for combining the calculation results of each model. If the AiOps detection service fails, then to ensure the stability and availability of the system, all operations will be degraded.

[0060] After generating the orchestration model, based on the script combination method of a specified scripting language, construct a combined script that combines the calculation results of each detection model. The combined scripting language can be Python, JavaScript, etc. According to business requirements, write a combined script to process the output results of each detection model and combine them into a comprehensive analysis result. Add the combined script to the orchestration model to ensure that the script can execute correctly and output results.

[0061] In addition, configure the metric determination information of the orchestration model based on the set metric determination rules. The metric determination rules can be set based on thresholds, trends, patterns, etc. of the calculation results of different detection models, and comprehensively consider the states of different calculation results in the case of abnormal comprehensive metrics, thereby generating corresponding determination rules. Furthermore, according to the determination rules, configure the metric determination information of the orchestration model to ensure that the orchestration model can correctly perform metric anomaly determination on the calculation results of combined script combination according to the determination rules.

[0062] Specifically, write a script using Python 2.7. Only need to define a method. First, judge whether the data determination conditions are met according to the configuration, such as whether all models have completed detection, whether the returned data conforms to the configuration, etc. And allow specifying models to skip detection exceptions. In the orchestration script, it is necessary to process the skipped abnormal data. The orchestration result only returns a Boolean type, and returning other results indicates detection exceptions, thus completing the construction of the orchestration model.

[0063] Optionally, after generating the orchestration model, it further includes:

[0064] Input the set simulation data into the orchestration model, and verify the orchestration logic of the orchestration model based on the output result of the orchestration model. The simulation data includes the corresponding index data of the index to be detected and the index anomaly determination result.

[0065] Refer to Figure 3 , after generating the orchestration model, use the set simulation data to verify the model, which can ensure the correctness and accuracy of the orchestration logic. By preparing simulation data corresponding to the index to be detected, these data include normal index data and abnormal index data, as well as the corresponding index anomaly determination result. Generate or collect simulation data according to the characteristics of the index to be detected. Ensure that the simulation data covers various possible scenarios and abnormal situations. Set the expected anomaly determination result for the simulation data for comparison with the output result of the orchestration model. Input the prepared simulation data into the orchestration model. Format the simulation data into a suitable format according to the input requirements of the orchestration model. Input the formatted simulation data into the orchestration model and wait for the output result. Based on the output result of the orchestration model, verify whether the orchestration logic of the orchestration model is correct. Among them, by comparing the output result of the orchestration model with the expected anomaly determination result. If the output result is consistent with the expected result, it indicates that the orchestration logic is correct; if not, the reason needs to be analyzed and adjusted. Furthermore, according to the verification result, make necessary modifications and optimization configurations to the orchestration model to ensure its accuracy and reliability.

[0066] Optionally, after generating the orchestration model, it further includes:

[0067] Generate the configuration information of the orchestration model to indicate the index to be detected to apply the orchestration model for index anomaly detection based on the configuration information.

[0068] After the construction of the orchestration model is completed, the system will generate the relevant configuration information. These configuration information details the input requirements, output format, operation parameters, etc. of the orchestration model, as well as the relevant information of the index to be detected, such as index name, data type, detection period, etc. The AIOps system will read and parse these configuration information, and collect the target index data from each data source according to the index name and data type specified in the configuration information. Furthermore, according to the configuration information, the AIOps system will divert the target index data to the orchestration model. It is implemented in ways such as message queues, data streams, etc.

[0069] It should be noted that the present application can implement the orchestration process of the above orchestration model through the Flink computing engine. In addition, other computing engines that can consume Kafka metrics can also be introduced for the orchestration model. And through the orchestration script, make full use of the algorithm combination to orchestrate the detection logic of the orchestration model, and then generate the detection results of the multi-model combination.

[0070] By providing an orchestration engine that customizes the calculation results of multiple detection algorithms, different model combination methods are provided for different metrics. Moreover, multiple orchestration combinations can be used simultaneously for the same metric, generating multiple orchestration results. By verifying the accuracy of the custom orchestration script, the flexibility and scalability of the orchestration model are improved. Based on the above pre-built orchestration model, subsequent anomaly detection of metrics can be performed by selecting this orchestration model according to the metrics to be detected.

[0071] S130. Input the target metric data of each type into the orchestration model, and calculate the multi-model calculation results of the target metric data of each type based on the combination script of the orchestration model. The multi-model calculation results are the combination of different calculation results of the target metric data of each type.

[0072] As Figure 4 shown, based on the above orchestration model, by inputting the target metric data of each type into the orchestration model, and based on each detection model (i.e., A detection model, B detection model, and C detection model) in the orchestration model, the corresponding target metric data is detected respectively to obtain the corresponding calculation results. The calculation results are obtained by calling multiple models in the orchestration model to detect the corresponding data, and the multi-model calculation results are obtained by combining the calculation results using the combination script. During this process, it is necessary to screen out the calculation results that are timed out, failed, and do not meet the expectations in the detection model.

[0073] S140. Compare the multi-model calculation results based on the pre-configured metric determination information, and perform anomaly determination of the metrics to be detected according to the comparison results, and output the corresponding determination results.

[0074] Finally, by comparing the multi-model calculation results with the pre-configured metric determination information, it is judged whether the metrics to be detected are abnormal according to the comparison results.

[0075] Taking a network latency metric as an example, after obtaining the multi-model calculation results by combining the calculation results of a series of target metric data such as network bandwidth, throughput, latency, jitter, and packet loss rate, the multi-model calculation results are determined by the metric determination information. The multi-model calculation results can be information such as detection parameters obtained by weighted fusion of the detection results of the corresponding detection models for network bandwidth, throughput, latency, jitter, packet loss rate, etc. Then the metric determination information is the weighted fusion parameter threshold corresponding to the multi-model calculation results in the case of metric anomalies. In addition, the multi-model calculation results can also be the combination of the calculation results of each detection model, such as the combination of the detection status of parameters such as network bandwidth, throughput, latency, jitter, and packet loss rate. Then the metric determination information is the combined result of the detection status of parameters such as network bandwidth, throughput, latency, jitter, and packet loss rate in the case of metric anomalies.

[0076] Finally, based on the comparison results, the anomaly determination of the metrics to be detected can be adaptively performed. If the calculation results of multiple models match the pre-configured metric determination information, the metric is determined to be abnormal. Otherwise, the metric is determined to be normal.

[0077] Thus, through a flexible multi-model combination method, the effectiveness of various model combinations can be quickly verified, significantly shortening the cycle of model development and tuning. With this process, the iteration of the model becomes more rapid, supporting the quick verification and improvement of the support strategy. Thus, while shortening the online time of the detection algorithm, it also ensures the efficient development of the algorithm. And the customized combination orchestration and determination method reduces the dependence on manual hard coding. Through the lightweight combination method of scripts, it reduces the complex workload of embedding the code for orchestration and determination into the main process in the past, significantly reducing the consumption of human resources. In addition, the combination strategy can be quickly adjusted according to actual needs, and the parameter configuration and algorithm combination can be quickly replaced. Through the script combination, a new algorithm combination method can be output within minutes, accelerating the speed of model iteration and going online. And through the flexible combination and result fusion of multiple models, the reliability of anomaly detection is further improved, ensuring the stable operation of the business system.

[0078] Optionally, after outputting the corresponding determination result, it further includes:

[0079] Update the monitoring data of the orchestration model based on the determination result, the target metric data, the calculation results and calculation durations of each detection model, and the total calculation duration of the orchestration model, and perform visual monitoring of the orchestration model based on the monitoring data.

[0080] The monitoring data can be the detection durations, statuses, detection results, and anomalies of each model in the orchestration model. It can also be the detection statuses, detection results, etc. of each metric. By statistically calculating the corresponding monitoring data from the orchestration model, and then performing visual monitoring of each part of the monitoring data according to the pre-set display rules, it is convenient to view the metric anomaly detection situation of the orchestration model and optimize the effect of metric anomaly monitoring.

[0081] In addition, outputting the corresponding determination result includes:

[0082] Write the determination result into the second Kafka message queue pre-built for the metrics to be detected, so as to extract the determination result through the intelligent operation and maintenance platform for anomaly detection result processing.

[0083] In the intelligent operation and maintenance (AIOps) scenario, write the determination result into the second Kafka message queue pre-built for the metrics to be detected to ensure that these results can be efficiently extracted and processed by the intelligent operation and maintenance platform for subsequent processing of anomaly detection results.

[0084] Among them, the determination result may include relevant information such as the name of the index determined to be abnormal, the type of abnormality, the level of abnormality, the description of the abnormality, and the determination time. By maintaining a Kafka message queue for the determination result, defined as the second Kafka message queue, the determination result is written into the second Kafka message queue. In the intelligent operation and maintenance platform, a Kafka consumer is configured to extract the determination result from the second Kafka message queue. Based on the extracted determination result, subsequent processing of the anomaly detection result is performed, such as triggering an alarm, generating a report, executing an automated script, etc. Through this process, it can be ensured that the determination result can be efficiently transmitted to the intelligent operation and maintenance platform through the Kafka message queue and subsequent anomaly detection result processing can be carried out.

[0085] As described above, by obtaining the target index data of each type corresponding to the index to be detected; determining the pre-constructed orchestration model according to the index to be detected, the orchestration model is pre-orchestrated and combined based on the detection models corresponding to the target index data of each type, and the orchestration model includes a combined script of the calculation results of each detection model; inputting the target index data of each type into the orchestration model, calculating the multi-model calculation result of the target index data of each type based on the combined script of the orchestration model, and the multi-model calculation result is a combination of different calculation results of the target index data of each type; comparing the multi-model calculation result with the pre-configured index determination information, and making an index anomaly determination of the index to be detected according to the comparison result, and outputting the corresponding determination result. By adopting the above technical means, an orchestration model is obtained by pre-orchestrating and combining the detection models corresponding to the target index data of each type, and the calculation results of the target index data of each type of the index to be detected are combined into a multi-model calculation result by combining the combined script of the calculation results of the detection models, so as to make an index anomaly determination of the index to be detected, so as to realize the efficient detection of index anomalies, simplify the cumbersome process of manually comprehensively judging index anomalies by combining the detection results of different models, reduce the cost and time consumption of index anomaly detection, and improve the flexibility and scalability of index anomaly detection.

[0086] On the basis of the above embodiment, Figure 5 This is a schematic structural diagram of an index anomaly detection system based on multiple models provided by the present application. Refer to Figure 5 This embodiment provides an index anomaly detection system based on multiple models, which specifically includes: an acquisition module 21, a model determination module 22, a model detection module 23, and a judgment module 24.

[0087] Among them, the acquisition module is configured to acquire the target index data of each type corresponding to the index to be detected;

[0088] A model determination module, configured to determine a pre-built orchestration model according to the metrics to be detected. The orchestration model is pre-orchestrated and combined based on the detection models corresponding to the target metric data of each type, and the orchestration model includes a combination script for the calculation results of each detection model;

[0089] A model detection module, configured to input the target metric data of each type into the orchestration model, and calculate the multi-model calculation results of the target metric data of each type based on the combination script of the orchestration model. The multi-model calculation results are a combination of different calculation results of the target metric data of each type;

[0090] A judgment module, configured to compare the multi-model calculation results based on the pre-configured metric judgment information, perform an abnormal metric judgment on the metrics to be detected according to the comparison results, and output the corresponding judgment results.

[0091] Specifically, obtaining the target metric data of each type corresponding to the metrics to be detected includes:

[0092] Obtaining the target metric data of each type corresponding to the metrics to be detected from the first Kafka message queue pre-built for the metrics to be detected. The target metric data of each type is collected by the intelligent operation and maintenance platform corresponding to the metrics to be detected, and the target metric data is written into the first Kafka message queue.

[0093] Specifically, the construction process of the orchestration model includes:

[0094] Determining the corresponding detection models based on the target metric data of each type;

[0095] Combining and orchestrating the detection models based on the network detection addresses of the detection models to generate an orchestration model;

[0096] After generating the orchestration model, it further includes:

[0097] Constructing a combination script for combining the calculation results of each detection model based on the script combination method of the specified scripting language, and adding the combination script to the orchestration model;

[0098] Configuring the metric judgment information of the orchestration model based on the set metric judgment rules.

[0099] After generating the orchestration model, it further includes:

[0100] Generating the configuration information of the orchestration model to indicate that the metrics to be detected apply the orchestration model for abnormal metric detection based on the configuration information.

[0101] After generating the orchestration model, it further includes:

[0102] Input the set simulated data into the orchestration model, and verify the orchestration logic of the orchestration model based on the output result of the orchestration model. The simulated data includes the corresponding index data of the index to be detected and the index anomaly determination result.

[0103] Specifically, after outputting the corresponding determination result, it further includes:

[0104] Update the monitoring data of the orchestration model based on the determination result, the target index data, the calculation results and calculation durations of each detection model, and the total calculation duration of the orchestration model, and perform visual monitoring of the orchestration model based on the monitoring data.

[0105] Outputting the corresponding determination result includes:

[0106] Write the determination result into the second Kafka message queue pre-constructed for the index to be detected, so as to extract the determination result through the intelligent operation and maintenance platform for abnormal detection result processing.

[0107] Above, by obtaining various types of target index data corresponding to the index to be detected; determining the pre-constructed orchestration model according to the index to be detected, the orchestration model is pre-orchestrated and combined based on the detection models corresponding to various types of target index data, and the orchestration model includes a combined script of the calculation results of each detection model; input various types of target index data into the orchestration model, calculate the multi-model calculation results of various types of target index data based on the combined script of the orchestration model, and the multi-model calculation results are a combination of different calculation results of various types of target index data; compare the multi-model calculation results based on the pre-configured index determination information, and perform index anomaly determination on the index to be detected according to the comparison result, and output the corresponding determination result. By adopting the above technical means, the orchestration model is obtained by pre-orchestrating and combining the detection models corresponding to various types of target index data, and the calculation results of various types of target index data of the index to be detected are combined into multi-model calculation results in combination with the combined script of the calculation results of the detection models, so as to perform index anomaly determination on the index to be detected, so as to realize the efficient detection of index anomalies, simplify the cumbersome process of manually comprehensively judging index anomalies by combining the detection results of different models, reduce the cost and time consumption of index anomaly detection, and improve the flexibility and scalability of index anomaly detection.

[0108] The multi-model-based index anomaly detection system provided by the embodiments of the present application can be configured to execute the multi-model-based index anomaly detection method provided by the above embodiments, and has the corresponding functions and beneficial effects.

[0109] On the basis of the above actual example, the embodiments of the present application further provide a multi-model-based index anomaly detection device, refer to Figure 6, the multi-model-based metric anomaly detection device includes: a processor 31, a memory 32, a communication module 33, an input device 34, and an output device 35. The memory, as a computer-readable storage medium, can be configured to store software programs, computer-executable programs, and modules, such as the program instructions / modules corresponding to the multi-model-based metric anomaly detection method described in any embodiment of the present application (for example, the acquisition module, model determination module, model detection module, and judgment module in the multi-model-based metric anomaly detection system). The communication module is configured to perform data transmission. The processor executes various functional applications and data processing of the device by running the software programs, instructions, and modules stored in the memory, that is, to implement the above-mentioned multi-model-based metric anomaly detection method. The input device can be configured to receive input digital or character information, and generate key signal inputs related to the user settings and function control of the device. The output device may include a display device such as a display screen. The above-provided multi-model-based metric anomaly detection device can be configured to execute the multi-model-based metric anomaly detection method provided in the above embodiment, and has corresponding functions and beneficial effects.

[0110] Based on the above embodiments, an embodiment of the present application further provides a non-volatile computer-readable storage medium. The non-volatile computer-readable storage medium stores computer-executable instructions, and the computer-executable instructions are configured to execute a multi-model-based metric anomaly detection method when executed by a computer processor. The storage medium can be any of various types of memory devices or storage devices. Of course, for the non-volatile computer-readable storage medium provided in the embodiment of the present application, the computer-executable instructions are not limited to the above-mentioned multi-model-based metric anomaly detection method, and can also execute related operations in the multi-model-based metric anomaly detection method provided in any embodiment of the present application.

[0111] Based on the above embodiments, an embodiment of the present application further provides a computer program product. Essentially, or the part that contributes to the prior art, or all or part of the technical solution of the present application can be embodied in the form of a software product. The computer program product is stored in a storage medium and includes several instructions for causing a computer device, a mobile terminal, or a processor therein to execute all or part of the steps of the multi-model-based metric anomaly detection method described in each embodiment of the present application.

Claims

1. A multi-model based indicator anomaly detection method, characterized in that: include: Obtain target indicator data of various types corresponding to the indicators to be detected; Determine a pre-built orchestration model according to the indicator to be detected, wherein the orchestration model is pre-combined based on the detection models corresponding to the target indicator data of each type, and the orchestration model includes a combination script of the calculation results of each detection model; Inputting each type of the target indicator data into the orchestration model, and calculating a multi-model calculation result of each type of the target indicator data based on a combination script of the orchestration model, wherein the multi-model calculation result is a combination of different calculation results of each type of the target indicator data; The multi-model calculation results are compared based on the pre-configured indicator judgment information, and the indicator abnormality judgment of the indicator to be detected is performed according to the comparison result, and the corresponding judgment result is output.

2. The multi-model-based indicator anomaly detection method according to claim 1, characterized in that: The construction process of the orchestration model includes: Determine the corresponding detection models based on the target indicator data of each type; Combining and arranging the detection models based on the network detection addresses of the detection models to generate the arrangement model; After generating the arrangement model, the process further includes: Constructing a combined script for combining the calculation results of each of the detection models based on a script combination method of a specified script language, and adding the combined script to the orchestration model; The indicator determination information of the orchestration model is configured based on the set indicator determination rule.

3. The multi-model-based indicator anomaly detection method according to claim 2, characterized in that: After generating the arrangement model, the method further includes: Generate configuration information of the orchestration model to instruct the indicator to be detected to apply the orchestration model to perform indicator anomaly detection based on the configuration information.

4. The method for detecting anomalies of indicators based on multiple models according to claim 2, characterized in that: After generating the arrangement model, the method further includes: The set simulation data is input into the orchestration model, and the orchestration logic of the orchestration model is verified based on the output result of the orchestration model, wherein the simulation data includes the corresponding indicator data of the indicator to be detected and the indicator abnormality determination result.

5. The method for detecting anomalies of indicators based on multiple models according to any one of claims 1 to 4, characterized in that: After the outputting of the corresponding determination result, the method further includes: Based on the determination result, the target indicator data, the calculation results and calculation duration of each detection model, and the total calculation duration of the orchestration model, the monitoring data of the orchestration model is updated, and visual monitoring of the orchestration model is performed based on the monitoring data.

6. The method for detecting anomalies of indicators based on multiple models according to any one of claims 1 to 4, characterized in that: The obtaining of target indicator data of various types corresponding to the indicator to be detected includes: Acquire the target indicator data of each type corresponding to the indicator to be detected from the first Kafka message queue pre-constructed for the indicator to be detected, wherein the target indicator data of each type is collected by the intelligent operation and maintenance platform corresponding to the indicator to be detected, and the target indicator data is written into the first Kafka message queue; The determination result corresponding to the output includes: The determination result is written into the second Kafka message queue pre-constructed for the indicator to be detected, so that the determination result can be extracted through the intelligent operation and maintenance platform to perform abnormal detection result processing.

7. A multi-model-based indicator anomaly detection system, characterized in that: include: An acquisition module, configured to acquire target indicator data of various types corresponding to the indicator to be detected; A model determination module is configured to determine a pre-built orchestration model according to the indicator to be detected, wherein the orchestration model is pre-arranged and combined based on the detection models corresponding to the target indicator data of each type, and the orchestration model includes a combination script of the calculation results of each detection model; A model detection module is configured to input each type of the target indicator data into the orchestration model, and calculate a multi-model calculation result of each type of the target indicator data based on a combination script of the orchestration model, wherein the multi-model calculation result is a combination of different calculation results of each type of the target indicator data; The judgment module is configured to compare the multi-model calculation results based on pre-configured indicator judgment information, perform indicator abnormality judgment of the indicator to be detected according to the comparison result, and output a corresponding judgment result.

8. A multi-model-based indicator anomaly detection device, characterized in that: include: memory and one or more processors; The memory is configured to store one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the multi-model-based indicator anomaly detection method as described in any one of claims 1-6.

9. A non-volatile computer-readable storage medium, characterized in that: The non-volatile computer-readable storage medium stores computer-executable instructions, and when the computer-executable instructions are executed by a computer processor, they are configured to execute the multi-model-based indicator anomaly detection method as described in any one of claims 1-6.

10. A computer program product, characterized in that The computer program product includes instructions, and when the instructions are executed on a computer or a processor, the computer or the processor executes the multi-model-based indicator anomaly detection method as described in any one of claims 1-6.

Images