Container failure analysis method, device, and storage medium

Abstract

The application discloses a container fault analysis method and device and a storage medium, relates to the technical field of fault analysis, and comprises the following steps: after obtaining alarm information, determining a fault object according to the alarm information, and determining a downstream object of the fault object; obtaining running state information of the fault object and running state information of the downstream object; inputting the running state information of the fault object and the running state information of the downstream object into a target fault analysis model to obtain a fault cause. The application can improve the efficiency and accuracy of fault analysis in a containerized environment.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of fault analysis, in particular to a container fault analysis method, device and storage medium. BACKGROUND

[0002] In a container cluster, each container carries different services or applications. Once a container fails, it may directly affect the function and service quality of the entire system. Through timely fault detection, problems can be quickly located and repaired, minimizing the impact of failures on the system and ensuring high availability of the system.

[0003] When performing fault detection in a container cluster management system, the current method is to obtain all running state information in the container and analyze it one by one to find the fault cause. However, in a large-scale cluster environment, analyzing the running state information of all containers one by one not only consumes time and effort, but also easily leads to information redundancy and noise, making fault location difficult.

[0004] The above content is only used to assist in understanding the technical solutions of the present application and does not represent the acknowledgement of the above content as prior art. SUMMARY

[0005] The main purpose of the present application is to provide a container fault analysis method, device and storage medium, aiming to solve the technical problem of how to improve the efficiency and accuracy of fault analysis in a containerized environment.

[0006] To achieve the above purpose, the present application provides a container fault analysis method, which comprises:

[0007] After obtaining the alarm information, the fault object is determined according to the alarm information, and the downstream object of the fault object is determined;

[0008] Obtain the running state information of the fault object and the running state information of the downstream object;

[0009] The running state information of the fault object and the running state information of the downstream object are input into a target fault analysis model to obtain the fault cause.

[0010] In an embodiment, the fault object includes a route, a service and a container group, and the step of determining the downstream object of the fault object comprises:

[0011] When the fault object is the route, the downstream service of the route is determined according to the route configuration file of the route;

[0012] When the fault object is the service, the downstream container group of the service is determined according to the IP address and port list of the service.

[0013] In an embodiment, when the fault object is the service, after the step of determining the downstream container group of the service according to the IP address and the port list of the service, the method further comprises:

[0014] When the fault object is the container group, determining a label selector matched with the container group according to a label of the container group;

[0015] Determining a target controller corresponding to the container group according to the label selector.

[0016] In an embodiment, the step of inputting the running state information of the fault object and the running state information of the downstream object into a target fault analysis model to obtain a fault cause comprises:

[0017] According to an alarm level corresponding to the alarm information, sorting the running state information;

[0018] According to the sorting result, inputting the running state information of the fault object and the running state information of the corresponding downstream object into the target fault analysis model to obtain the fault cause.

[0019] In an embodiment, after the step of inputting the running state information of the fault object and the running state information of the downstream object into a target fault analysis model to obtain a fault cause and a repair measure, the method further comprises:

[0020] Classifying the fault cause and the repair measure according to a fault type;

[0021] Inputting the classified fault cause and the repair measure into a preset knowledge base to update the knowledge base.

[0022] In an embodiment, before the step of determining a fault object according to alarm information and determining an associated downstream object according to a level of the fault object after obtaining the alarm information, the method further comprises:

[0023] Obtaining running state information of a container according to a monitoring tool;

[0024] Analyzing the running state information of the container according to a preset abnormality detection rule;

[0025] In an embodiment, the method further comprises:

[0026] Obtaining historical fault data, and labeling a fault type and a repair measure of the historical fault data to obtain a training set;

[0027] Training a large model according to the training set to obtain the target fault analysis model.

[0028] In one embodiment, after the step of inputting the operating status information of the faulty object and the operating status information of the downstream object into the target fault analysis model to obtain the fault cause and repair measures, the following is included:

[0029] Identify frequently failing areas based on historical fault records;

[0030] Set monitoring indicators for the frequently failing areas;

[0031] When the monitoring status information of the frequently faulty area is greater than or equal to the monitoring index, an early warning is triggered.

[0032] In addition, to achieve the above objectives, this application also proposes a container failure analysis device, which includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the container failure analysis method as described above.

[0033] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the program process abnormal monitoring method described above.

[0034] This application provides a container fault analysis method that triggers alarms when anomalies or potential problems are detected. Based on the alarm information, the faulty object is identified. After identifying the faulty object, its downstream dependencies are identified. The runtime status information of the faulty object and its downstream objects is obtained and input into a pre-trained target fault analysis model. Based on the input information and a learned knowledge base, the target fault analysis model outputs possible fault causes, impact scope, and remedial measures.

[0035] In this application, identifying the faulty object and its downstream objects helps to comprehensively assess the scope of the fault's impact. By focusing only on the faulty object and its downstream objects, the scope of analysis can be significantly narrowed, reducing the amount of data that needs to be monitored and analyzed. This helps to speed up fault diagnosis while reducing the burden on computing resources. Furthermore, limiting the analysis to the faulty object and its downstream objects avoids feeding information from a large number of irrelevant containers into the fault analysis model. This saves computing resources and improves the model's response speed and accuracy. The targeted fault analysis model can accurately identify the causes of the fault, such as abnormal CPU usage and memory leak patterns, thereby improving the accuracy of fault location. Attached Figure Description

[0036] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0037] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0038] Figure 1 This is a flowchart illustrating an embodiment of the container fault analysis method of this application.

[0039] Figure 2 This is a detailed flowchart illustrating an embodiment of the container failure analysis method of this application.

[0040] Figure 3 Another detailed flowchart provided for Embodiment 1 of the container failure analysis method of this application;

[0041] Figure 4 This is a flowchart illustrating Embodiment 2 of the container fault analysis method of this application;

[0042] Figure 5 This is a flowchart illustrating Embodiment 3 of the container failure analysis method of this application;

[0043] Figure 6 This is a flowchart illustrating Embodiment 4 of the container failure analysis method of this application;

[0044] Figure 7 This is a flowchart illustrating Embodiment 5 of the container fault analysis method of this application;

[0045] Figure 8 This is a schematic diagram of the hardware operating environment involved in the container fault analysis method in this application embodiment. Detailed Implementation

[0046] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0047] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0048] The main solution of this application embodiment is: after obtaining alarm information, determine the faulty object based on the alarm information, and determine the downstream object associated with the faulty object; obtain the running status information of the faulty object and the running status information of the downstream object; input the running status information of the faulty object and the running status information of the downstream object into the target fault analysis model to obtain the fault cause and repair measures.

[0049] In a container cluster, each container hosts different services or applications. If a container fails, it can directly impact the functionality and service quality of the entire system. Timely fault detection allows for rapid problem location and remediation, minimizing the impact of failures and ensuring high system availability.

[0050] In container cluster management systems, the current approach for fault detection is to acquire all runtime status information from each container and analyze them one by one to find the cause of the fault. However, in large-scale cluster environments, analyzing the runtime status information of all containers one by one is not only time-consuming and laborious, but also prone to information redundancy and noise, making fault localization difficult.

[0051] This application provides a container fault analysis method that triggers alarms when an anomaly or potential problem is detected. Based on the alarm information, the method identifies the object that has failed. After identifying the failed object, it identifies its downstream dependencies. The method acquires the runtime status information of the failed object and its downstream objects and inputs it into a pre-trained target fault analysis model. The target fault analysis model, based on the input information and a learned knowledge base, outputs possible causes of the fault, the scope of impact, and remedial measures.

[0052] In this application, identifying the faulty object and its downstream objects helps to comprehensively assess the scope of the fault's impact. By focusing only on the faulty object and its downstream objects, the scope of analysis can be significantly narrowed, reducing the amount of data that needs to be monitored and analyzed. This helps to speed up fault diagnosis while reducing the burden on computing resources. Furthermore, limiting the scope of analysis to the faulty object and its downstream objects avoids feeding information from a large number of irrelevant containers into the fault analysis model. This saves computing resources and improves the model's response speed and accuracy. The targeted fault analysis model can accurately identify the causes of the fault, such as abnormal CPU usage and memory leak patterns, thereby further improving the accuracy of fault location.

[0053] It should be noted that the executing entity in this embodiment can be a computing service device with network communication and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device or apparatus capable of performing the above functions. The following description uses a container fault analysis device as an example to illustrate this embodiment and the subsequent embodiments.

[0054] Based on this, embodiments of this application provide a container failure analysis method, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the container fault analysis method of this application.

[0055] In this embodiment, the container fault analysis method includes steps S100~S300:

[0056] Step S100: After obtaining the alarm information, determine the faulty object based on the alarm information, and determine the downstream object of the faulty object.

[0057] It should be noted that the faulty object refers to the entity or component that has failed.

[0058] In this embodiment, the specific alarm object is determined based on the alarm information. The faulty object may be a service, component, Pod, or node. If the alarm information contains network transmission-related error information such as high network latency, increased packet loss rate, or route unreachability, it indicates that the fault occurs at the routing level. If the alarm information shows prolonged service response time, decreased throughput, or increased error rate, it indicates that the fault occurs at the service level. If the alarm information shows that the container status of a Pod is abnormal (such as stopped or crashed), or the resource usage is abnormal (such as high CPU usage or insufficient memory), it indicates that the fault occurs at the Pod level.

[0059] After identifying the object triggering the alert, determine its downstream dependencies. In a microservice architecture, the dependencies between components are complex, and a failure in one component can affect multiple downstream components. Therefore, identifying downstream objects helps to comprehensively assess the scope of the failure and provides guidance for subsequent troubleshooting and remediation.

[0060] Please refer to Figure 2 In one feasible implementation, step S100 may further include steps S110 to S120:

[0061] Step S110: When the faulty object is the route, determine the downstream service of the route according to the route configuration file of the route.

[0062] It's important to note that a container group (i.e., a Pod) is the smallest unit of deployment in a Kubernetes (K8s) cluster. It contains one or more containers that share network and storage resources and run on the same host. A Service is an abstraction layer that defines a logical collection of containers and the policies for accessing them. It can group multiple Pods together and provide them with a unique DNS name and a stable IP address. In a K8s cluster, external requests enter the cluster via routes (such as Ingress). Routers forward requests to the appropriate Service. The Service then routes the request to the matching Pod (container group) based on a tag selector.

[0063] In this implementation, the routing configuration file is a file containing route definitions that specify how incoming traffic to the cluster is routed to specific services. The configuration file may be in JSON, YAML, XML, or other formats. First, the contents of the routing configuration file are read and loaded. Based on the configuration file's format (e.g., YAML), the corresponding parsing library (e.g., PyYAML) is used to parse the file content, converting it into a data structure easily manipulated in code (e.g., a Python dictionary or list). The parsed data structure typically contains multiple route definitions. These definitions are traversed to find configuration information associated with the current route. For each route definition, key information, such as the route name, path, target service name, or identifier, is extracted. The service to which the route points is determined based on this key information. For example, using the extracted target service name or identifier, the corresponding service is searched for and recorded in the cluster's service registry (e.g., Kubernetes Service resources) or the configured service list.

[0064] Step S120: When the faulty object is the service, determine the downstream container group of the service based on the service's IP address and port list.

[0065] In this implementation, the IP address and port list refers to an Endpoint, which represents a set of IP addresses and port numbers of the Service backend, used to direct traffic from the Service to the Pods that are actually running the application. Each Service is associated with a corresponding Endpoint, which dynamically maintains the network endpoint information of all Pods selected by the Service.

[0066] In this implementation, the Kubernetes API is used to query the Endpoints object associated with a specific Service. A list containing IP addresses and ports is retrieved, corresponding to the Pods currently capable of responding to Service requests. If the Endpoints list is empty, it means no Pods match the Service's selector; or all matching Pods are not in the "ready" state, indicating a problem with the Service.

[0067] In this implementation, firstly, the Kubernetes API (e.g., via kubectl get endpoints) is used. <service-name>The command queries the Endpoints object associated with the specific Service using the Kubernetes client library. The Endpoints resource object is obtained and the list of IP addresses and ports are parsed from it. Next, the Pod IPs that match the IP addresses in the Endpoints are found. The Pod's name or labels are used to further verify and confirm the association.

[0068] In this embodiment, the status of the Pods associated with the Endpoints can also be checked. The kubectl get pods command is used with the appropriate label selector to find the Pods, and their Ready condition is checked. If the Pods are in the Running state and the READY column shows 1 / 1 (or other similar "ready / total" ratio), it indicates that the Pods are ready and can accept requests. If the status of the Pods does not match the expectation or the IP addresses in the Endpoints list do not match the IP addresses of the Pods, it indicates that there is a problem with the Pods and further analysis of the related information is needed.

[0069] In one possible implementation, step S120 can be followed by steps S130-S140:

[0070] Step S130, when the fault object is the container group, determining a label selector matching the container group according to the label of the container group.

[0071] Step S140, determining a target controller corresponding to the container group according to the label selector.

[0072] In this embodiment, the target controller can be a Deployment, a StatefulSet, and a DaemonSet. Deployment is a controller in Kubernetes for managing stateless applications. It provides functions such as replica management, automatic scaling, rolling upgrades, etc. for applications. StatefulSet is a controller for managing stateful applications. It guarantees that each Pod has a stable and unique identifier and provides persistent storage for them. DaemonSet ensures that each node in the cluster runs a copy of the Pod.

[0073] In this embodiment, each container group (i.e. Pod) can be labeled when created, and these labels are used to identify and select Pods. Controllers such as Deployment, StatefulSet, and DaemonSet use label selectors to determine which Pods they should manage.

[0074] Alternatively, first, use kubectl describe pod <pod-name>Or the command such as kubectl get pods --show-labels to view the labels of the Pod. And view the definition of the related controller, find the selector part. Second, match the labels of the Pod with the selector of the controller, if matched, the Pod is managed by the controller.

[0075] Exemplarily, the label selector of the Deployment controller is matchLabels: {app: myapp, env: production}. If there is a Pod with the label app=myapp, env=production, the Pod matches the selector of the Deployment controller.

[0076] In the embodiment, in the Kubernetes cluster, the Pod is usually managed by a specific controller (such as Deployment, StatefulSet, DaemonSet, etc.). Determining the controller corresponding to the Pod helps to determine which controller is responsible for the life cycle management of the Pod, so as to determine who should be contacted or which controller configuration should be checked in case of failure. After the controller corresponding to the Pod is determined, by analyzing the running state information of the controller, the specific link causing the Pod failure can be located. More specific and richer information is provided for subsequent analysis according to the target failure analysis model.

[0077] In step S200, the running state information of the failure object and the running state information of the downstream object are obtained.

[0078] In this embodiment, when a routing failure occurs, the running state information of the ingress is obtained. In Kubernetes, ingress is usually used to define rules for external access to internal services in the cluster. The running state information can be obtained through the management interface of Kubernetes (such as Dashboard) or command line tools (such as kubectl). The running state information of ingress includes the name of ingress, rules, associated services, and detailed information of backend pods, etc. The running state information of service includes its associated pods, selector (used to determine which pods should be exposed by the service), endpoints (the actual pods IP and port pointed by the service), etc. The running state information of pod includes its node, IP address, container state (such as running, stopped, etc.), logs, and resource usage, etc. The running state information of deployment includes the number of pod replicas it manages, update policy, event log, and current state (such as in progress, completed, failed, etc.). The running state information of statefulset includes the number of pod replicas it manages, persistent storage information of each pod, state, and event log, etc. These information can also be obtained through the management interface of Kubernetes or kubectl command. The running state information of daemonset includes the number of pod replicas it manages, node selector (used to determine which nodes should run pod replicas), and event log, etc.

[0079] In step S300, the running state information of the failure object and the running state information of the downstream object are input into the target failure analysis model to obtain the failure cause.

[0080] In this embodiment, the collected running state information of the failure object and the downstream object is sorted to ensure that the data format meets the input requirements of the target failure analysis model. The sorted data is input into the target failure analysis model. The output result of the failure analysis model is received and analyzed. The output result usually includes the specific cause of the failure, possible repair measures, and the priority of the repair measures, etc.

[0081] Optionally, before implementing the repair measures, the feasibility and safety of the repair measures are verified. The repair process is simulated in a test environment or sandbox environment. Before simulating the repair, the key data and configurations are backed up. The measures are implemented step by step, and after each step is completed, the test and verification are performed to ensure that each step is safe and effective.

[0082] Please refer to Figure 3 In a feasible implementation, step S300 can include steps S310-S320:

[0083] Step S310, according to the alarm level corresponding to the alarm information, the running state information of the fault object is sorted.

[0084] Step S320, according to the sorting result, the running state information of the fault object and the corresponding running state information of the downstream object are input into the target fault analysis model to obtain the fault cause and the repair measure.

[0085] In this embodiment, the alarm level can be directly obtained from the alarm information. It can also be determined according to other alarm information. When the alarm level is determined according to other alarm information, the alarm type, alarm time, alarm description and other information are extracted from the alarm information. According to the preset rules or mapping table, the key information in the alarm information is associated with a specific alarm level (such as emergency, important, general, warning, etc.). For each fault object, collect its current running state information, and sort the running state information of the fault object according to the determined alarm level. The alarms of emergency and important level should be handled first, and then the alarms of general and warning level should be analyzed and processed. By processing the high-level alarms first, it can ensure that critical problems and emergency failures are responded in time, and resources are not scattered by low-priority problems.

[0086] Based on the first embodiment of the present application, in the second embodiment of the present application, the same or similar contents as the above embodiment one can refer to the above introduction, and the following will not be repeated. On this basis, please refer to Figure 4 Before step S100, steps A100-A300 can also be included:

[0087] Step A100, the running state information of the container is obtained according to the monitoring tool.

[0088] In this embodiment, the running state information is collected in real time or periodically by the monitoring tool, and the running state information includes but is not limited to performance indicators (such as CPU usage, memory occupation, disk I / O, etc.), user behavior data, system logs, etc. After collecting the data, the collected raw data is preprocessed such as data cleaning, filtering, normalization, etc. to remove possible noise, redundancy, and solve the problem of inconsistent formats. The preprocessing operation can ensure the accuracy and reliability of subsequent analysis.

[0089] Optionally, the monitoring tool can be Nagios, Zabbix, Prometheus, etc. Nagios can monitor the running status of various network devices, servers and applications. By installing Nagios Agent and configuring corresponding monitoring plugins (such as check_docker and check_kubernetes) in the container cluster, Nagios can monitor the status, resource utilization and health of Docker containers, as well as the status of nodes, Pods and services in the Kubernetes cluster. Prometheus can be used to monitor the dynamic environment of the container cluster, and real-time monitoring of various components in the cluster can be achieved through components such as Prometheus Operator.

[0090] Step A200, according to the preset abnormality detection rule, the running state information of the container is analyzed.

[0091] Step A300, when detecting that there is an abnormality, the alarm information is generated according to the running state information of the container.

[0092] In this embodiment, the preprocessed cloud state data is analyzed and calculated by using the preset rules, models or algorithms to detect abnormal conditions. The abnormality detection algorithm can be based on statistical methods (such as mean and standard deviation analysis), machine learning methods (such as supervised learning and unsupervised learning) or time series analysis methods, etc. After detecting the abnormal condition, the alarm information is generated according to the preset alarm rules and strategies. The alarm information can include the type, timestamp, severity level and possible fault location of the fault, etc.

[0093] Optionally, the mean and standard deviation analysis is used for abnormality detection. The mean and standard deviation of the data are calculated, and then a threshold is determined, and the data points exceeding this threshold are regarded as abnormal. Exemplarily, the 3sigma principle is adopted, that is, if the data points exceed the range (μ-3σ, μ+3σ), these points are regarded as abnormal points.

[0094] Optionally, the fault detection is based on the proximity method, which measures the distance between data points to detect abnormalities, such as k-nearest neighbor (k-NN) algorithm. The fault detection is based on clustering method, which divides the data into multiple clusters, and the abnormal points are usually located at the edge of the cluster or do not belong to any cluster, such as DBSCAN algorithm.

[0095] Optionally, the time series analysis method is used to detect the abnormality in the time series data. The outlier can be directly located for point anomaly. ARIMA, regression model, LSTM, etc. can also be used,

[0096] Learn a historical data, then predict the future value, and compare the deviation between the true value and the predicted value to determine whether it is abnormal.

[0097] Based on the first embodiment of the present application, in the third embodiment of the present application, the same or similar contents as the above embodiment one can refer to the above introduction, and the subsequent will not be described. On this basis, please refer to Figure 5 , the container fault analysis method further comprises steps S01-S02:

[0098] Step S01, obtain historical fault data, and label fault type and repair measures for the historical fault data to obtain a training set;

[0099] In this embodiment, the historical fault records of the container are collected from the log files, monitoring systems, and operation and maintenance records of the container. Ensure that the collected data contains the time, type, impact range, and repair measures of the fault. Clean and standardize the collected data to remove duplicate, invalid, or redundant information and ensure the consistency of the data format. Label the cleaned data with fault type, impact level, and repair measures. Assign one or more fault type labels to each fault record, which should accurately describe the nature of the fault, such as "memory leak", "disk space shortage", "network failure", etc. Impact level labels can evaluate the impact of each fault record on the system or business and assign appropriate labels, such as "minor", "moderate", "severe", etc. Help the model understand the importance of the fault and may affect the subsequent processing or response strategy. According to specific needs, other key information labels can also be added to the data, such as "occurrence time", "repair time", "repair measures", etc.

[0100] Step S02, training the large model according to the training set to obtain the target fault analysis model.

[0101] In this embodiment, according to the requirements of fault analysis, select a suitable model architecture, such as Transformer, BERT, CHATGPT, etc. Input the training set into the model, set appropriate training parameters such as learning rate, batch size, iteration number, etc. Select appropriate training strategies such as distributed training, gradient accumulation, etc. to improve training efficiency and model performance. After training is completed, the target fault analysis model is obtained.

[0102] Based on the first embodiment of the present application, in the fourth embodiment of the present application, the same or similar contents as the above embodiment one can refer to the above introduction, and the subsequent will not be described. On this basis, please refer to Figure 6 , step S300 further comprises steps S400-S500:

[0103] Step S400, the failure causes and the repair measures are classified according to the failure types.

[0104] Step S500, the classified failure causes and repair measures are input into a preset knowledge base, and the knowledge base is updated.

[0105] In this embodiment, the failure causes and repair measures output by the target failure analysis model are sorted, and the sorted information is classified according to dimensions such as failure type, equipment type, and cause classification, so as to facilitate subsequent retrieval and use. The classified information is input into the existing knowledge base, and the knowledge base is updated. After each update, a new version number is recorded, and the old version is retained. The version number can be used to track the updates and changes of the knowledge base.

[0106] In this embodiment, the failure causes and repair measures in the knowledge base are classified and sorted, so that the maintenance personnel can quickly locate the problem when facing a failure. The solutions in the knowledge base have been verified and practiced, and have high accuracy and reliability. The maintenance personnel can directly apply these solutions to improve the accuracy and efficiency of failure resolution.

[0107] Based on the first embodiment of the present application, in the fifth embodiment of the present application, the same or similar contents as the above embodiment one can refer to the above introduction, and the following will not be repeated. On this basis, please refer to Figure 7 , after step S300, steps B100-B300 are further included:

[0108] Step B100, determining the frequent failure area according to the failure history record;

[0109] In this embodiment, the failure history records in the past period of time are collected from the failure management system, log files, monitoring tools and other sources. The failure history records include failure type, occurrence time, impact range, repair process and other information. The collected failure data is sorted and classified, and is organized according to dimensions such as failure type and occurrence time, and is stored in a failure database or table. Through data analysis, the frequently occurring failure areas or components, and the main patterns and reasons of failure occurrence are identified. These frequently occurring failure areas or components are regarded as the key objects for monitoring.

[0110] Optionally, the occurrence frequency of different types of faults can be counted to identify which fault types are more common and the distribution of faults in different time periods (such as daily, weekly, monthly). Time series analysis and other methods can also be used to observe the trend of fault data over time and predict the possible development of future faults. Association rule analysis can also be performed to discover the association between different faults, such as the simultaneous occurrence or mutual triggering of certain faults. These fault areas or components with associations are also set with more stringent monitoring indicators.

[0111] Step B200, setting a monitoring indicator for the frequent fault area.

[0112] Step B300, triggering a warning prompt when the running state information of the frequent fault area is greater than or equal to the monitoring indicator.

[0113] In this embodiment, specific monitoring indicators are set for each key monitoring object, such as CPU usage, memory occupancy, response time, error rate, etc. A reasonable alarm threshold is set for each monitoring indicator. When the monitoring data exceeds the threshold, an alarm notification is triggered to promptly discover problems and take measures.

[0114] In this embodiment, the monitoring range can also be dynamically adjusted according to the running situation of the container and the analysis results of the fault history data. The areas or components that frequently appear faults are monitored more frequently and more carefully. When the real-time running data reaches the preset monitoring indicator threshold, the monitoring level is automatically adjusted, such as increasing the monitoring items, shortening the monitoring interval, etc.

[0115] In this embodiment, the monitoring range is dynamically adjusted according to the running situation of the container and the historical data of fault occurrence, and the areas or components that frequently appear faults are monitored. By analyzing the running situation of the container and the fault history data, the potential problem areas or components can be more accurately identified. The areas or components that frequently appear faults are monitored, which can quickly respond when faults occur and shorten the fault handling time. According to the changes of the monitoring focus, the allocation of monitoring resources is reasonably adjusted to ensure that the key areas and components are given enough monitoring resources. Avoiding resource waste, the limited monitoring resources are concentrated in the most needed place, improving the monitoring efficiency.

[0116] The present application provides a container fault analysis device, comprising: at least one processor; and a memory in communication connection with the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the container fault analysis method in Embodiment I.

[0117] The following refers to Figure 8 The diagram illustrates a structural schematic of a container fault analysis device suitable for implementing embodiments of this application. The container fault analysis device in this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Android Devices), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 8 The container failure analysis device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0118] like Figure 8 As shown, the container fault analysis device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.) that can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1002 or a program loaded from a storage device 1003 into a random access memory (RAM) 1004. The RAM 1004 also stores various programs and data required for the operation of the container fault analysis device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to the I / O interface 1006: input devices 1007 including, for example, a touchscreen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage devices 1003 including, for example, magnetic tape, hard disk, etc.; and communication devices 1009. Communication device 1009 allows the container failure analysis device to communicate wirelessly or wiredly with other devices to exchange data. While the figure shows a container failure analysis device with various systems, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0119] In particular, according to the embodiments disclosed in the present application, the process described above with reference to the flowchart can be implemented as a computer software program. For example, the embodiments disclosed in the present application include a computer program product comprising a computer program carried on a computer readable medium, the computer program containing program codes for executing the method shown in the flowchart. In such embodiments, the computer program can be downloaded and installed from a network through a communication device, or installed from the storage device 1003, or installed from the ROM 1002. When the computer program is executed by the processing device 1001, the above-mentioned functions defined in the method of the embodiments disclosed in the present application are executed.

[0120] The container fault analysis device provided by the present application adopts the container fault analysis method in the above-mentioned embodiments, and can solve the technical problem of how to improve the efficiency and accuracy of fault analysis in a containerized environment. Compared with the prior art, the beneficial effects of the container fault analysis device provided by the present application are the same as those of the container fault analysis method provided by the above-mentioned embodiments, and other technical features in the container fault analysis device are the same as those disclosed in the previous embodiment method, which will not be repeated here.

[0121] It should be understood that parts of the present application can be realized by hardware, software, firmware or a combination thereof. In the description of the above-mentioned embodiments, specific features, structures, materials or characteristics can be combined in any one or more embodiments or examples in a suitable manner.

[0122] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto, and any person skilled in the art can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be covered within the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.

[0123] The present application provides a computer readable storage medium having stored thereon computer readable program instructions (i.e. computer program) for executing the container fault analysis method in the above-mentioned embodiments.

[0124] The computer readable storage medium provided in the application may be, for example, a U disk, but is not limited to an electric, magnetic, optical, electromagnetic, infrared, or semiconductor system, system, or device, or any combination thereof. More specific examples of the computer readable storage medium may include, but are not limited to, an electric connection with one or more conductive wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof. In the embodiment, the computer readable storage medium may be any tangible medium containing or storing a program, which can be used by or in combination with an instruction execution system, system, or device. The program code contained on the computer readable storage medium can be transmitted by any suitable medium, including but not limited to an electric wire, an optical cable, an RF (Radio Frequency), and the like, or any suitable combination thereof.

[0125] The computer readable storage medium described above may be contained in the container fault analysis device, or may exist separately without being assembled into the container fault analysis device.

[0126] The computer readable storage medium described above carries one or more programs, which, when executed by the container fault analysis device, cause the container fault analysis device to: after obtaining the alarm information, determine a fault object according to the alarm information, and determine a downstream object of the fault object; obtain running state information of the fault object and running state information of the downstream object; input the running state information of the fault object and the running state information of the downstream object into a target fault analysis model to obtain a fault cause.

[0127] Computer program code for carrying out operations of the present application can be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code can execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection can be made to an external computer (for example, through the Internet using an Internet Service Provider).

[0128] The flow diagrams and the block diagrams in the drawings are illustrations of architectures, functionalities, and operations of possible implementations of systems, methods, and computer program products according to various embodiments of the present application. In this regard, each block in the flow diagrams or block diagrams can represent a module, a segment, or a portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that in some alternative implementations, the functions noted in the blocks can occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently or the blocks may

[0129] The modules involved in the embodiments of the present application can be implemented in the form of software or in the form of hardware. In some cases, the name of the module does not constitute a limitation on the module itself.

[0130] The readable storage medium provided by the present application is a computer readable storage medium, which stores computer readable program instructions (i.e. computer programs) for executing the container fault analysis method described above, and can solve the technical problem of how to improve the efficiency and accuracy of fault analysis in a containerized environment. Compared with the prior art, the computer readable storage medium provided by the present application has the same beneficial effects as the container fault analysis method provided by the above-mentioned embodiments, and will not be described here.

[0131] The above merely describes some embodiments of the present application, and does not limit the patent scope of the present application. Any equivalent structural transformation, direct / indirect application in other related technical fields, or the like, which is made based on the technical concept of the present application and the content of the specification and drawings, is included in the patent protection scope of the present application.

Claims

1. A method of container failure analysis, characterized by, The method comprises: obtaining running state information of a container according to a monitoring tool; analyzing the running state information of the container according to a preset abnormality detection rule; generating alarm information according to the running state information of the container when an abnormality is detected; determining a fault object and a downstream object of the fault object according to the alarm information after the alarm information is obtained; obtaining running state information of the fault object and running state information of the downstream object; inputting the running state information of the fault object and the running state information of the downstream object into a target fault analysis model to obtain a fault cause; determining a frequent fault area according to a fault history record; setting a monitoring index for the frequent fault area; triggering a pre-warning prompt when the running state information of the frequent fault area is greater than or equal to the monitoring index; the downstream object comprises a route, a service and a container group, and the step of determining the downstream object associated with the fault object comprises: when the fault object is the route, determining a downstream service of the route according to a route configuration file of the route; when the fault object is the service, determining a downstream container group of the service according to an IP address and a port list of the service; when the fault object is the container group, determining a label selector matched with the container group according to a label of the container group; determining a target controller corresponding to the container group according to the label selector.

2. The container failure analysis method according to claim 1, wherein the step of inputting the running state information of the fault object and the running state information of the downstream object into the target fault analysis model to obtain the fault cause comprises: sorting the running state information of the fault object according to an alarm level corresponding to the alarm information; inputting the running state information of the fault object and the running state information of the corresponding downstream object into the target fault analysis model according to the sorting result to obtain the fault cause and a repair measure.

3. The container failure analysis method according to claim 2, wherein the step of inputting the running state information of the fault object and the running state information of the downstream object into the target fault analysis model to obtain the fault cause further comprises: classifying the fault cause and the repair measure according to a fault type; inputting the classified fault cause and repair measure into a preset knowledge base to update the knowledge base.

4. The container failure analysis method according to Claim 1, characterized by, the method further comprises: obtaining historical fault data, and labeling a fault type and a repair measure of the historical fault data to obtain a training set; training a large model according to the training set to obtain the target fault analysis model.

5. A container failure analysis apparatus characterized by comprising: The device comprises a memory, a processor and a computer program stored on the memory and executable on the processor, and the computer program is configured to implement the steps of the container fault analysis method according to any one of claims 1 to 4.

6. A storage medium, characterized by The storage medium is a computer readable storage medium, and the storage medium stores a computer program, and the computer program is executed by the processor to implement the steps of the container fault analysis method according to any one of claims 1 to 4.

Images