Cloud service alarm method, electronic device, storage medium and computer program product

Abstract

The present disclosure provides a cloud service alarm method, an electronic device, a storage medium and a computer program product. The cloud service alarm method comprises: determining initial alarm information on the basis of service anomaly information appearing in a cloud platform, wherein the initial alarm information comprises an alarm type and an alarm reason corresponding to the service anomaly information; selecting, from a plurality of pieces of initial alarm information, alarm information to be selected that has an alarm reason meeting an alarm selection rule; and merging the alarm information to be selected that has the same alarm reason to generate target alarm information for prompting a user. The technical solution of the present disclosure can improve the degree of confidence of alarm information, and can reduce the frequency of alarm prompts without affecting the handling of cloud platform service anomalies.

Description

[0001] Cloud Service Alarm Method, Electronic Device, Storage Medium, and Computer Program Product This disclosure claims priority to a Chinese patent application filed with the China Patent Office on February 7, 2024, application number 202410175680. 4. The entire contents of this application are incorporated herein by reference. Technical Field This disclosure relates to the field of data processing technology, and more particularly to a cloud service alarm method, electronic device, storage medium, and computer program product. Background: For microservice-based cloud platforms, traditional cloud platform monitoring systems can only generate alarms based on abnormal information generated by a single microservice. However, as cloud platforms mature, current cloud platforms now include thousands or even more microservices, with complex dependencies between them. Consequently, the same fault may trigger alarms from multiple microservices, resulting in an alarm storm and hindering the rapid and efficient processing of alarms. SUMMARY OF THE INVENTION Embodiments of the present disclosure provide a cloud service alarm method, electronic device, storage medium, and computer program product to alleviate or resolve one or more technical problems existing in the prior art. In a first aspect, embodiments of the present disclosure provide a cloud service alarm method, comprising: determining initial alarm information based on service anomaly information occurring on a cloud platform, wherein the initial alarm information includes the alarm type and alarm cause corresponding to the service anomaly information; screening, from multiple initial alarm information, candidate alarm information whose alarm causes meet alarm screening rules; and merging candidate alarm information with the same alarm cause to generate a target alarm information for prompting a user. In a second aspect, embodiments of the present disclosure provide an electronic device comprising a memory, a processor, and a computer program stored in the memory, wherein the processor, when executing the computer program, implements the method described in any one of the embodiments of the present disclosure. In a third aspect, embodiments of the present disclosure provide a computer-readable storage medium, wherein the computer program is stored therein, and wherein the computer program, when executed by the processor, implements the method described in any one of the embodiments of the present disclosure. In a fourth aspect, an embodiment of the present disclosure provides a computer program product, including a computer program, which implements any method of the embodiments of the present disclosure when executed by a processor.According to the cloud service alarm method provided by the embodiments of the present disclosure, service anomaly information from microservices in a cloud platform is processed to obtain the corresponding alarm type and cause. Subsequently, the alarm is filtered and consolidated based on alarm screening and merging rules. This further verifies the alarm information based on cloud platform monitoring data, improving the confidence of the ultimately displayed alarm information. Furthermore, the merging of alarm information reduces the frequency of alarm prompts without affecting the handling of cloud platform service anomalies, thus avoiding the formation of alarm storms and enabling fast and efficient handling of service anomalies in the cloud platform. Optionally, the technical solutions of the embodiments of the present disclosure can also utilize natural language models to determine the alarm type and cause, eliminating the need for operations and maintenance personnel to manually determine the alarm type and cause of service anomaly information from alarm documents one by one. This further improves the confidence and generation efficiency of the alarm information, facilitates fast and efficient handling of service anomalies in the cloud platform, and enhances the user experience of cloud platform users. The above description is merely an overview of the technical solutions of the present disclosure. To provide a clearer understanding of the technical solutions of the present disclosure, implementation may be carried out in accordance with the contents of this specification. To further enhance the understanding of the above and other objectives, features, and advantages of the present disclosure, specific embodiments of the present disclosure are described below. In the accompanying drawings, unless otherwise specified, identical reference numerals throughout the various figures denote identical or similar components or elements. The drawings are not necessarily drawn to scale. It should be understood that these drawings depict only some embodiments of the present disclosure and should not be construed as limiting the scope of the present disclosure. Figure 1 is a system flow chart of an application scenario of an embodiment of the present disclosure; Figure 2 is a flow chart of a cloud service alarm method according to an embodiment of the present disclosure; Figure 3 is a schematic diagram of a cloud service alarm device according to an embodiment of the present disclosure; and Figure 4 is a block diagram of an electronic device for implementing an embodiment of the present disclosure. DETAILED DESCRIPTION OF THE EMBODIMENTS The following briefly describes certain exemplary embodiments. As will be appreciated by those skilled in the art, the described embodiments may be modified in various ways without departing from the spirit or scope of the present disclosure. Therefore, the drawings and description are to be regarded as illustrative in nature and not restrictive. To facilitate understanding of the technical solutions of the embodiments of the present disclosure, the following describes related technologies of the embodiments of the present disclosure. The following related technologies are optional solutions that can be combined with the technical solutions of the embodiments of the present disclosure in any manner, and all of them fall within the scope of protection of the embodiments of the present disclosure.In traditional cloud platform monitoring systems, alarm event generation is often based on fixed alarm rules. However, with the development of cloud platforms, the increasing number of components has led to a significant increase in the complexity of cloud platforms. The original alarm event generation algorithm cannot adapt to complex business scenarios and changing alarm conditions, and is prone to false positives and missed alarms. Especially in the microservice scenario of cloud platforms, the dependencies between microservices are becoming increasingly complex. Taking proprietary cloud platforms as an example, there are as many as tens of thousands of raw alarm indicators. It is difficult to complete the merging and processing of these raw alarms relying on traditional manpower. As a result, the same fault may trigger alarms in multiple microservices, resulting in an alarm storm phenomenon, which is not conducive to the fast and efficient processing of alarms. Furthermore, due to the different developers of microservices within a cloud platform, the styles and forms of alerts from different microservices may differ. Operations and maintenance personnel often need to consult the alert documentation associated with the monitoring system and, based on their experience, determine the alert type and cause corresponding to each microservice's service anomaly information. However, with the increasing number of microservices, relying solely on manual queries makes it difficult to promptly and accurately determine the alert type and cause. To address this, embodiments of the present disclosure provide a cloud service alert solution that can be used within a cloud platform monitoring system. This solution processes service anomaly information from microservices within the cloud platform to determine the corresponding alert type and cause. Subsequently, based on alert screening and merging rules, the service anomaly information from each microservice within the cloud platform is processed and integrated, ultimately generating alert information for cloud platform operations and maintenance personnel. Figure 1 is a system flow diagram for an application scenario of embodiments of the present disclosure, illustrating the complete process of a cloud platform monitoring system from acquiring monitoring data within the cloud platform to generating alert information. As shown in Figure 1, the cloud platform monitoring system can periodically monitor the cloud platform to obtain various monitoring data. This monitoring data can include hardware device status information, application status information, and network traffic information. The processed data includes service status information for each microservice on the cloud platform. The monitoring system can analyze and process service anomaly information in this service status information to generate alarm events for each microservice on the cloud platform. Specifically, the cloud platform monitoring system's processing of service anomaly information for each microservice generally involves three stages:

[0002] (1) Initial Alarm Phase During the initial alarm phase, unlike traditional operations and maintenance personnel who determine the alarm type and alarm cause corresponding to service anomaly information by reading alarm documents, the disclosed embodiment can use a natural language model (NLP) to annotate the service anomaly information of each microservice in the cloud platform, thereby automatically generating the alarm type and alarm cause based on the natural language model. A natural language model refers to a deep learning model trained using a large amount of text data. It can generate natural language text or understand the meaning of language text, and handle various natural language tasks such as text classification, question-answering, and dialogue. It is an important technical means in the field of artificial intelligence technology. Specifically, service anomaly information and alarm documents can be input into a natural language model. The alarm document includes a mapping between service anomaly information, alarm type, and alarm cause. The natural language model can use semantic judgment to classify the service anomaly information and associate it with the alarm type and cause. The model then outputs the alarm type and cause corresponding to the service anomaly information as initial alarm information, or processes the output of the natural language model to obtain the alarm type and cause as initial alarm information. The alarm type refers to the classification of the alarm event triggered by the service anomaly information, which can assist operations and maintenance personnel in determining fault handling. For example, the alarm type can indicate whether the alarm event is hardware-related, software-related, or related to an abnormality in a control node or worker node. The alarm cause refers to the specific cause or condition that generated the service anomaly information, such as a hardware device temperature exceeding a threshold or an application's concurrent request count exceeding a threshold.

[0003] (2) Alarm Screening Phase It is understandable that for different microservices, due to the possibility of inconsistent developers, the abnormality judgment criteria for service anomalies may be different, and calculation and analysis errors are inevitable in the process of processing monitoring data to obtain service anomaly information. Therefore, not all service anomaly information needs to be generated as an alarm event and notified to the operation and maintenance personnel for processing. The initial alarm information generated in the initial alarm phase needs to be screened. In the embodiment of the present disclosure, the cloud platform monitoring system will pre-configure alarm screening rules and screen the initial alarm information according to the alarm screening rules. For example, in the alarm screening phase, the monitoring data collected by the cloud platform monitoring system can be periodically obtained, and the monitoring data can be semantically parsed using a natural language model. The working status of each component and each microservice in the cloud platform can be judged based on the semantic parsing results.

[0004] (3) During the alarm integration phase, it is understood that the service anomaly information of a microservice only indicates that the working status of a microservice in the cloud platform has become abnormal during a certain monitoring cycle. During the normal operation of the cloud platform, calculation errors may occasionally occur, causing individual microservices to work abnormally for a short period of time. In other words, not all filtered initial alarm information needs to be notified to the operation and maintenance personnel immediately for processing. Therefore, during the alarm integration phase, alarm merging rules can be pre-configured to merge the initial alarm information to form a target alarm information including multiple initial alarm information, and use the target alarm information to prompt the operation and maintenance personnel to handle the fault. For example, the alarm merging rule can include the number of candidate alarm information with the same alarm cause exceeding a threshold within a preset time period. For example, for candidate alarm information with the alarm cause being authentication service anomaly, the alarm merging rule can be that the number of candidate alarm information with the alarm cause being authentication service anomaly exceeds 5 within 30 seconds. In this case, the alarm merging rule is triggered to merge these candidate alarm information with the alarm cause being authentication service anomaly to form the target alarm information. For example, the target alarm information includes the microservices and microservice anomaly information corresponding to each candidate alarm, as well as the alarm type, so that operations and maintenance personnel can quickly understand the severity of the alarm anomaly based on the target alarm information, determine the root cause of the problem based on the alarm type, and determine subsequent solutions. Based on this, the cloud service alarm method of the disclosed embodiments is applied to a cloud service alarm system. By processing service anomaly information from microservices in a cloud platform, the corresponding alarm types and causes are obtained. Subsequent screening and consolidation based on alarm screening and merging rules can reduce the frequency of alarm prompts and avoid the formation of alarm storms. Furthermore, a natural language model can be used to process service anomaly information from microservices in a cloud service to obtain the corresponding alarm types and causes. This eliminates the need for operations and maintenance personnel to manually determine the alarm types and causes of service anomaly information from alarm documents one by one, allowing for rapid and efficient handling of service anomalies in the cloud platform. In addition, the initial alarm information determined by the natural language model based on service anomaly information will be filtered and integrated based on alarm screening rules and alarm merging rules. On the one hand, the alarm information is further verified based on the monitoring data of the cloud platform, improving the confidence of the alarm information finally displayed. On the other hand, unlike the traditional method of prompting all service anomaly information one by one, this solution merges the alarm information after screening and verification based on the alarm merging rules. This reduces the frequency of alarm prompts without affecting the handling of cloud platform service anomalies, and can more clearly display the alarm information that needs to be handled to operation and maintenance personnel.Optionally, since the service operation of a cloud platform is also affected by operating periods, such as peak or off-peak periods, and certain short-term and frequent service anomalies require more timely detection and root cause analysis to more quickly resolve the problem and ensure a better user experience, the alarm screening rules and alarm merging rules used in the alarm screening and alarm integration stages in the embodiments of the present disclosure can also be dynamically adjusted using an intelligent rule engine trained through manual annotation. For example, based on historical alarm information from the cloud platform monitoring system, cloud platform monitoring data, and the cloud platform's corresponding service knowledge base, the time threshold for triggering alarm merging or the threshold for the number of selected alarm information in the alarm merging rules can be periodically adjusted. This allows adaptive adjustment of alarm processing rules based on the cloud platform's real-time environment and historical alarm conditions, thereby enhancing the adaptability of the monitoring system and enabling it to handle constantly changing monitoring data. It should be noted that the above-mentioned application scenarios or application examples of the cloud service alarm method provided in the embodiments of the present disclosure are provided for ease of understanding, and the embodiments of the present disclosure do not specifically limit the application of the cloud service alarm method. The following detailed description uses specific embodiments to explain the technical solutions of the present disclosure and how they solve the aforementioned technical problems. The specific embodiments listed above may be combined with one another, and identical or similar concepts or processes may not be described in detail in certain embodiments. Figure 2 shows a flow chart of a cloud service alarm method according to an embodiment of the present disclosure. This cloud service alarm method can be applied to a cloud service alarm device and a cloud platform monitoring system. As shown in Figure 2, the cloud service alarm method may include the following: Step S201: Determining initial alarm information based on service anomaly information generated on the cloud platform, where the initial alarm information includes the alarm type and alarm cause corresponding to the service anomaly information. The embodiments of the present disclosure do not limit the electronic components included in the cloud platform; these components may be determined based on actual circumstances. For example, the cloud platform may include multiple cloud hosts, multiple cloud storage devices, etc. At least one service or microservice runs on the cloud platform, such as an authentication service, a user microservice, an order microservice, a message microservice, or an advertising microservice. For example, service exception information refers to an abnormal situation occurring in a node of a service or microservice in the cloud platform. It can be directly reflected in text form by the monitoring data monitored by the cloud platform monitoring system, such as access interface failure, connection abnormality, etc., or it can be reflected in other pre-defined forms such as codes or numbers, such as abnormal 200 error, abnormal 500 error, etc.Detailed explanations of Exception 200 and Exception 500 errors can be documented by the developers of each service or microservice in the corresponding alarm documentation. When a corresponding exception error occurs, users can query the alarm documentation to identify and determine the specific issue corresponding to the service exception information. The alarm type categorizes the alarm event triggered by the service exception information, helping operations and maintenance personnel determine how to handle the fault. For example, the alarm type can indicate whether the alarm event is hardware-related or software-related, or an abnormality in a control node or working node. The alarm cause refers to the specific cause or condition that generated the service exception information, such as a hardware device temperature exceeding a threshold or an application's concurrent request count exceeding a threshold. Step S202: Filter out candidate alarm information from multiple initial alarm messages, selecting alarms whose causes meet the alarm screening criteria. The alarm screening rules corresponding to a microservice may include whether the operating status of the microservice, determined based on monitoring data during the alarm screening phase, matches the service anomaly information of the microservice in the initial alarm information. For example, the initial alarm information generated during the initial alarm phase may indicate that the alarm cause corresponding to a certain service anomaly information is server A operating abnormally. However, during the alarm screening phase, the monitoring data is analyzed and determined to indicate that server A is operating normally. In this case, the initial alarm information is excluded during the alarm screening phase, and the operating status of server A is further determined based on subsequent cloud platform monitoring data to determine whether an alarm for the service anomaly information is required. Exemplarily, different alarm screening rules can be set for different microservices and stored in an alarm rule library. Upon receiving service anomaly information for any microservice, the alarm screening rule corresponding to the microservice can be searched in the alarm rule library, and the service anomaly information of the microservice can be filtered using the corresponding alarm screening rule, thereby selecting candidate alarm information from the initial alarm information for subsequent processing. Exemplarily, the alarm screening rules can be pre-configured by the user based on the service status of the cloud platform. For example, since the service exception prompting patterns of cloud platform components corresponding to different microservices are relatively fixed, for example, if the CPU utilization of a cloud server exceeds 80%, a service exception message will be triggered. However, in reality, the role of this service exception message is only to remind rather than requiring operation and maintenance personnel to detect and handle it. In this case, users can configure the cloud server. Table 1 illustrates the difference between the natural language model's processing of service exception information in the disclosed embodiment and traditional manual methods. As shown in Table 1, both microservices 1 and 2 experience service exceptions. The service exception information for microservice 1 is "Exception 500 Error," while the service exception information for microservice 2 is "Access Interface Failure." Traditional manual methods require manual search of the alarm documents for microservices 1 and 2 for the corresponding service exception information and determine the cause. However, the natural language model can collect the contents of the alarm documents corresponding to microservices 1 and 2 from a database. After learning to identify the alarm document content, it identifies and processes the service exception information for microservices 1 and 2, annotating the corresponding alarm type and cause for each service exception information. Using the method of this embodiment, operations and maintenance personnel no longer need to manually determine the alarm type and cause of each service exception information from alarm documents. Instead, the natural language model can be used to process service exception information from microservices in the cloud service, obtaining the corresponding alarm type and cause, enabling fast and efficient handling of service exceptions in the cloud platform. In one embodiment, the cloud service alarm method of the disclosed embodiment may further include: obtaining current and historical monitoring data of the cloud platform; wherein the monitoring data includes at least one of hardware device status information, application status information, and network traffic information; and adjusting alarm screening rules based on changes in the current monitoring data compared to the historical monitoring data. Multiple monitoring indicators for the cloud platform may be preset, and changes in each monitoring data may be determined based on the current and historical monitoring data of the cloud platform as changes in the monitoring indicators, and the alarm screening rules may be adjusted based on the changes in the monitoring indicators. The monitoring indicators of the cloud platform include, but are not limited to, server CPU utilization, memory utilization, and the hardware resources required for the operation of various microservices in the cloud platform. For example, if the alarm screening rule for a cloud server includes CPU utilization exceeding 80% and lasting for more than 5 minutes, but if analysis of the monitoring indicators determines that the cloud platform is in a peak operating period, the alarm screening rule can be adaptively adjusted to CPU utilization exceeding 90% and lasting for more than 5 minutes to avoid excessive invalid alarms during peak periods. Alternatively, the adaptive adjustment of the alarm screening rule can also be to change the duration threshold of the abnormal service status, for example, adjusting the alarm screening rule to CPU utilization exceeding 80% and lasting for more than 10 minutes. This configuration can be based on actual conditions and is not specifically limited here.In one embodiment, in step S203, merging the candidate alarm information with the same alarm cause may include merging the candidate alarm information with the same alarm cause according to an alarm merging rule. As an example, the alarm merging rule may include merging the candidate alarm information with the same alarm cause in response to the number of candidate alarm information with the same alarm cause exceeding a threshold within a preset time period. For example, if the preset time period is 5 minutes and the threshold number of candidate alarm information is set to 10, and the number of candidate alarm information with the alarm cause being the number of concurrent requests of application B exceeding the rated load is less than 10 within 5 minutes, this indicates that application B experienced very little overload during the preset time period. The cloud platform monitoring system allows for a certain degree of overload operation, and there is no need to generate an alarm for such candidate alarm information. Therefore, the alarm merging rule will not be triggered to merge the less than 10 candidate alarm information of this type. As another example, an alarm merging rule may include merging candidate alarm information with the same alarm cause and an abnormality level exceeding a preset level. For example, the alarm cause of the candidate alarm information is excessive temperature of hardware device C. The triggering condition for generating the candidate alarm information may be that the temperature of hardware device C exceeds 60 degrees Celsius. However, in the alarm merging rule, the user can categorize the abnormality levels of alarms caused by the temperature of hardware device C. For example, a temperature exceeding 100 degrees Celsius is classified as "very severe," a temperature exceeding 80 degrees Celsius is classified as "relatively severe," and a temperature exceeding 60 degrees Celsius is classified as "moderately severe." The alarm merging rule may specify that when the temperature reaches "very severe," a target alarm is immediately generated; when the temperature reaches "relatively severe" but does not meet the "very severe" standard and persists for more than 30 seconds, a target alarm is generated; and when the temperature reaches "moderately severe" but does not meet the "relatively severe" standard and persists for more than 60 seconds, a target alarm is generated. As another example, the alarm merging rule may include merging the candidate alarm information with the same alarm cause if the number of consecutive alarms exceeds a preset number. For example, if the candidate alarm information with the alarm cause being an authentication service anomaly appears three times consecutively, the alarm information is merged to form the target alarm information.It is understood that the three different alarm merging rules described above can be applied independently to a specific alarm cause, or they can be used together to generate target alarm information for the same alarm cause. For example, the alarm merging rule may be that three consecutive occurrences of candidate alarm information for authentication service anomalies, and the number of candidate alarm information for authentication service anomalies occurring within a preset time period exceeds a threshold, triggering alarm merging. Furthermore, the definition of the three alarm merging rules in the embodiments of this disclosure is merely intended to better explain the process of generating target alarm information for user notification based on candidate alarm information. In actual applications, the alarm merging rules can be configured and modified as needed, and this disclosure is not limited thereto. In one embodiment, the alarm merging rules can be periodically adjusted based on the cloud platform's current monitoring data, historical alarm information, and the cloud platform's corresponding service knowledge base. It is understandable that the cloud platform monitoring system needs to more promptly detect and analyze the root causes of certain short-term and frequent service anomalies to more quickly resolve the issues and ensure a better user experience. Alarm merging rules also need to be adaptively adjusted based on the cloud platform's real-time environment and historical alarm information. Historical alarm information can be alarm information that the cloud platform monitoring system has issued to users within a certain historical period. In one embodiment, the method may further include periodically adjusting at least one of a quantity threshold, a preset level, and a preset number of times based on the cloud platform's current monitoring data, historical alarm information, and a service knowledge base. Taking adjusting the number threshold as an example, for example, consider a candidate alarm whose cause is "Application B's concurrent requests exceed the rated load." If, within the past week, the alarm has been generated dozens of times, this clearly indicates a serious problem that has not been effectively resolved and requires priority attention. In this case, the threshold for the number of candidate alarms in the alarm merging rule corresponding to this alarm cause can be optimized and adjusted from 10 to 8. This will enable more timely detection of frequent problems and facilitate timely resolution by operations and maintenance personnel. In addition to adjusting the threshold for the number of candidate alarms in the alarm merging rule corresponding to this alarm cause, the detection time threshold in the alarm merging rule corresponding to this alarm cause can also be adjusted.Taking the candidate alarm information whose alarm cause is that the number of concurrent requests of application B exceeds the rated load as an example, if the cloud platform's current monitoring data detects that the cloud platform is currently operating at peak capacity, it is clear that the overload of various applications will increase. In this case, the preset time period can be adjusted to 2 minutes. Only if more than 10 candidate alarm information with the alarm cause being that the number of concurrent requests of application B exceeds the rated load is generated within 2 minutes will the alarm merging rule be triggered to merge the information into the target alarm information. This avoids excessive alarming during peak cloud platform operating periods. It is understood that the adaptive adjustment of the detection time threshold and the threshold for the number of candidate alarm information can be performed separately or jointly, for example, adjusting both the detection time and the threshold for the number of candidate alarm information. The specific adjustment can be determined based on actual conditions and is not limited in this disclosure. Taking the example of adjusting the preset severity, when the cloud platform is detected to be at peak operation, the alarm merging rules can be optimized and adjusted, including appropriately increasing the duration of "relatively severe" and "moderately severe" temperatures. For example, when the temperature reaches the "relatively severe" standard but does not meet the "very severe" standard and lasts for more than 40 seconds, a target alarm message is generated. When the temperature reaches the "moderately severe" standard but does not meet the "relatively severe" standard and lasts for more than 80 seconds, a target alarm message is generated. Taking the example of adjusting the preset number of times, when historical alarm information determines that the number of authentication service anomalies within the past month exceeds the preset number, the alarm merging rules can be optimized and adjusted to reduce the threshold for the number of consecutive alarms triggered by authentication service anomalies. For example, if three consecutive occurrences of candidate alarm messages with the cause of the alarm being authentication service anomalies were previously used for alarm merging, the threshold can be adaptively adjusted to two consecutive occurrences of candidate alarm messages with the cause of the alarm being authentication service anomalies for alarm merging. In one embodiment, the target alarm information may include the service name and service exception information, alarm type, etc. corresponding to each candidate alarm information, so that operation and maintenance personnel can quickly understand the abnormality level of the alarm based on the target alarm information, determine the root cause of the problem based on the alarm type, and determine subsequent solutions.For example, in the embodiments of the present disclosure, the adjustment of alarm screening rules and alarm merging rules can be dynamically adjusted by an intelligent rule engine trained through manual annotation. This allows the trained intelligent rule engine to combine historical alarm information from the cloud platform monitoring system, cloud platform monitoring data, and the cloud platform's corresponding service knowledge base, using maximum likelihood estimation to determine the most appropriate parameters and periodically adjust the thresholds in the alarm screening rules and alarm merging rules. This allows adaptive adjustment of alarm processing rules based on the cloud platform's real-time environment and historical alarm conditions, thereby enhancing the adaptability of the monitoring system and enabling it to handle constantly changing monitoring data. In one embodiment, the cloud service alarm method may further include: collecting monitoring data from the cloud platform, where the monitoring data includes at least one of hardware device status information, application status information, and network traffic information; and preprocessing the monitoring data to generate service anomaly information. It is understandable that the monitoring data collected by the monitoring system merely represents the operating parameters of various devices or programs on the cloud platform. These operating parameters need to be analyzed to generate service anomaly information, facilitating the subsequent determination of target alarm information based on the service anomaly information. Preprocessing of the monitoring data includes, but is not limited to, data cleaning and conversion. The target alarm information can be delivered in various formats, including, but not limited to, SMS, phone calls, emails, and light alarm outputs. Based on the technical solutions of the disclosed embodiments, service anomaly information from microservices on the cloud platform is processed to obtain the corresponding alarm type and cause. This information is then filtered and consolidated based on alarm screening and merging rules. This further verifies the alarm information based on the cloud platform's monitoring data, improving the confidence level of the ultimately displayed alarm information. Furthermore, the merging of alarm information reduces the frequency of alarm prompts without affecting the handling of cloud platform service anomalies, preventing the formation of alarm storms and enabling rapid and efficient handling of service anomalies on the cloud platform. Furthermore, natural language models can be used to process service anomaly information from microservices within cloud services. This eliminates the need for operations and maintenance personnel to manually determine the alarm type and cause of each service anomaly from alarm documents. This further improves the confidence level and generation efficiency of alarm information, facilitates rapid and efficient handling of service anomalies within the cloud platform, and enhances the user experience of cloud platform users. Another beneficial effect of the technical solution of the disclosed embodiments is that a trained intelligent rule engine can be used to adaptively adjust alarm screening and merging rules. This allows for adaptive adjustment of alarm processing rules based on the cloud platform's real-time environment and historical alarm conditions, enhancing the adaptability of the monitoring system and enabling it to handle ever-changing monitoring data.Corresponding to the application scenario provided by the embodiment of the present disclosure and the method of embodiment 1, the embodiment of the present disclosure also provides a cloud service alarm device 300. oThe cloud service alarm device 300 may include: an initial alarm module 301 for determining initial alarm information based on service anomaly information generated on the cloud platform, wherein the initial alarm information includes the alarm type and alarm cause corresponding to the service anomaly information; a screening module 302 for screening, from multiple initial alarm information, candidate alarm information whose alarm causes meet alarm screening criteria; and a merging module 303 for merging candidate alarm information with the same alarm cause to generate a target alarm message for prompting a user. In one embodiment, the initial alarm module 301 is specifically configured to: input service anomaly information and an alarm document into a natural language model, wherein the alarm document includes mappings between multiple service anomaly information, multiple alarm types, and multiple alarm causes; and obtain the initial alarm information based on the output of the natural language model. In one embodiment, the cloud service alarm device 300 may further include: a data acquisition module for acquiring current and historical monitoring data of the cloud platform; wherein the monitoring data includes at least one of hardware device status information, application status information, and network traffic information; and a rule adjustment module for adjusting alarm screening rules based on changes in current monitoring data compared to historical monitoring data. In one embodiment, the merging module 303 is specifically configured to merge candidate alarm information with the same alarm cause according to an alarm merging rule, wherein the alarm merging rule includes at least one of the following: merging candidate alarm information with the same alarm cause in response to the number of candidate alarm information with the same alarm cause exceeding a quantity threshold within a preset time period; merging candidate alarm information with the same alarm cause whose abnormality exceeds a preset degree; and merging candidate alarm information with the same alarm cause in response to the number of consecutive alarms exceeding a preset number. In one embodiment, the alarm merging rules are periodically adjusted based on the cloud platform's current monitoring data, historical alarm information, and the cloud platform's corresponding service knowledge base. In one embodiment, the rule adjustment module is further configured to periodically adjust at least one of the quantity threshold, the preset level, and the preset number of times based on the cloud platform's current monitoring data, the historical alarm information, and the service knowledge base. In one embodiment, the cloud service alarm device 300 may further include a preprocessing module configured to preprocess the monitoring data and generate service anomaly information. The functions of each module in each device of the disclosed embodiment can be found in the corresponding description of the method above, and they possess corresponding beneficial effects, so they are not further described here. Figure 4 is a block diagram of an electronic device used to implement the disclosed embodiment.As shown in FIG4 , the electronic device includes a memory 401 and a processor 402. The memory 401 stores a computer program executable on the processor 402. When the processor 402 executes the computer program, the method described in the above embodiment is implemented. The memory 401 and the processor 402 may be one or more. The electronic device also includes a communication interface 403 for communicating with external devices and exchanging data. If the memory 401, the processor 402, and the communication interface 403 are implemented independently, the memory 401, the processor 402, and the communication interface 403 may be interconnected via a bus to enable communication between them. The bus may be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus. The bus may be divided into an address bus, a data bus, a control bus, and the like. For ease of illustration, Figure 4 shows only one thick line, but this does not indicate that there is only one bus or only one type of bus. Optionally, in a specific implementation, if memory 401, processor 402, and communication interface 403 are integrated on a single chip, memory 401, processor 402, and communication interface 403 can communicate with each other through an internal interface. Embodiments of the present disclosure provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the methods provided in the embodiments of the present disclosure. Embodiments of the present disclosure provide a computer program product including a computer program that, when executed by a processor, implements the methods provided in the embodiments of the present disclosure. Embodiments of the present disclosure also provide a chip including a processor configured to retrieve and execute instructions stored in a memory, thereby enabling a communication device equipped with the chip to perform the methods provided in the embodiments of the present disclosure. Embodiments of the present disclosure also provide a chip including an input interface, an output interface, a processor, and a memory. The input interface, the output interface, the processor, and the memory are connected via an internal connection path. The processor is configured to execute code in the memory. When the code is executed, the processor performs the methods provided in the embodiments of the present disclosure.It should be understood that the processor may be a CPU, or other general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), an FPGA, or other programmable logic device, a discrete gate or transistor logic device, or a discrete hardware component. A general-purpose processor may be a microprocessor or any conventional processor. It is worth noting that the processor may be a processor supporting the Advanced Reduced Instruction Set Machine (ARM) architecture. Furthermore, optionally, the memory may include a read-only memory and a random access memory. The memory may be a volatile memory or a non-volatile memory, or may include both volatile and non-volatile memory. Non-volatile memory may include read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory may include random access memory (RAM), which serves as an external cache. By way of example and not limitation, many forms of RAM are available. For example, static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM), and direct RAM RAM (DR RAM). In the above embodiments, all or part of them can be implemented by software, hardware, firmware, or any combination thereof.When implemented using software, it can be implemented in whole or in part in the form of a computer program product. A computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the processes or functions according to the present disclosure are fully or partially generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another. It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, storage, and display, etc.) involved in this disclosure are all information and data authorized by the user or fully authorized by all parties. The collection, use, and processing of relevant data must comply with the relevant laws, regulations, and standards of the relevant countries and regions, and corresponding operation portals are provided for users to select or edit authorization or rejection. In the description of this disclosure, reference to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples" means that the specific features, structures, materials, or characteristics described in conjunction with that embodiment or example are included in at least one embodiment or example of this disclosure. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples. Furthermore, those skilled in the art may combine and integrate different embodiments or examples described in this disclosure, as well as features from different embodiments or examples, unless otherwise specified. Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed to indicate or imply relative importance or implicitly specify the number of technical features indicated. Therefore, features specified as "first" or "second" may explicitly or implicitly include at least one of those features. In the description of this disclosure, "plurality" means two or more, unless otherwise specifically defined. Any process or method described in a flowchart or otherwise herein can be understood to represent a module, segment, or portion of code comprising one or more executable instructions for implementing the steps of a specific logical function or process. Furthermore, the scope of the preferred embodiments of the present disclosure includes alternative implementations in which functions may be performed out of the order shown or discussed, including performing functions substantially simultaneously or in reverse order depending on the functions involved.The logic and / or steps described in the flowcharts or otherwise described herein can, for example, be considered a sequenced list of executable instructions for implementing logical functions and can be embodied in any computer-readable medium for use by an instruction execution system, apparatus, or device (e.g., a computer-based system, a system including a processor, or other system that can fetch and execute instructions from an instruction execution system, apparatus, or device), or in conjunction with such an instruction execution system, apparatus, or device. It should be understood that various aspects of the present disclosure can be implemented using hardware, software, firmware, or a combination thereof. In the above-described embodiments, multiple steps or methods can be implemented using software or firmware stored in a memory and executed by a suitable instruction execution system. All or part of the steps of the above-described method embodiments can be performed by a program that instructs the relevant hardware. The program can be stored in a computer-readable storage medium. When executed, the program includes one or a combination of the steps of the method embodiments. Furthermore, the functional units in the various embodiments of the present disclosure can be integrated into a single processing module, each unit can exist physically separately, or two or more units can be integrated into a single module. The above-mentioned integrated modules can be implemented in either hardware or software functional modules. If implemented as software functional modules and sold or used as independent products, the integrated modules can also be stored in a computer-readable storage medium. This storage medium can be a read-only memory, a magnetic disk, or an optical disk. The above description is merely an exemplary embodiment of the present disclosure, but the scope of protection of the present disclosure is not limited thereto. Anyone skilled in the art can easily conceive of various variations and substitutions within the technical scope of the present disclosure, and such variations and substitutions are intended to be encompassed by the scope of protection of the present disclosure. Therefore, the scope of protection of the present disclosure shall be subject to the scope of protection of the claims.

Claims

Claims 1. A cloud service alarm method, comprising: Initial alarm information is determined based on service anomaly information appearing in the cloud platform, wherein the initial alarm information includes an alarm type and an alarm cause corresponding to the service anomaly information; candidate alarm information whose alarm type and alarm cause meet alarm screening rules is screened out from multiple pieces of the initial alarm information; and candidate alarm information with the same alarm cause is merged to generate target alarm information for prompting a user.

2. The method according to claim 1, wherein: Determining initial alarm information based on service anomaly information occurring in a cloud platform includes: inputting the service anomaly information and an alarm document into a natural language model, wherein the alarm document includes mapping relationships between multiple service anomaly information, multiple alarm types, and multiple alarm causes; and obtaining the initial alarm information based on an output result of the natural language model.

3. The method according to claim 1 or 2, further comprising: Obtain current monitoring data and historical monitoring data of the cloud platform; wherein the monitoring data includes at least one of hardware device status information, application status information, and network traffic information; and adjust the alarm screening rules based on changes in the current monitoring data compared to the historical monitoring data.

4. The method according to any one of claims 1 to 3, wherein the merging of candidate alarm information with the same alarm cause comprises: The candidate alarm information with the same alarm cause is merged and processed according to the alarm merging rule, wherein the alarm merging rule includes at least one of the following: in response to the number of candidate alarm information with the same alarm cause exceeding a quantity threshold within a preset time period, the candidate alarm information with the same alarm cause is merged; the candidate alarm information with the same alarm cause and the abnormality degree of the alarm cause exceeding a preset degree is merged; in response to the number of consecutive alarms of the candidate alarm information with the same alarm cause exceeding a preset number, the candidate alarm information with the same alarm cause is merged.

5. The method according to claim 4, wherein: The alarm merging rules are periodically adjusted based on the current monitoring data of the cloud platform, historical alarm information, and the service knowledge base corresponding to the cloud platform.

6. The method according to claim 5, further comprising: Based on the current monitoring data of the cloud platform, the historical alarm information, and the service knowledge base, at least one of the quantity threshold, the preset degree, and the preset number of times is periodically adjusted.

7. The method according to any one of claims 1 to 6, further comprising: Collecting monitoring data of the cloud platform, wherein the monitoring data includes at least one of hardware device status information, application status information, and network traffic information; and preprocessing the monitoring data to generate the service exception information.

8. An electronic device, comprising a memory, a processor, and a computer program stored in the memory, wherein the processor implements the method according to any one of claims 1 to 7 when executing the computer program.

9. A computer-readable storage medium, wherein a computer program is stored in the computer-readable storage medium, and when the computer program is executed by a processor, the method according to any one of claims 1 to 7 is implemented.

10. A computer program product, comprising a computer program, wherein when executed by a processor, the computer program implements the method according to any one of claims 1 to 7.

Images