A fault prediction method, device, equipment, medium and product

Abstract

A fault prediction method, device, equipment, medium and product are disclosed. The method comprises: obtaining a target data set, the target data set comprising: a container running index, an application log text, a listening event and a link tracking index; performing fault prediction based on the target data set to obtain a fault prediction result, the fault prediction result comprising: a fault probability, a fault type and a prediction time. Through the technical solution of the present application, real-time analysis of multi-dimensional indexes during container running can be performed to realize early prediction of faults.

Description

Technical Field

[0001] This invention relates to the field of container environment fault prediction technology, and in particular to a fault prediction method, apparatus, equipment, medium and product. Background Technology

[0002] In current cloud-native and containerized deployment environments, fault detection and recovery primarily rely on threshold-based monitoring and alerting systems, Kubernetes' native health check mechanisms, traditional fault detection systems, and basic AIOps (Artificial Intelligence for IT Operations) platform applications. However, these solutions suffer from several drawbacks: passive response, difficulty in threshold configuration, lack of fault type identification capabilities, and insufficient container environment adaptation. Therefore, a fault prediction solution for container environments that can overcome these shortcomings is urgently needed. Summary of the Invention

[0003] This invention provides a fault prediction method, apparatus, device, medium, and product to enable real-time analysis of multi-dimensional indicators during container operation and to predict faults in advance.

[0004] According to one aspect of the present invention, a fault prediction method is provided, comprising: Obtain the target data set, which includes: container runtime metrics, application log text, listening events, and tracing metrics; Fault prediction is performed based on the target dataset to obtain fault prediction results, which include: fault probability, fault type, and prediction time.

[0005] In some embodiments of the present invention, fault prediction is performed based on the target dataset to obtain fault prediction results, including: Determine the feature vector sequence based on the target dataset; The feature vector sequence is input into the fault prediction model to obtain the fault prediction result.

[0006] In some embodiments of the present invention, determining a feature vector sequence based on the target data set includes: Extract the time-series features corresponding to the target dataset, including mean, variance, trend slope, and periodic pattern; Extract log semantic features corresponding to application log text in the target dataset using a pre-trained language model; Construct a container dependency graph and extract the topological association features corresponding to the target dataset using a graph neural network; The time-series features, log semantic features, and topological association features are fused to obtain a feature vector sequence.

[0007] In some embodiments of the present invention, after performing fault prediction based on the target data set and obtaining the fault prediction result, the method further includes: Determine the confidence level corresponding to the fault prediction result; If the confidence level is greater than the first threshold and the failure probability is greater than the second threshold, an early warning is triggered.

[0008] In some embodiments of the present invention, after performing fault prediction based on the target data set and obtaining the fault prediction result, the method further includes: Based on the fault prediction results, the strategy library is queried to obtain recovery action instructions; the recovery action types include at least one of the following: container restart, horizontal scaling, resource quota adjustment, service degradation, and traffic switching. Update the container state based on the recovery action command and obtain the recovery result.

[0009] In some embodiments of the present invention, after updating the container state based on the recovery action instruction and obtaining the recovery result, the method further includes: The parameters of the fault prediction model are updated based on the recovery results and historical data.

[0010] According to another aspect of the present invention, a fault prediction device is provided, the device comprising: The acquisition module is used to acquire a target data set, which includes: container running metrics, application log text, listening events, and tracing metrics. The prediction module is used to perform fault prediction based on the target data set and obtain fault prediction results, which include: fault probability, fault type and prediction time.

[0011] According to another aspect of the present invention, an electronic device is provided, the electronic device comprising: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, which enables the at least one processor to perform the fault prediction method according to any embodiment of the present invention.

[0012] According to another aspect of the present invention, a computer-readable storage medium is provided, the computer-readable storage medium storing computer instructions for causing a processor to execute and implement the fault prediction method according to any embodiment of the present invention.

[0013] According to another aspect of the present invention, embodiments of the present invention also provide a computer program product, the computer program product including a computer program, which, when executed by a processor, implements the fault prediction method described in any embodiment of the present invention.

[0014] This invention acquires a target data set, including container runtime metrics, application log text, monitoring events, and tracing metrics. Based on this target data set, it performs fault prediction to obtain fault prediction results, which include fault probability, fault type, and prediction time. Through this invention, multi-dimensional metrics of container runtime can be analyzed in real time, enabling early fault prediction.

[0015] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

[0016] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of the present invention and should not be regarded as a limitation on the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 This is a flowchart of a fault prediction method according to an embodiment of the present invention; Figure 2 This is a schematic diagram of the structure of a fault prediction device according to an embodiment of the present invention; Figure 3 This is a schematic diagram of the structure of an electronic device that implements the fault prediction method of the present invention. Detailed Implementation

[0018] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0019] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and their derivatives, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0020] It is understood that before using the technical solutions disclosed in the various embodiments of this disclosure, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in this disclosure in an appropriate manner in accordance with relevant laws and regulations, and user authorization should be obtained.

[0021] Example 1 In current cloud-native and containerized deployment environments, fault detection and recovery mainly rely on the following technical solutions: (1) Threshold-based monitoring and alarm system: alarms are triggered by preset thresholds for indicators such as CPU (Central Processing Unit), memory, and network. When an indicator exceeds the threshold, a notification is sent, and maintenance personnel can manually intervene to handle the situation.

[0022] (2) Kubernetes (open source container orchestration platform) native health check mechanism: By periodically probing the health status of containers, it automatically restarts containers or removes them from the service endpoint when an abnormality is detected.

[0023] (3) Traditional fault detection system: Based on SNMP (Simple Network Management Protocol) or Agent, the system collects the status of hosts and services, judges faults and sends alarms through the rule engine.

[0024] (4) Initial application of AIOps (Artificial Intelligence for IT Operations): Some platforms have begun to introduce machine learning for anomaly detection, but most of them are post-event analysis, lack real-time prediction capabilities, and have low integration with container orchestration systems.

[0025] However, the above-mentioned solutions have the following drawbacks: (1) Passive response architecture: Existing solutions are mostly passive responses after a failure occurs, which cannot predict the failure in advance, resulting in long business interruption time and poor user experience.

[0026] (2) Difficulty in threshold configuration: Static thresholds are difficult to adapt to the dynamic characteristics of container environments. If the threshold is too high, it will lead to missed reports, and if it is too low, it will generate a large number of false reports, increasing the maintenance burden.

[0027] (3) Lack of fault type identification capability: Existing health checks only determine whether the container is alive, and cannot identify specific fault types (such as memory leaks, deadlocks, resource contention, etc.), resulting in a single recovery strategy.

[0028] (4) The recovery strategy is simple and crude: Kubernetes’ default recovery strategy is only to restart the container, and it cannot take differentiated recovery measures according to the fault type, which may cause the problem to recur.

[0029] (5) Lack of self-learning ability: The existing system cannot learn from historical failures and cannot continuously optimize the prediction model and recovery strategy.

[0030] (6) Insufficient container environment adaptation: Traditional monitoring tools are designed for physical machines or virtual machines, which makes it difficult to adapt to the short life cycle, high-density deployment and rapid elastic scaling characteristics of containers.

[0031] Therefore, there is an urgent need for a fault prediction solution for container environments that can overcome the above-mentioned drawbacks.

[0032] Figure 1 This is a flowchart of a fault prediction method in an embodiment of the present invention. This embodiment is applicable to fault prediction in production environment operation and maintenance scenarios of container orchestration platforms such as Kubernetes. The method can be executed by the fault prediction device in this embodiment, which can be implemented in software and / or hardware, such as... Figure 1 As shown, the method specifically includes the following steps: S101. Obtain the target data set.

[0033] In this embodiment, the target data set can be a collection of data such as container runtime metrics, logs, and events.

[0034] The target data set includes: container runtime metrics, application log text, listener events, and tracing metrics.

[0035] It should be noted that container performance metrics can include core metrics such as CPU utilization, memory usage, network I / O, disk I / O, and number of file descriptors. The sampling frequency can be configured according to actual needs (the default could be 1 second).

[0036] It should be noted that the application log text can be collected from the container's standard output and error logs, and supports log pattern recognition and anomaly detection.

[0037] It should be noted that the event monitoring can be achieved by establishing a long-lived Watch connection through the Kubernetes API Server to monitor the change event stream of core resource objects such as Pods, Deployments, and Nodes in real time, and filter and capture key abnormal events such as OOMKilled (Out Of Memory Killed, an exit event caused by the system being terminated due to memory exceeding the limit), Evicted (a forced eviction event triggered by node resource pressure), and Image Pull Back Off (an event caused by container image pull failure entering a backoff state).

[0038] It should be noted that the link tracing metrics can be distributed tracing metrics such as inter-service call latency and error rate.

[0039] Specifically, the system initializes and configures data collection parameters: metric collection frequency (default 1 second), log collection mode, and event subscription type; it establishes a Kubernetes API connection: obtaining cluster access permissions and registering a CRD (Custom Resource Definition). After completing the system initialization configuration, it performs multi-dimensional real-time data collection and preprocessing: starting the data collection agent and establishing connections with various data sources; cleaning and normalizing the collected data; organizing the data by container dimension and constructing a time-series data window; ultimately, it obtains a preprocessed, standardized time-series data stream.

[0040] S102. Based on the target data set, perform fault prediction to obtain fault prediction results.

[0041] The fault prediction results include: fault probability, fault type, and prediction time.

[0042] It should be noted that the failure probability can be the probability that a failure may occur, the failure type can be the type of failure that may occur, and the prediction time can be the expected time when the failure will occur.

[0043] Specifically, a deep learning prediction model can be used to predict faults based on the target dataset and obtain the fault prediction results.

[0044] This invention acquires a target data set, including container runtime metrics, application log text, monitoring events, and tracing metrics. Based on this target data set, it performs fault prediction to obtain fault prediction results, which include fault probability, fault type, and prediction time. Through this invention, multi-dimensional metrics of container runtime can be analyzed in real time, enabling early fault prediction.

[0045] Optionally, fault prediction is performed based on the target dataset to obtain fault prediction results, including: Determine the sequence of feature vectors based on the target dataset.

[0046] In this embodiment, the feature vector sequence can be a feature vector matrix obtained by performing intelligent feature engineering multi-scale feature extraction on the preprocessed standardized time-series data stream.

[0047] Specifically, different feature extraction methods can be used for different types of data in the target dataset. For example, statistical and trend features can be extracted from time-series indicators, template parsing and semantic encoding can be performed on log data, service dependency graphs can be constructed and graph features can be extracted, and finally, multi-source features can be fused through attention mechanisms to obtain fused features, which is the feature vector sequence.

[0048] The feature vector sequence is input into the fault prediction model to obtain the fault prediction result.

[0049] In this embodiment, the fault prediction model can be, for example, a deep learning prediction model. Its model architecture can adopt a Transformer-LSTM hybrid architecture. The Transformer captures long-distance dependencies, while the LSTM (Long Short-Term Memory) model the dynamic changes over time. The model performs multi-task learning simultaneously: it simultaneously outputs fault probability prediction (binary classification), fault type identification (multi-classification), and fault time prediction (regression), sharing the underlying feature representation.

[0050] Specifically, during system initialization configuration, a pre-trained model is loaded: a fault prediction model adapted to the current environment is pulled from the model repository, such as a deep learning model. Then, the fused features are input into the deep learning model, and the model outputs fault prediction results (including: fault probability, fault type, and expected occurrence time).

[0051] Optionally, a sequence of feature vectors is determined based on the target dataset, including: Extract the time-series features corresponding to the target dataset.

[0052] The time-series characteristics include mean, variance, trend slope, and periodic patterns.

[0053] Specifically, for time series feature extraction, a sliding window mechanism can be used to extract multi-scale time series features, including statistical features such as mean, variance, trend slope, and periodic patterns.

[0054] Extract log semantic features corresponding to application log text in the target dataset using a pre-trained language model.

[0055] Specifically, regarding log semantic features: pre-trained language models (such as BERT variants) can be used to encode application log text and extract semantic vectors representing abnormal patterns. BERT, short for Bidirectional Encoder Representations from Transformers, is a pre-trained language representation model that learns deep bidirectional contextual representations on unlabeled text through masked language models and next-sentence prediction tasks. After fine-tuning, it is adapted to downstream natural language processing tasks. The overall architecture for encoding application log text using pre-trained language models (such as BERT variants) to extract semantic vectors representing abnormal patterns can be described as follows: For the original application log stream, Step 1: Log preprocessing and structured extraction: Regular expression parsing: timestamp, log level, component name, message body; Output: structured fields + original message text. Step 2: Template parsing and variable masking: Identifying constant templates: "ERROR Connection timeout to..." "(in, (The asterisk is a wildcard used to match dynamic content of any length); variable substitution: <ip> ， <port>,<DB_NAME> Placeholders; Output: Template ID + parameterized message. Step 3: Semantic encoding of pre-trained language model: Tokenization → Input BERT variant → Extract [CLS] vector / Last layer average pooling; Output: d-dimensional dense semantic vector (usually 768 or 1024 dimensions). Step 4: Anomaly pattern detection: Vector input / Clustering / Classifier / Distance metric; Output: Anomaly score + Anomaly type label + Similar historical cases.

[0056] Construct a container dependency graph and extract the topological association features corresponding to the target dataset using a graph neural network.

[0057] Specifically, regarding topological association features: a container dependency graph can be constructed, and graph neural networks can be used to extract the association features between services to capture cascading failure modes. The specific implementation process can be described as follows: Container runtime monitoring data stream: container metrics + network connectivity + service call chain (distributed tracing); Step 1: Container Dependency Graph Construction: Nodes: Container / Pod / Service Instances; Edges: Network Connections, Call Dependencies, Shared Resources, Deployment Affinity; Attributes: Node Resource Status, Edge Traffic Characteristics, Temporal Changes. Step 2: Graph Neural Network Encoding: Message Passing: Aggregate Neighbor Features to Capture Dependency Strength; Hierarchical Aggregation: Multi-hop Propagation to Model the Cascading Impact Range; Output: Context-Enhanced Embedding Vector for Each Node. Step 3: Cascading Failure Mode Recognition: Single Point of Occurrence Detection: Deviation of Node's Own State; Propagation Risk Prediction: Probability and Path of Anomaly Spreading Along Graph Edges; Global Impact Assessment: Predict the Cascading Failure Range and Severity.

[0058] Output: Root cause analysis of the fault + cascading propagation path + impact prediction + loss prevention recommendations.

[0059] The time-series features, log semantic features, and topological association features are fused to obtain a feature vector sequence.

[0060] Specifically, in the feature fusion stage, multi-source heterogeneous features can be adaptively fused through an attention mechanism to form a unified feature representation.

[0061] Optionally, after performing fault prediction based on the target dataset and obtaining the fault prediction results, the process may also include: Determine the confidence level corresponding to the fault prediction results.

[0062] In this embodiment, after inputting the fused features into the deep learning model to obtain the fault prediction results (including fault probability, fault type, and expected occurrence time), uncertainty estimation can be performed: a Bayesian neural network or MCDropout technology is introduced to output the confidence interval of the prediction results to assist decision-making. MCDropout (Monte Carlo Dropout) is a Bayesian approximate inference technique that maintains random deactivation and activation of the Dropout layer during the testing phase, performs multiple forward propagation samplings, and uses the mean of the network output as the prediction result and the variance as the uncertainty measure, thereby quantifying the prediction confidence of the deep learning model.

[0063] If the confidence level is greater than the first threshold and the failure probability is greater than the second threshold, an early warning will be triggered.

[0064] The first threshold can be a confidence threshold set based on actual needs or empirical values. When the confidence level exceeds this threshold, the obtained fault prediction result can be considered reliable. The second threshold can be a fault occurrence probability threshold set based on actual needs or empirical values. When the fault probability exceeds this threshold, the predicted fault can be considered likely to occur.

[0065] Specifically, the confidence level of the fault prediction result is calculated, and an early warning is triggered when the confidence level is greater than the first threshold and the fault probability is greater than the second threshold.

[0066] In practice, online inference optimization is also possible: by using model quantization and knowledge distillation techniques, the prediction latency can be controlled within 10ms to meet real-time requirements.

[0067] Optionally, after performing fault prediction based on the target dataset and obtaining the fault prediction results, the process may also include: Based on the fault prediction results, the strategy library is queried to obtain recovery action instructions.

[0068] The recovery action types include at least one of the following: container restart, Pod migration, horizontal scaling, resource quota adjustment, service degradation, and traffic switching.

[0069] In practice, the policy library is initialized during system initialization configuration: importing the default recovery policy mapping table and configuring security constraint parameters. During the intelligent decision-making phase, policy library management is possible: maintaining the mapping relationship between fault types and recovery policies, supporting both rule-based and learning-based policy modes. Reinforcement learning optimization is also possible: based on the DQN (Deep Q-Network) algorithm, decision-making policies are continuously optimized based on recovery performance feedback. Furthermore, a security constraint mechanism can be set: setting circuit breaker thresholds for recovery operations to prevent service avalanche caused by consecutive recovery failures, and supporting manual approval of high-risk operations.

[0070] Specifically, based on the fault type in the fault prediction results, the strategy library is queried to obtain candidate recovery solutions, and the optimal recovery strategy is selected in combination with the current system status.

[0071] Update the container state based on the recovery action command and obtain the recovery result.

[0072] The recovery results can include aspects such as recovery success rate, recovery time, and scope of business impact.

[0073] In the specific implementation process, a gradual recovery can be performed: a gray-scale recovery strategy is adopted, first performing recovery actions on a portion of instances, verifying the effect, and then expanding to all instances. In addition, recovery orchestration can be performed: multi-step recovery process orchestration is supported, and the dependencies of recovery steps are defined through DAG (Directed Acyclic Graph).

[0074] Specifically, check whether the security constraints are met, call the Kubernetes API to perform the recovery operation, record the recovery operation log, monitor the running status of the container after recovery, calculate the recovery success rate and recovery time, and add the data from this failure to the training sample library.

[0075] Optionally, after updating the container state based on the recovery action command and obtaining the recovery result, the following may also be included: The parameters of the fault prediction model are updated based on the recovery results and historical data.

[0076] In practice, after automatic recovery is executed, the recovery effect is evaluated: evaluation indicators such as recovery success rate, recovery time, and business impact scope are defined to quantify the recovery effect. Then, incremental model updates are performed: online learning is conducted based on new fault samples, federated learning technology is used to support multi-cluster collaborative training, and incremental model updates are periodically triggered to optimize the recovery strategy weights in the strategy library. Furthermore, fault cases and recovery experience are compiled into a knowledge graph to support rapid matching and handling of similar faults.

[0077] It should be added that, in the specific implementation process, the input sources of the fault prediction model can include: log data, topology data, and indicator data. Log data can be in the form of unstructured text streams, obtained through standard outputs of various services / file collection, and the preprocessing process can be: template parsing → template ID sequence → BERT encoding → log semantic vector. Topology data can be in the form of service call relationships, obtained through distributed tracing (Zipkin / Jaeger) or network traffic analysis, and the preprocessing process can be: constructing a DAG → graph neural network encoding → service embedding vector. Indicator data can be in the form of time-series values ​​(CPU / memory / latency), obtained through Prometheus / cloud monitoring API, and the preprocessing process can be: sliding window normalization → LSTM / TCN (Temporal Convolutional Network) encoding → time-series feature vector.

[0078] The three outputs of the fault prediction model can include: fault probability, fault type, and expected occurrence time. The fault probability corresponds to a binary classification task, a fully connected + sigmoid network layer, and a binary cross-entropy loss function. Its physical meaning is whether a fault will occur within a future T-window, with an output value ∈ [0, 1]. The fault type corresponds to a multi-class classification task, a fully connected + softmax network layer, and a cross-entropy loss function. Its physical meaning is predicting the root cause category of the fault (network / storage / computation / dependency / configuration), with an output of the category probability distribution. The expected occurrence time corresponds to a regression task, a fully connected + ReLU (Rectified Linear Unit) network layer, and a mean squared error or Huber Loss loss function. Its physical meaning is predicting the interval between the current time and the fault occurrence (in minutes), with an output value ∈ [0, +∞).

[0079] Specifically, the overall architecture of the fault prediction model can be described as follows: Log data streams (unstructured text) are input into a template parsing module to extract log templates and perform semantic encoding using BERT. Topology data streams (service call relationships) are input into a graph construction module to build a service dependency DAG and extract graph structure features. Metric data streams (time-series values) are input into a time-series encoding module to pre-process sliding window features based on a hybrid LSTM / Transformer architecture. These three types of features are then input into a multi-source feature fusion layer, where adaptive weighted multi-source features are applied using a cross-attention mechanism. The fused features are then input into a shared encoding layer, where a Transformer encoder extracts high-order interaction features. These high-order interaction features are then input into a fault probability output head, a fault type classification head, and an occurrence time regression head, respectively. The fault probability output head uses Sigmoid for binary classification to output fault probabilities, the fault type classification head uses Softmax for multi-class classification to output fault types, and the occurrence time regression head uses ReLU+Linear for time prediction to output the estimated occurrence time.

[0080] The technical solution of this invention can achieve the following beneficial effects: Predictive maintenance: Compared with passive response solutions, this solution can predict faults 5-30 minutes in advance, significantly reducing business downtime. Accurate fault identification: The multi-task learning model can simultaneously output fault probability, type, and time, supporting differentiated recovery strategies. Adaptive learning: The model is continuously optimized through a closed-loop feedback mechanism to adapt to changes in business and environment. Container-native design: Deeply integrated with the Kubernetes ecosystem, it fully utilizes container orchestration capabilities to achieve automatic recovery. Secure and controllable: Multi-layered security constraint mechanisms ensure that recovery operations will not cause larger faults.

[0081] Example 2 Figure 2 This is a schematic diagram of a fault prediction device according to an embodiment of the present invention. This embodiment is applicable to fault prediction in production environment operation and maintenance scenarios of container orchestration platforms such as Kubernetes. The device can be implemented using software and / or hardware, and can be integrated into any device that provides fault prediction functionality, such as… Figure 2 As shown, the fault prediction device specifically includes: an acquisition module 201 and a prediction module 203.

[0082] The acquisition module 201 is used to acquire a target data set, which includes: container running metrics, application log text, listening events, and tracing metrics. The prediction module 202 is used to perform fault prediction based on the target data set and obtain fault prediction results, which include: fault probability, fault type and prediction time.

[0083] Optionally, the prediction module 202 includes: The determining unit is used to determine a sequence of feature vectors based on the target data set; The input unit is used to input the feature vector sequence into the fault prediction model to obtain the fault prediction result.

[0084] Optionally, the determining unit is specifically used for: Extract the time-series features corresponding to the target dataset, including mean, variance, trend slope, and periodic pattern; Extract log semantic features corresponding to application log text in the target dataset using a pre-trained language model; Construct a container dependency graph and extract the topological association features corresponding to the target dataset using a graph neural network; The time-series features, log semantic features, and topological association features are fused to obtain a feature vector sequence.

[0085] Optionally, the device further includes: The determination module is used to determine the confidence level corresponding to the fault prediction result; The triggering module is used to trigger an early warning if the confidence level is greater than a first threshold and the failure probability is greater than a second threshold.

[0086] Optionally, the device further includes: The query module is used to query the strategy library based on the fault prediction results to obtain recovery action instructions; the recovery action types include at least one of the following: container restart, horizontal scaling, resource quota adjustment, service degradation, and traffic switching. The update module is used to update the container state based on the recovery action command and obtain the recovery result.

[0087] Optionally, the device further includes: An update module is used to update the parameters of the fault prediction model based on the recovery results and historical data.

[0088] The above-mentioned products can execute the fault prediction method provided in any embodiment of the present invention, and have the corresponding functional modules and beneficial effects of the execution method.

[0089] Example 3 Figure 3 A schematic diagram of an electronic device 30 that can be used to implement embodiments of the present invention is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0090] like Figure 3 As shown, the electronic device 30 includes at least one processor 31 and a memory, such as a read-only memory (ROM) 32 or a random access memory (RAM) 33, communicatively connected to the at least one processor 31. The memory stores computer programs executable by the at least one processor. The processor 31 can perform various appropriate actions and processes based on the computer program stored in the ROM 32 or loaded from storage unit 38 into the RAM 33. The RAM 33 can also store various programs and data required for the operation of the electronic device 30. The processor 31, ROM 32, and RAM 33 are interconnected via a bus 34. An input / output (I / O) interface 35 is also connected to the bus 34.

[0091] Multiple components in electronic device 30 are connected to I / O interface 35, including: input unit 36, such as keyboard, mouse, etc.; output unit 37, such as various types of monitors, speakers, etc.; storage unit 38, such as disk, optical disk, etc.; and communication unit 39, such as network card, modem, wireless transceiver, etc. Communication unit 39 allows electronic device 30 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0092] Processor 31 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 31 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 31 performs the various methods and processes described above, such as fault prediction methods: Obtain the target data set, which includes: container runtime metrics, application log text, listening events, and tracing metrics; Fault prediction is performed based on the target dataset to obtain fault prediction results, which include: fault probability, fault type, and prediction time.

[0093] In some embodiments, the fault prediction method may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 38. In some embodiments, part or all of the computer program may be loaded and / or installed on electronic device 30 via ROM 32 and / or communication unit 39. When the computer program is loaded into RAM 33 and executed by processor 31, one or more steps of the fault prediction method described above may be performed. Alternatively, in other embodiments, processor 31 may be configured to perform the fault prediction method by any other suitable means (e.g., by means of firmware).

[0094] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0095] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0096] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0097] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0098] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or middleware components (e.g., application servers), or frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0099] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0100] In one embodiment, the present invention further includes a computer program product, which includes a computer program that, when executed by a processor, implements the fault prediction method of any embodiment of the present invention.

[0101] In implementing the computer program product, computer program code for performing the operations of this invention can be written in one or more programming languages ​​or a combination thereof. Programming languages ​​include object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0102] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0103] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.< / port> < / ip>

Claims

1. A fault prediction method, characterized in that, include: Obtain the target data set, which includes: container runtime metrics, application log text, listening events, and tracing metrics; Fault prediction is performed based on the target dataset to obtain fault prediction results, which include: fault probability, fault type, and prediction time.

2. The method according to claim 1, characterized in that, Fault prediction is performed based on the target dataset to obtain fault prediction results, including: Determine the feature vector sequence based on the target dataset; The feature vector sequence is input into the fault prediction model to obtain the fault prediction result.

3. The method according to claim 2, characterized in that, Determining the feature vector sequence based on the target dataset includes: Extract the time-series features corresponding to the target dataset, including mean, variance, trend slope, and periodic pattern; Extract log semantic features corresponding to application log text in the target dataset using a pre-trained language model; Construct a container dependency graph and extract the topological association features corresponding to the target dataset using a graph neural network; The time-series features, log semantic features, and topological association features are fused to obtain a feature vector sequence.

4. The method according to claim 1, characterized in that, After performing fault prediction based on the target dataset and obtaining the fault prediction result, the process further includes: Determine the confidence level corresponding to the fault prediction result; If the confidence level is greater than the first threshold and the failure probability is greater than the second threshold, an early warning is triggered.

5. The method according to claim 1, characterized in that, After performing fault prediction based on the target dataset and obtaining the fault prediction result, the process further includes: Based on the fault prediction results, the strategy library is queried to obtain recovery action instructions; the recovery action types include at least one of the following: container restart, horizontal scaling, resource quota adjustment, service degradation, and traffic switching. Update the container state based on the recovery action command and obtain the recovery result.

6. The method according to claim 5, characterized in that, After updating the container state based on the recovery action instruction and obtaining the recovery result, the process also includes: The parameters of the fault prediction model are updated based on the recovery results and historical data.

7. A fault prediction device, characterized in that, include: The acquisition module is used to acquire a target data set, which includes: container running metrics, application log text, listening events, and tracing metrics. The prediction module is used to perform fault prediction based on the target data set and obtain fault prediction results, which include: fault probability, fault type and prediction time.

8. An electronic device, characterized in that, The electronic device includes: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the fault prediction method according to any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that cause a processor to execute the fault prediction method according to any one of claims 1-6.

10. A computer program product comprising a computer program that, when executed by a processor, implements the fault prediction method according to any one of claims 1-6.

Images