Abnormal service management method and device, storage medium and electronic equipment

Abstract

The invention discloses an abnormal service management method and device, a storage medium and electronic equipment, and relates to the field of distributed technologies. The method comprises the following steps: detecting whether an abnormal cluster running an abnormal service exists in N clusters or not; when it is detected that an abnormal cluster exists in the N clusters, the fault type of an abnormal service running on the abnormal cluster is collected; the fault type of the abnormal service running on the abnormal cluster and the processing state information of the abnormal service are recorded on a target list, and the processing state information is used for representing whether the abnormal service is repaired or not; and according to the target list, detecting the abnormal service running on the abnormal cluster every preset duration, and updating the target list after determining that the abnormal service is recovered to normal. The technical problem of low efficiency of a service governance scheme in the prior art is solved.

Description

Technical Field

[0001] The present application relates to the field of distributed technology, and in particular to an abnormal service management method, device, storage medium and electronic device. Background Art

[0002] In a highly distributed service architecture, service governance faces multiple challenges, especially in environments involving multiple Zookeeper clusters. Traditional service governance solutions typically rely on simple monitoring and alerting mechanisms. Once a service anomaly is detected, such as a configuration error, unregistered service, or performance degradation, manual judgment and action are required to locate and fix the problem. However, this approach has significant efficiency shortcomings, especially when the number of services is large and widely distributed.

[0003] On the one hand, manually intervened governance processes often have slow response times and struggle to promptly handle a large number of concurrent failures, resulting in extended service recovery times and severely impacting business continuity and user experience. On the other hand, when similar anomalies occur in different Zookeeper clusters for the same service, traditional solutions generate duplicate alarms. This not only increases alarm redundancy but also makes it difficult for service maintainers to distinguish which issues truly require immediate attention, thereby reducing decision-making efficiency and wasting valuable maintenance resources. Furthermore, existing technologies rely on service maintainers to manually reply and confirm the status of issues. This process is not only inefficient but also prone to issues being missed due to human negligence, making it impossible to form effective closed-loop management.

[0004] To address the above-mentioned problems, no effective solutions have been proposed so far. Summary of the Invention

[0005] The present application provides an abnormal service management method, device, storage medium and electronic device to at least solve the technical problem of low efficiency of service governance solutions in the existing technology.

[0006] According to one aspect of the present application, a method for managing abnormal services is provided, including: detecting whether there is an abnormal cluster running an abnormal service among N clusters; when an abnormal cluster is detected among the N clusters, collecting the fault type of the abnormal service running on the abnormal cluster; recording the fault type of the abnormal service running on the abnormal cluster and processing status information of the abnormal service on a target list, wherein the processing status information is used to characterize whether the abnormal service has been repaired; detecting the abnormal service running on the abnormal cluster at a preset time interval according to the target list, and updating the target list after confirming that the abnormal service has returned to normal.

[0007] Optionally, the fault type of the abnormal service running on the abnormal cluster and the processing status information of the abnormal service are recorded in the target list, including: when there are M abnormal clusters in N clusters, all abnormal services corresponding to the M abnormal clusters are grouped into an abnormal service set, where M is greater than or equal to 1 and less than or equal to N; detecting whether there are services of the same service type in the abnormal service set; when it is detected that there are abnormal services of the same service type in the abnormal service set, detecting whether the fault types corresponding to the abnormal services of the same service type are the same, and obtaining a first detection result; based on the first detection result, the identification, fault type and processing status information of the abnormal service in the abnormal service set are recorded in the target list.

[0008] Optionally, after detecting whether there are services of the same service type in the abnormal service set, the method further includes: when it is detected that there are no abnormal services of the same service type in the abnormal service set, generating a fault record corresponding to the abnormal service based on the fault type corresponding to each abnormal service, wherein the number of fault records corresponding to each abnormal service is the same as the number of fault types corresponding to the abnormal service, and the fault record is the identification, fault type and processing status information of the abnormal service; and recording the fault record corresponding to each abnormal service on the target list.

[0009] Optionally, based on the first detection result, the identification, fault type and processing status information of the abnormal services in the abnormal service set are recorded in the target list, including: when, based on the first detection result, it is detected that the i-th abnormal service and the j-th abnormal service belong to the same service type, and the fault types corresponding to the i-th abnormal service and the j-th abnormal service are the same, the same fault record is generated based on the same fault type corresponding to the i-th abnormal service and the j-th abnormal service, wherein the i-th abnormal service and the j-th abnormal service are any two abnormal services in the abnormal service set, and the fault record is the identification, fault type and processing status information of the abnormal service; when, based on the first detection result, it is detected that the i-th abnormal service and the j-th abnormal service belong to the same service type, and the fault types corresponding to the i-th abnormal service and the j-th abnormal service are different, a fault record corresponding to the abnormal service is generated based on the fault type corresponding to the i-th abnormal service and the fault type corresponding to the j-th abnormal service, respectively.

[0010] Optionally, after recording the fault type of the abnormal service running on the abnormal cluster and the processing status information of the abnormal service in the target list, the method also includes: when it is detected that the target abnormal service is running on the xth abnormal cluster and the yth abnormal cluster at the same time, detecting whether the fault type corresponding to the target abnormal service on the xth abnormal cluster and the yth abnormal cluster is the same, wherein the target abnormal service is any abnormal service in the abnormal service set, wherein the xth abnormal cluster and the yth abnormal cluster are any two abnormal clusters in the M abnormal clusters; when it is detected that the fault type of the target abnormal service running on the xth abnormal cluster and the yth abnormal cluster is the same, detecting whether the fault type of the target abnormal service on the xth abnormal cluster and the yth abnormal cluster has been repaired; when it is detected that the fault type of the target abnormal service on the xth abnormal cluster and the yth abnormal cluster has been repaired, updating the processing status information of the fault type corresponding to the target abnormal service in the target list to repaired; when it is detected that the fault type of the target abnormal service on any one of the abnormal clusters of the xth abnormal cluster and the yth abnormal cluster has not been repaired, prohibiting the adjustment of the processing status information of the fault type corresponding to the target abnormal service in the target list.

[0011] Optionally, after detecting whether the fault types corresponding to the target abnormal services on the xth abnormal cluster and the yth abnormal cluster are the same, the method also includes: when detecting that the fault types of the target abnormal services running on the xth abnormal cluster and the yth abnormal cluster are different, respectively detecting whether the corresponding fault types of the target abnormal services running on the xth abnormal cluster and the yth abnormal cluster have been repaired; when detecting that the fault types corresponding to the target abnormal services running on the xth abnormal cluster and the yth abnormal cluster have been repaired, updating the processing status information of the fault types of the target abnormal services corresponding to the xth abnormal cluster and the yth abnormal cluster in the target list to repaired.

[0012] Optionally, the abnormal service management method also includes: predicting all services in N clusters based on the target model to obtain prediction results, wherein the target model is a prediction model obtained by training the initial model based on the historical abnormal service information of the N clusters, and the target model is used to predict abnormal problems existing in the service, wherein the historical abnormal service information includes the fault logs corresponding to the historical abnormal services; and generating prompt information based on the prediction results.

[0013] Optionally, the abnormal service management method also includes: determining the level information of the fault type corresponding to each abnormal service; sorting the records in the target list according to the level information of the fault type corresponding to each abnormal service, and generating different warning information for fault types with different level information.

[0014] According to another aspect of the present application, an abnormal service management device is also provided, including: a detection unit for detecting whether there is an abnormal cluster running an abnormal service among N clusters; a collection unit for collecting the fault type of the abnormal service running on the abnormal cluster when an abnormal cluster is detected among the N clusters; a recording unit for recording the fault type of the abnormal service running on the abnormal cluster and the processing status information of the abnormal service on a target list, wherein the processing status information is used to indicate whether the abnormal service has been repaired; an updating unit for detecting the abnormal service running on the abnormal cluster at a preset time interval according to the target list, and updating the target list after confirming that the abnormal service has returned to normal.

[0015] According to another aspect of the present application, a computer-readable storage medium is provided, which includes a stored executable program, wherein when the executable program runs, the device where the computer-readable storage medium is located is controlled to execute the above-mentioned abnormal service management method.

[0016] According to another aspect of the present application, an electronic device is also provided, comprising one or more processors and a memory, wherein the memory is used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors execute the above-mentioned abnormal service management method.

[0017] According to another aspect of an embodiment of the present application, a computer program product is further provided, comprising computer instructions, which implement the steps of the above-mentioned abnormal service management method when executed by a processor.

[0018] In this application, first, it is detected whether there is an abnormal cluster running an abnormal service among N clusters. When it is detected that there is an abnormal cluster among N clusters, the fault type of the abnormal service running on the abnormal cluster is collected, and then the fault type of the abnormal service running on the abnormal cluster and the processing status information of the abnormal service are recorded on the target list, wherein the processing status information is used to indicate whether the abnormal service has been repaired. Finally, the abnormal service running on the abnormal cluster is detected at each preset time interval according to the target list, and after confirming that the abnormal service has returned to normal, the target list is updated. That is, through closed-loop tracking and automated detection, the purpose of continuously monitoring and intelligently updating the abnormal service governance status is achieved, thereby achieving the technical effect of an efficient, accurate and automated service governance solution, thereby solving the technical problem of low efficiency of the service governance solution in the prior art. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0020] Figure 1 is a flowchart of an optional abnormal service management method according to an embodiment of the present application;

[0021] Figure 2 is a schematic diagram of an optional abnormal service management method according to an embodiment of the present application;

[0022] Figure 3 This is a schematic diagram of an optional abnormal service management device according to an embodiment of the present application. DETAILED DESCRIPTION

[0023] In order to enable those skilled in the art to better understand the present invention, the following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments in the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts should fall within the scope of protection of this application.

[0024] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequential order. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in a sequence other than those illustrated or described herein. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device comprising a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0025] It should be noted that the collected information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data for display, data for analysis, etc.) involved in this application are information and data authorized by the user or fully authorized by all parties, and the collection, storage, use, processing, transmission, provision, disclosure and application of the relevant data comply with relevant laws, regulations and standards, take necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation portals for users to choose to authorize or refuse. For example, an interface is set up between this system and relevant users or institutions to provide users with corresponding operation portals for users to choose to agree or refuse the automated decision-making results; if the user chooses to refuse, the expert decision-making process will be entered.

[0026] According to an embodiment of the present application, a method embodiment of an abnormal service management method is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0027] It should be noted that an intelligent processing system can be used as the execution subject of the abnormal service management method of the embodiment of the present application. It is understandable that the abnormal service management method provided in the embodiment of the present application can also be executed by other systems or devices, and the embodiment of the present application does not specifically limit this.

[0028] Figure 1 is a flow chart of an optional abnormal service management method according to an embodiment of the present application, such as Figure 1 As shown, the method includes the following steps:

[0029] Step S101 : Detect whether there is an abnormal cluster running an abnormal service among the N clusters.

[0030] Optionally, N clusters refer to multiple Zookeeper clusters (abbreviated as zk clusters), where N represents the number of clusters. N is an integer greater than 1, representing the number of environments that the system needs to monitor and manage simultaneously.

[0031] Optionally, an abnormal service refers to a service registered in the Zookeeper cluster that has an unexpected running status or has a specific problem.

[0032] Optionally, the abnormal cluster refers to a Zookeeper cluster where abnormal service operation is detected.

[0033] Optionally, the intelligent processing system proactively patrols N Zookeeper clusters to identify any services whose operating status deviates from normal ranges or has known violations. This detection helps identify potential problems early, preventing minor issues from becoming major failures and improving overall service stability and responsiveness.

[0034] Step S102 : When it is detected that there is an abnormal cluster among the N clusters, the fault type of the abnormal service running on the abnormal cluster is collected.

[0035] Optionally, fault type: specifies the type of problem exhibited by the abnormal service, such as configuration error, service unregistered, timeout, permission issue, etc., to facilitate subsequent targeted governance.

[0036] Optionally, if the intelligent processing system discovers abnormal services in one or more Zookeeper clusters, it will further collect detailed fault types for these abnormal services. This is done to better understand and classify the problems encountered, so as to take the most appropriate measures to address them and avoid blind processing and waste of resources.

[0037] Step S103: Record the fault type of the abnormal service running on the abnormal cluster and the processing status information of the abnormal service in the target list.

[0038] In step S103, the processing status information is used to indicate whether the abnormal service has been repaired.

[0039] Optionally, processing status information: indicates the governance progress of the current abnormal service, whether it has been repaired or is being repaired.

[0040] Optionally, the target list is a database or data structure that tracks the abnormal service governance process and is used to record key information such as problems to be solved and the current processing status.

[0041] Optionally, the fault type and handling status of abnormal services are recorded in the target list, forming a clear view that allows operations and development teams to quickly understand which services have problems, the nature of the problems, and the current progress of repairs. This not only improves transparency, but also facilitates team collaboration and priority decision-making, accelerating problem resolution.

[0042] Step S104 : detecting abnormal services running on the abnormal cluster at preset intervals according to the target list, and updating the target list after confirming that the abnormal services have returned to normal.

[0043] Optionally, the preset duration refers to the time interval at which the intelligent processing system rechecks the abnormal service status, which is usually a reasonable period set based on the importance of the service and the frequency of failures.

[0044] Optionally, during this phase, the intelligent processing system periodically returns to previously flagged anomaly clusters based on the records on the target list to recheck the latest status of those anomaly services. If the service is confirmed to have recovered from the failure, the system automatically updates the target list and removes the associated failure record, thus forming a closed-loop system. Conversely, if the service has not yet recovered, the record on the list remains unchanged, continuing to prompt relevant personnel for attention and action. This process ensures the continuity and effectiveness of problem management, reduces duplication of effort and human oversight, and achieves automated and intelligent service governance.

[0045] From the contents of steps S101 to S104, it can be seen that in this application, first, it is detected whether there is an abnormal cluster running an abnormal service in the N clusters. When it is detected that there is an abnormal cluster in the N clusters, the fault type of the abnormal service running on the abnormal cluster is collected, and then the fault type of the abnormal service running on the abnormal cluster and the processing status information of the abnormal service are recorded on the target list, wherein the processing status information is used to characterize whether the abnormal service has been repaired. Finally, the abnormal service running on the abnormal cluster is detected at each preset time interval according to the target list, and after confirming that the abnormal service has returned to normal, the target list is updated. That is, through closed-loop tracking and automated detection, the purpose of continuously monitoring and intelligently updating the abnormal service governance status is achieved, thereby achieving the technical effect of an efficient, accurate and automated service governance solution, thereby solving the technical problem of low efficiency of the service governance solution in the prior art.

[0046] In an optional embodiment, when there are M abnormal clusters in N clusters, the intelligent processing system organizes all abnormal services corresponding to the M abnormal clusters into an abnormal service set, where M is greater than or equal to 1 and less than or equal to N. Then, it is detected whether there are services of the same service type in the abnormal service set. When it is detected that there are abnormal services of the same service type in the abnormal service set, it is detected whether the fault types corresponding to the abnormal services of the same service type are the same, and a first detection result is obtained. Then, based on the first detection result, the identification, fault type and processing status information of the abnormal services in the abnormal service set are recorded in the target list.

[0047] Optionally, N clusters refers to the total number of Zookeeper clusters that the system needs to monitor; M abnormal clusters refers to the number of clusters with abnormal services among the N clusters, where M is an integer greater than or equal to 1 and less than or equal to N, representing the breadth of the problem environment; abnormal service set refers to the information of all abnormal services in the M abnormal clusters, which is aggregated into a set to facilitate subsequent unified analysis and processing.

[0048] Optionally, the same service type refers to services with the same name or function in the exception service set, which may be registered or run on different zookeeper clusters.

[0049] Optionally, after the intelligent processing system identifies M abnormal clusters in N Zookeeper clusters, the abnormal services corresponding to the identified M abnormal clusters are grouped into a set. Next, the intelligent processing system will analyze the abnormal service set to detect whether it contains services of the same service type. The purpose of this detection step is to identify whether there are multiple zk clusters running the same abnormal service in multiple zk environments. If services of the same service type are detected in the abnormal service set, the system will further analyze whether the fault types of these services are consistent. The first detection result generated by this process is crucial for subsequent governance actions. If the fault type is the same, then a unified repair measure can be taken; if the fault type is different, a specific governance plan needs to be formulated for each fault type. This improves the pertinence and efficiency of problem handling, avoids repeatedly generating alarms of the same fault type for the same service in different environments, and saves maintenance costs.

[0050] Optionally, based on the first detection result, the intelligent processing system records the identifier, fault type, and current processing status of each abnormal service in the abnormal service set in a target list. This is crucial because the target list not only provides a clear record of service governance but also provides foundational data for subsequent regular inspections and closed-loop operations. The target list effectively tracks the progress of service governance and ensures that all issues are promptly addressed and verified.

[0051] As can be seen from the above, the intelligent processing system achieves efficient, precise, and automated service governance through automated detection, problem aggregation and analysis, and closed-loop tracking strategies across multiple ZK environments. This solution significantly improves service governance efficiency, reduces duplication of effort, and ensures that issues with the same service type in different environments are not repeatedly reported. It also avoids over-reliance on service maintainers and reduces maintenance costs.

[0052] In an optional embodiment, when the intelligent processing system detects that there is no abnormal service of the same service type in the abnormal service set, it generates a fault record corresponding to the abnormal service based on the fault type corresponding to each abnormal service, wherein the number of fault records corresponding to each abnormal service is the same as the number of fault types corresponding to the abnormal service, and the fault record is the identification, fault type and processing status information of the abnormal service, and the fault record corresponding to each abnormal service is recorded in the target list.

[0053] Optionally, if the intelligent processing system finds that all abnormal services are of different types (i.e., there are no duplicate service type anomalies), for each abnormal service in the set, the system generates one or more fault records based on its unique fault type. Each record contains the unique identifier of the abnormal service, the fault type encountered, and the current processing status information. It is worth noting that the number of fault records for each abnormal service strictly corresponds to the number of its fault types, ensuring the detailed and accurate fault records.

[0054] Optionally, the fault record is not limited to the fault type but also includes the identifier of the abnormal service (such as service name, version, operating environment, etc.) and processing status information (such as whether the repair has started, the progress of the repair, whether the closed loop has been completed, etc.). This information is accurately recorded in the target list, which is a dynamically updated database or data structure used to track the governance status of all abnormal services, ensuring the integrity and traceability of the information.

[0055] From the above content, it can be seen that through the above implementation method, the intelligent processing system can carry out refined management of abnormal services, and each fault type of each service will be recorded and tracked separately, avoiding resource waste and management confusion caused by repeated fault types. At the same time, the establishment and updating of the target list ensures that the operation and maintenance team can grasp the latest progress of service governance in real time, and improve the efficiency of fault response and repair. Overall, this dependent claim significantly improves the accuracy and timeliness of service governance in a multi-zk environment through automated fault recording and tracking, realizes closed-loop automation and low-cost and high-efficiency of service governance, and effectively solves the problems of low efficiency and high dependence of service governance solutions in the existing technology.

[0056] In an optional embodiment, when the intelligent processing system detects, based on the first detection result, that the i-th abnormal service and the j-th abnormal service belong to services of the same service type, and the fault types corresponding to the i-th abnormal service and the j-th abnormal service are the same, the intelligent processing system generates the same fault record based on the same fault type corresponding to the i-th abnormal service and the j-th abnormal service, wherein the i-th abnormal service and the j-th abnormal service are any two abnormal services in the abnormal service set, and the fault record is the identifier, fault type and processing status information of the abnormal service; when the intelligent processing system detects, based on the first detection result, that the i-th abnormal service and the j-th abnormal service belong to services of the same service type, and the fault types corresponding to the i-th abnormal service and the j-th abnormal service are different, the fault record corresponding to the abnormal service is generated based on the fault type corresponding to the i-th abnormal service and the fault type corresponding to the j-th abnormal service, respectively.

[0057] Optionally, when the intelligent processing system analyzes the first detection result and finds that the i-th and j-th abnormal services (both of the same service type) have encountered the same fault type, the system will merge the fault information of these two services and generate a single fault record, rather than generating a separate record for each service. This avoids redundant fault records in the target list, reduces the identification and processing costs of the service maintainer, and improves the efficiency of problem management.

[0058] Optionally, if the first detection result finds that the i-th and j-th abnormal services are of the same type but have different fault types, the intelligent processing system will generate a corresponding fault record for each service. Each fault record contains the service identifier and specific fault type, as well as processing status information. This processing approach ensures that the specific issues of each service can be accurately identified and tracked. Even services of the same type can be independently managed based on their different issues, avoiding the incorrect "one-size-fits-all" governance strategy and improving the targeted and accurate problem solving.

[0059] As can be seen above, when an abnormal service is detected, the system intelligently distinguishes and merges services of the same service type and fault type, generating a unified fault record, reducing duplicate alerts and optimizing the problem handling process. Furthermore, for services with different fault types, even those belonging to the same service type, independent fault records are generated, ensuring that each issue is accurately tracked and efficiently resolved. This strategy not only reduces the burden on service maintainers and speeds up problem handling, but also enhances the intelligence of the entire service governance system, providing strong support for the stable operation of distributed systems.

[0060] In an optional embodiment, when the intelligent processing system detects that the target abnormal service is running on the xth abnormal cluster and the yth abnormal cluster at the same time, it detects whether the fault types corresponding to the target abnormal services on the xth abnormal cluster and the yth abnormal cluster are the same, wherein the target abnormal service is any abnormal service in the abnormal service set, wherein the xth abnormal cluster and the yth abnormal cluster are any two abnormal clusters in the M abnormal clusters; when it is detected that the fault types of the target abnormal services running on the xth abnormal cluster and the yth abnormal cluster are the same, it detects whether the fault types of the target abnormal services on the xth abnormal cluster and the yth abnormal cluster have been repaired; when it is detected that the fault types of the target abnormal services on the xth abnormal cluster and the yth abnormal cluster have been repaired, the processing status information of the fault type corresponding to the target abnormal service in the target list is updated to repaired; when it is detected that the fault type of the target abnormal service on any abnormal cluster of the xth abnormal cluster and the yth abnormal cluster has not been repaired, it is prohibited to adjust the processing status information of the fault type corresponding to the target abnormal service in the target list.

[0061] Optionally, once the intelligent processing system finds the same target abnormal service in the xth and yth abnormal clusters, it further compares the fault types of these services on the two clusters, that is, whether the problem is prevalent in different instances of the same service.

[0062] Optionally, if the same fault type is detected, the intelligent processing system will next check whether these faults have been fixed in both clusters. This is achieved by rescanning the cluster status and comparing the service's operating indicators. When the intelligent processing system confirms that the faults of the target abnormal service in both the xth abnormal cluster and the yth abnormal cluster have been fixed, it will mark the processing status information of the relevant service as "Fixed" in the target list. This not only means that the problem of the abnormal service has been completely resolved, but also marks a closed loop in the governance process. The system can stop tracking the problem and avoid unnecessary resource consumption. If the detection results show that the fault of the target abnormal service in at least one cluster still exists, the intelligent processing system will prevent the processing status information in the target list from being updated to "Fixed". This is done to ensure the rigor of the governance process, avoid global misjudgments due to incomplete resolution of problems in some clusters, and ensure the authenticity and integrity of service governance.

[0063] As can be seen from the above, the intelligent processing system significantly improves the efficiency and accuracy of service governance by meticulously comparing fault types and uniformly verifying repairs for the same target abnormal services across multiple clusters. This mechanism avoids duplicate governance actions and ineffective resource allocation. Furthermore, through automated detection and status updates, it ensures a closed-loop governance process, reducing the need for manual intervention and achieving more efficient, intelligent, and reliable service governance. Overall, this approach effectively addresses the issues of inconsistent and inefficient service governance in multi-ZK environments, providing powerful tool support for the operation and maintenance of distributed systems.

[0064] In an optional embodiment, when the intelligent processing system detects that the fault types of the target abnormal services running on the xth abnormal cluster and the yth abnormal cluster are different, it respectively detects whether the corresponding fault types of the target abnormal services running on the xth abnormal cluster and the yth abnormal cluster have been repaired; when it detects that the fault types corresponding to the target abnormal services running on the xth abnormal cluster and the yth abnormal cluster have been repaired, the processing status information of the fault types of the target abnormal services corresponding to the xth abnormal cluster and the yth abnormal cluster in the target list is updated to repaired.

[0065] Optionally, when the intelligent processing system detects that any target abnormal service is running in at least two abnormal clusters, it will detect whether the fault type corresponding to the target abnormal service on each abnormal cluster is the same. If different, each abnormal cluster running the target abnormal service will be detected separately, that is, it will detect whether the fault type corresponding to each abnormal cluster running the target abnormal service has been restored. If restored, the processing status information of the fault type of the target abnormal service corresponding to the abnormal cluster on the target list will be modified; and in the case where the fault type is the same, the processing status information of the fault type of the target abnormal service in the target list will be modified only when it is detected that the fault type corresponding to the target abnormal service in each of the multiple abnormal clusters involving the fault type corresponding to the target abnormal service has been restored.

[0066] Optionally, when the intelligent processing system detects that the fault types of the target abnormal service running on the xth abnormal cluster and the yth abnormal cluster are different, the system will independently check the target abnormal service in the xth and yth abnormal clusters to evaluate whether their respective fault types have been repaired. This process uses the system's built-in detection mechanism, which may include but is not limited to service status monitoring, log analysis, and performance indicator inspection to determine whether the service has returned to normal operation. Once the intelligent processing system confirms that the fault types of the target abnormal service on the xth and yth abnormal clusters have been repaired, it will immediately update the corresponding records in the target list and change the processing status information of the corresponding service faults on these two clusters to "repaired". This dynamic update mechanism ensures the real-time and accuracy of the list, allowing the operation and maintenance team to immediately understand the results of service governance and reduce unnecessary repeated inspections.

[0067] As can be seen from the preceding implementation, the intelligent processing system demonstrates the flexibility and precision of service governance across multiple environments. It not only identifies and distinguishes the unique failure types faced by the same service in different clusters, but also verifies the remediation of these failure types one by one, enabling precise control over the governance status of each abnormal service. This not only greatly improves the efficiency and accuracy of service governance, but also reduces operational costs by reducing ineffective or repetitive governance actions, ensuring the health and consistency of services across all cluster environments, and providing more stable and reliable operation for distributed systems.

[0068] In an optional embodiment, the intelligent processing system predicts all services in N clusters based on a target model to obtain a prediction result, wherein the target model is a prediction model obtained by training the initial model based on the historical abnormal service information of the N clusters, and the target model is used to predict abnormal problems existing in the service, wherein the historical abnormal service information includes the fault log corresponding to the historical abnormal service, and then generates prompt information based on the prediction result.

[0069] Optionally, a target model: This is a machine learning or data analysis model that is trained using historical abnormal service information from N zk clusters and can predict abnormal problems that may occur in current or future services.

[0070] Optionally, the intelligent processing system applies a target model, previously trained on a large amount of historical service anomaly information, to perform predictive analysis on all services in N ZooK clusters. This target model can identify potential risks in service operation and provide early warning of potential service anomalies, enabling the operations team to proactively prevent them and take preventative measures to reduce the likelihood of future failures. Once the prediction is complete, the intelligent processing system generates corresponding alerts for services with potential anomalies based on the prediction results. This information is then sent to the relevant operations and development teams, prompting them to intervene early to conduct necessary inspections and adjustments, preventing issues from escalating into actual failures.

[0071] As can be seen from the above, the intelligent processing system, by utilizing a target model trained on historical data, achieves forward-looking predictions of all service anomalies across N ZK clusters. This predictive capability helps the operations team identify potential risks in advance and implement preventative maintenance measures, significantly reducing production outages and customer impacts caused by unforeseen service anomalies. Furthermore, comprehensive predictions across all services reveal common system-level issues, providing data support for improving system architecture and optimizing service deployment. This approach not only improves service availability and stability, but also enhances the proactiveness and efficiency of the entire operations system.

[0072] In an optional embodiment, the intelligent processing system first determines the level information of the fault type corresponding to each abnormal service, then sorts the records in the target list according to the level information of the fault type corresponding to each abnormal service, and generates different warning information for fault types with different level information.

[0073] Optionally, after an abnormal service is detected and logged, the intelligent processing system evaluates the fault type level of each abnormal service. This process, based on pre-set fault type classification criteria, automatically identifies the fault's urgency and priority. For example, a complete service crash or data loss is classified as a "critical" fault, while configuration warnings or minor delays might be considered lower-level "normal" or "minor" faults. By clearly defining fault levels, the system can intelligently allocate resources to prioritize the most pressing issues.

[0074] Optionally, once the level information of the fault type is determined, the intelligent processing system will sort the records in the target list based on this information. The benefit of this is that when the service maintenance party views the target list, they will first see the problems that need to be handled most urgently. This sorting process enhances the practicality and guidance of the target list, and improves the efficiency and pertinence of problem handling. In addition to sorting, the intelligent processing system will also generate customized early warning information for fault types with different levels of information. For example, a "critical" fault may trigger the highest level of early warning, including immediate SMS or email notification, and may even initiate an automatic emergency response process; while a "minor" fault may only generate a low-level warning, which will be recorded in the log for later review. By generating differentiated early warnings, the system can notify the maintenance party in a timely and appropriate manner, avoid information overload, and ensure that the most important issues receive immediate attention and processing.

[0075] As can be seen from the above, the intelligent processing system, by introducing the concept of fault type and level information, achieves intelligent sorting of the target list and differentiated early warning, significantly improving the efficiency and accuracy of service governance. Through this series of steps, the intelligent processing system can not only quickly identify and prioritize the most serious issues, but also take appropriate response measures based on the urgency of different faults, avoiding waste of resources and time delays. In addition, the dynamic sorting mechanism of the target list allows maintenance parties to always focus on the service anomalies that need to be addressed most, thereby accelerating problem resolution, reducing the risk of service interruption, and improving overall service quality and user experience.

[0076] In an optional embodiment, Figure 2 is a schematic diagram of an optional abnormal service management method according to an embodiment of the present application, such as Figure 2 As shown, the system regularly traverses each ZooKeeper cluster to be remediated, scanning for violating services and their associated issues (fault types). Each ZooKeeper cluster outputs the offending services and their associated issues, which are then aggregated to create a target list. Issues for the same service across different ZooKeeper clusters are grouped into a single issue record. Issues requiring remediation are organized into a table (target list) based on the order [Service - Issue - Closed Loop (representing the processing status)] and corresponding tracking issues are generated. If unclosed tracking issues exist for the same issue for the same service in the table, they are not added to the table again. Subsequently, the system regularly checks each ZooKeeper environment to see if unclosed issues have been rectified. If they have been rectified across all ZooKeeper environments, the issue is considered closed. If not, the issue remains unclosed. Finally, service maintainers are urged to address unclosed issues, and projects with these issues face delivery or release delays.

[0077] Through this approach, generated issues can be tracked and closed. Generate issues are regularly checked for closure. Projects with governance issues cannot be delivered or released, making service governance mandatory and preventing the leakage of non-compliant services. The same violation issue for the same service in different ZooK environments will not be repeatedly generated, reducing governance costs for service maintainers. Furthermore, service maintainers do not need to manually respond to issues; they only need to correct the violation. Once the system detects that the issue has been corrected in all ZooK environments, the corresponding issue will be automatically closed.

[0078] The embodiment of the present application also provides an abnormal service management device. It should be noted that the abnormal service management device of the embodiment of the present application can be used to execute the abnormal service management method provided in the embodiment of the present application. The abnormal service management device provided in the embodiment of the present application is introduced below.

[0079] According to an embodiment of the present application, a device for implementing the above abnormal service management method is also provided. Figure 3 is a schematic diagram of an optional abnormal service management device according to an embodiment of the present application, such as Figure 3 As shown, the device includes: a detection unit 301, a collection unit 302, a recording unit 303 and an updating unit 304.

[0080] Optionally, the detection unit 301 is used to detect whether there is an abnormal cluster running an abnormal service among the N clusters; the collection unit 302 is used to collect the fault type of the abnormal service running on the abnormal cluster when it is detected that there is an abnormal cluster among the N clusters; the recording unit 303 is used to record the fault type of the abnormal service running on the abnormal cluster and the processing status information of the abnormal service on the target list, wherein the processing status information is used to indicate whether the abnormal service has been repaired; the updating unit 304 is used to detect the abnormal service running on the abnormal cluster at a preset time interval according to the target list, and update the target list after confirming that the abnormal service has returned to normal.

[0081] Optionally, the recording unit 303 includes: a first construction subunit, a first detection subunit, a second detection subunit, and a first recording subunit. The first construction subunit is used to, when there are M abnormal clusters in N clusters, group all abnormal services corresponding to the M abnormal clusters into an abnormal service set, where M is greater than or equal to 1 and less than or equal to N; the first detection subunit is used to detect whether there are services of the same service type in the abnormal service set; the second detection subunit is used to, when detecting that there are abnormal services of the same service type in the abnormal service set, detect whether the fault types corresponding to the abnormal services of the same service type are the same, and obtain a first detection result; the first recording subunit is used to record the identification, fault type, and processing status information of the abnormal services in the abnormal service set on the target list based on the first detection result.

[0082] Optionally, the abnormal service management device further includes: a first generating unit and a first recording unit. The first generating unit is configured to, upon detecting that an abnormal service of the same service type does not exist in the abnormal service set, generate a fault record corresponding to each abnormal service based on the fault type corresponding to the abnormal service, wherein the number of fault records corresponding to each abnormal service is the same as the number of fault types corresponding to the abnormal service, and the fault record includes an identifier of the abnormal service, a fault type, and processing status information; and the first recording unit is configured to record the fault record corresponding to each abnormal service in the target list.

[0083] Optionally, the first recording subunit includes: a first generating module and a second generating module. The first generating module is used to generate the same fault record based on the same fault type corresponding to the i-th abnormal service and the j-th abnormal service when it is detected based on the first detection result that the i-th abnormal service and the j-th abnormal service belong to the same service type, and the fault types corresponding to the i-th abnormal service and the j-th abnormal service are the same, wherein the i-th abnormal service and the j-th abnormal service are any two abnormal services in the abnormal service set, and the fault record is the identifier, fault type, and processing status information of the abnormal service; the second generating module is used to generate the fault record corresponding to the abnormal service based on the fault type corresponding to the i-th abnormal service and the fault type corresponding to the j-th abnormal service when it is detected based on the first detection result that the i-th abnormal service and the j-th abnormal service belong to the same service type, and the fault types corresponding to the i-th abnormal service and the j-th abnormal service are different.

[0084] Optionally, the abnormal service management device further includes: a first detection unit, a second detection unit, a first updating unit, and a first processing unit. Among them, the first detection unit is used to detect whether the fault types corresponding to the target abnormal services on the xth abnormal cluster and the yth abnormal cluster are the same when it is detected that the target abnormal service is running on the xth abnormal cluster and the yth abnormal cluster at the same time, wherein the target abnormal service is any abnormal service in the abnormal service set, and wherein the xth abnormal cluster and the yth abnormal cluster are any two abnormal clusters in the M abnormal clusters; the second detection unit is used to detect whether the fault types of the target abnormal services running on the xth abnormal cluster and the yth abnormal cluster have been repaired when it is detected that the fault types of the target abnormal services on the xth abnormal cluster and the yth abnormal cluster have been repaired; the first updating unit is used to update the processing status information of the fault type corresponding to the target abnormal service in the target list to repaired when it is detected that the fault types of the target abnormal service on the xth abnormal cluster and the yth abnormal cluster have been repaired; the first processing unit is used to prohibit adjusting the processing status information of the fault type corresponding to the target abnormal service in the target list when it is detected that the fault type of the target abnormal service on any abnormal cluster of the xth abnormal cluster and the yth abnormal cluster has not been repaired.

[0085] Optionally, the abnormal service management device further includes: a third detection unit and a second update unit. The third detection unit is configured to, upon detecting that the fault types of the target abnormal services running on the xth abnormal cluster and the yth abnormal cluster are different, respectively detect whether the corresponding fault types of the target abnormal services running on the xth abnormal cluster and the yth abnormal cluster have been repaired; and the second update unit is configured to, upon detecting that the fault types corresponding to the target abnormal services running on the xth abnormal cluster and the yth abnormal cluster have been repaired, update the processing status information of the fault types of the target abnormal services corresponding to the xth abnormal cluster and the yth abnormal cluster in the target list to "repaired."

[0086] Optionally, the abnormal service management device further includes: a prediction unit and a second generation unit. The prediction unit is configured to predict all services in N clusters based on a target model to obtain a prediction result, wherein the target model is a prediction model obtained by training an initial model based on historical abnormal service information of the N clusters, and the target model is used to predict abnormal problems existing in the service, wherein the historical abnormal service information includes fault logs corresponding to the historical abnormal services; and the second generation unit is configured to generate prompt information based on the prediction result.

[0087] Optionally, the abnormal service management device further includes: a determination unit and a second processing unit. The determination unit is configured to determine level information of the fault type corresponding to each abnormal service; the second processing unit is configured to sort the records in the target list according to the level information of the fault type corresponding to each abnormal service, and generate different warning information for fault types with different level information.

[0088] According to another aspect of the present application, a computer-readable storage medium is provided, which includes a stored executable program, wherein when the executable program runs, the device where the computer-readable storage medium is located is controlled to execute the above-mentioned abnormal service management method.

[0089] According to another aspect of the present application, an electronic device is also provided, comprising one or more processors and a memory, wherein the memory is used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors execute the above-mentioned abnormal service management method.

[0090] According to another aspect of an embodiment of the present application, a computer program product is further provided, comprising computer instructions, which implement the steps of the above-mentioned abnormal service management method when executed by a processor.

[0091] In the above embodiments of the present application, the description of each embodiment has its own focus. For parts that are not described in detail in a certain embodiment, please refer to the relevant description of other embodiments.

[0092] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. Among them, the device embodiments described above are only exemplary. For example, the division of the units can be a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of units or modules, which can be electrical or other forms.

[0093] The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple units. Some or all of the units may be selected according to actual needs to achieve the purpose of the present embodiment.

[0094] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0095] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions for enabling a computer device (which can be a personal computer, a server or a network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk or an optical disk.

[0096] The above is only a preferred embodiment of the present application. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present application. These improvements and modifications should also be regarded as the scope of protection of the present application.

Claims

1. A method for managing abnormal services, characterized in that: include: Detect whether there is an abnormal cluster running abnormal services among N clusters; When detecting that the abnormal cluster exists in the N clusters, collecting the fault type of the abnormal service running on the abnormal cluster; Recording the fault type of the abnormal service running on the abnormal cluster and processing status information of the abnormal service in the target list, wherein the processing status information is used to indicate whether the abnormal service has been repaired; The abnormal service running on the abnormal cluster is detected at preset intervals according to the target list, and the target list is updated after confirming that the abnormal service has returned to normal.

2. The abnormal service management method according to claim 1, characterized in that: Recording the fault type of the abnormal service running on the abnormal cluster and the processing status information of the abnormal service in the target list includes: In the case where there are M abnormal clusters among the N clusters, all abnormal services corresponding to the M abnormal clusters are grouped into an abnormal service set, where M is greater than or equal to 1 and less than or equal to N; Detecting whether there is a service of the same service type in the abnormal service set; When detecting that abnormal services of the same service type exist in the abnormal service set, detecting whether the fault types corresponding to the abnormal services of the same service type are the same, and obtaining a first detection result; Based on the first detection result, the identifier, fault type, and processing status information of the abnormal service in the abnormal service set are recorded in the target list.

3. The abnormal service management method according to claim 2, characterized in that: After detecting whether there is a service of the same service type in the abnormal service set, the method further includes: When it is detected that there is no abnormal service of the same service type in the abnormal service set, a fault record corresponding to each abnormal service is generated according to the fault type corresponding to the abnormal service, wherein the number of fault records corresponding to each abnormal service is the same as the number of fault types corresponding to the abnormal service, and the fault record includes the identifier of the abnormal service, the fault type, and the processing status information; The fault record corresponding to each abnormal service is recorded in the target list.

4. The abnormal service management method according to claim 2, characterized in that: Based on the first detection result, recording the identifier, fault type, and processing status information of the abnormal service in the abnormal service set on the target list includes: If, based on the first detection result, it is detected that the i-th abnormal service and the j-th abnormal service belong to the same service type, and the fault types corresponding to the i-th abnormal service and the j-th abnormal service are the same, a same fault record is generated based on the same fault type corresponding to the i-th abnormal service and the j-th abnormal service, wherein the i-th abnormal service and the j-th abnormal service are any two abnormal services in the abnormal service set, and the fault record includes an identifier, a fault type, and processing status information of the abnormal service; When, based on the first detection result, it is detected that the i-th abnormal service and the j-th abnormal service belong to services of the same service type, and the fault types corresponding to the i-th abnormal service and the j-th abnormal service are different, a fault record corresponding to the abnormal service is generated based on the fault type corresponding to the i-th abnormal service and the fault type corresponding to the j-th abnormal service, respectively.

5. The abnormal service management method according to claim 2, characterized in that: After recording the fault type of the abnormal service running on the abnormal cluster and the processing status information of the abnormal service in the target list, the method further includes: When it is detected that the target abnormal service is running on the xth abnormal cluster and the yth abnormal cluster at the same time, detecting whether the fault types corresponding to the target abnormal service on the xth abnormal cluster and the yth abnormal cluster are the same, wherein the target abnormal service is any abnormal service in the abnormal service set, and wherein the xth abnormal cluster and the yth abnormal cluster are any two abnormal clusters in the M abnormal clusters; When it is detected that the fault types of the target abnormal service running on the xth abnormal cluster and the yth abnormal cluster are the same, detecting whether the fault types of the target abnormal service on the xth abnormal cluster and the yth abnormal cluster have been repaired; When it is detected that the fault types of the target abnormal service on the xth abnormal cluster and the yth abnormal cluster have been repaired, updating the processing status information of the fault type corresponding to the target abnormal service in the target list to repaired; When it is detected that the fault type of the target abnormal service in any one of the xth abnormal cluster and the yth abnormal cluster is not repaired, it is prohibited to adjust the processing status information of the fault type corresponding to the target abnormal service in the target list.

6. The abnormal service management method according to claim 5, characterized in that: After detecting whether the fault types corresponding to the target abnormal services in the xth abnormal cluster and the yth abnormal cluster are the same, the method further includes: When it is detected that the fault types of the target abnormal service running on the xth abnormal cluster and the yth abnormal cluster are different, detecting whether the corresponding fault types of the target abnormal service running on the xth abnormal cluster and the yth abnormal cluster have been repaired respectively; When it is detected that the fault types corresponding to the target abnormal services running on the xth abnormal cluster and the yth abnormal cluster have been repaired, the processing status information of the fault types of the target abnormal services corresponding to the xth abnormal cluster and the yth abnormal cluster in the target list is updated to repaired.

7. The abnormal service management method according to claim 1, characterized in that: The method further comprises: Predicting all services in the N clusters based on a target model to obtain a prediction result, wherein the target model is a prediction model obtained by training an initial model based on historical abnormal service information of the N clusters, and the target model is used to predict abnormal problems existing in the services, wherein the historical abnormal service information includes fault logs corresponding to historical abnormal services; Prompt information is generated according to the prediction result.

8. The abnormal service management method according to claim 1, characterized in that: The method further comprises: Determine the level information of the fault type corresponding to each abnormal service; The records in the target list are sorted according to the level information of the fault type corresponding to each abnormal service, and different warning information is generated for fault types with different level information.

9. An abnormal service management device, characterized in that: include: A detection unit, configured to detect whether there is an abnormal cluster running abnormal services among the N clusters; a collecting unit, configured to, when detecting that the abnormal cluster exists in the N clusters, collect a fault type of an abnormal service running on the abnormal cluster; a recording unit, configured to record the fault type of the abnormal service running on the abnormal cluster and processing status information of the abnormal service in a target list, wherein the processing status information is used to indicate whether the abnormal service has been repaired; An updating unit is configured to detect abnormal services running on the abnormal cluster at preset intervals according to the target list, and update the target list after confirming that the abnormal services have returned to normal.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, wherein when the computer program is executed, the device where the computer-readable storage medium is located executes the abnormal service management method according to any one of claims 1 to 8.

11. An electronic device, characterized in that: It includes one or more processors and a memory, wherein the memory is used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors execute the abnormal service management method described in any one of claims 1 to 8.

12. A computer program product comprising computer instructions, characterized in that When the computer instructions are executed by a processor, the steps of the abnormal service management method according to any one of claims 1 to 8 are implemented.

Images