Alarm root cause processing method and device, medium and computer program product

Abstract

The invention relates to an alarm root cause processing method. The method comprises the steps of receiving an identifier of a target alarm; acquiring context event data from a plurality of heterogeneous data sources based on the identifier of the target alarm and a predetermined analysis time range; performing multi-stage preprocessing on the context event data to generate high-fidelity context data, the multi-stage preprocessing comprising: grouping and aggregating event data of a predetermined type to associate discrete punctiform event data into composite event data with a service meaning; selecting a corresponding prompt word template from a plurality of preset prompt word templates based on the alarm type of the target alarm; injecting the high-fidelity context data into a selected cue word template to construct an input cue word; and inputting the input prompt word into the large language model, and obtaining a structured root cause analysis report from the large language model. The invention also relates to an alarm root cause processing device, a medium and a computer program product.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to alarm root cause processing methods, devices, media, and computer program products. Background Technology

[0002] With the acceleration of enterprise digital transformation, the scale and complexity of information technology systems have increased dramatically. In modern distributed system architectures, business systems consist of numerous microservices and infrastructure components with close dependencies between them. To ensure system stability, operations teams deploy various monitoring tools to collect system operational status data and generate alerts when metrics are abnormal. However, these monitoring tools often generate massive amounts of alarm information from diverse sources and containing significant noise, leaving operations engineers overwhelmed by a sea of ​​information when facing faults, making it difficult to handle them quickly and effectively.

[0003] In current technological practices, processing these alarm messages presents numerous challenges. First, alarms, changes, and releases are often scattered across different tools and platforms, creating data silos and lacking effective correlation mechanisms, making it difficult for operations personnel to construct clear fault propagation chains. Second, traditional alarm handling methods rely heavily on simple rules based on keyword matching or fixed thresholds, which struggle to handle complex fault scenarios, resulting in a large number of irrelevant alarms creating noise interference and drowning out truly critical signals. Finally, root cause analysis heavily depends on the personal experience of senior engineers and their deep understanding of the system architecture. This approach is not only inefficient and difficult to scale, but also prevents effective knowledge accumulation and reuse, prolonging the mean time to repair faults. Although some solutions have attempted to utilize large language models and other technologies for analysis in recent years, directly inputting raw, disorganized monitoring data often leads to misleading conclusions due to low information quality. Summary of the Invention

[0004] The purpose of this invention is to provide alarm root cause processing methods, devices, media, and computer program products to solve the technical problem of how to effectively integrate and process massive, heterogeneous, and high-noise multi-source alarm and event data in order to achieve automated and accurate fault root cause localization.

[0005] The first embodiment of the present invention discloses an alarm root cause processing method, comprising:

[0006] The identifier for receiving target alarms;

[0007] Based on the identifier of the target alarm and the predetermined analysis time range, context event data is obtained from multiple heterogeneous data sources;

[0008] The context event data is preprocessed in multiple stages to generate high-fidelity context data. The multi-stage preprocessing includes: grouping and aggregating event data of a predetermined type to associate discrete point-like event data into composite event data with business meaning.

[0009] Based on the alarm type of the target alarm, select a corresponding prompt word template from multiple pre-defined prompt word templates;

[0010] The high-fidelity context data is injected into the selected prompt word template to construct input prompt words;

[0011] The input prompts are fed into a large language model, and a structured root cause analysis report is obtained from the large language model.

[0012] A second embodiment of the present invention discloses an electronic device, the electronic device including a memory storing computer-executable instructions and a processor, wherein when the instructions are executed by the processor, the electronic device implements the alarm root cause processing method according to the first embodiment of the present invention.

[0013] A third embodiment of the present invention discloses a computer storage medium storing instructions that, when executed on a computer, cause the computer to perform an alarm root cause processing method according to a first embodiment of the present invention.

[0014] A fourth embodiment of the present invention discloses a computer program product including computer-executable instructions, which are executed by a processor to implement an alarm root cause processing method according to a first embodiment of the present invention.

[0015] The main differences and effects of the embodiments of the present invention compared with the prior art are as follows:

[0016] In this invention, the process involves receiving the identifier of a target alarm; acquiring contextual event data from multiple heterogeneous data sources based on the target alarm identifier and a predetermined analysis time range; performing multi-stage preprocessing on the contextual event data to generate high-fidelity contextual data. This multi-stage preprocessing includes: grouping and aggregating event data of predetermined types to associate discrete point-like event data into composite event data with business meaning; selecting a corresponding prompt word template from multiple predetermined prompt word templates based on the alarm type of the target alarm; injecting the high-fidelity contextual data into the selected prompt word template to construct input prompt words; inputting the input prompt words into a large language model; and obtaining a structured root cause analysis report from the large language model. This achieves full automation from receiving alarms to generating root cause analysis reports. It deeply integrates multi-source heterogeneous data, extracts high-fidelity analysis materials through multi-stage intelligent preprocessing, and uses advanced dynamic prompt word engineering technology to guide the large language model in accurate root cause inference. It not only solves the pain points of data silos, noise interference, and over-reliance on human experience in traditional operation and maintenance, but also improves the speed and accuracy of fault location, providing efficient and reliable technical support for ensuring the stability of complex systems. Attached Figure Description

[0017] Figure 1 A flowchart illustrating an alarm root cause processing method according to an embodiment of this application is shown.

[0018] Figure 2 A schematic diagram illustrating data aggregation and normalization processing according to an embodiment of this application is shown.

[0019] Figure 3 A schematic diagram of a data preprocessing pipeline according to an embodiment of this application is shown.

[0020] Figure 4 A flowchart illustrating the prompt word construction and interaction with a large language model according to an embodiment of this application is shown.

[0021] Figure 5 A hardware block diagram of an electronic device for alarm root cause processing according to an embodiment of this application is shown. Detailed Implementation

[0022] In existing operational practices, alarm and event management has become a core challenge in ensuring system stability in the face of increasingly complex business systems. When a system failure occurs, operations engineers typically receive massive amounts of heterogeneous and noisy alarm information. Quickly filtering out relevant information, constructing a clear fault propagation chain, and locating the root cause from this information is extremely difficult and time-consuming. Existing technical solutions often suffer from problems such as information overload, isolated and scattered alarm events, and heavy reliance on expert experience, leading to extended mean time to repair (MTBT) and making it difficult to meet the high availability requirements of modern distributed systems.

[0023] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0024] To address the aforementioned technical problems, embodiments of this application provide an alarm root cause processing method, aiming to automate and intelligentize alarm analysis and improve the efficiency and accuracy of root cause localization. Figure 1 A flowchart of an alarm root cause processing method according to an embodiment of this application is shown. This method can be applied to electronic devices such as servers, computer terminals, or cloud computing platforms. The steps include:

[0025] S101, the identifier for receiving target alarms.

[0026] For example, in a specific application scenario, an operations engineer discovers an alarm that requires in-depth root cause analysis. This step can be triggered automatically, such as when a high-priority alarm is generated by the monitoring system; or it can be triggered manually, such as when the operations engineer selects a specific alarm and starts the analysis process through the user interface of the operations platform.

[0027] In this embodiment, a specific scenario will be used as Example A for detailed explanation. Suppose that in the operation and maintenance scenario of an e-commerce platform, the monitoring system generates an alarm with the subject "API response timed out for retrieving shopping cart details". The operations engineer receives this alarm and wants to find the root cause of the API timeout. At this time, the system receives the unique identifier of the target alarm, such as span_id: 716847f24000145c, and the analysis time range preset by the operations engineer or the system, for example, based on the alarm trigger time 2025-09-17 11:14:50, tracing back 15 minutes and forward 5 minutes.

[0028] S102, based on the target alarm identifier and the predetermined analysis time range, obtains context event data from multiple heterogeneous data sources.

[0029] Upon receiving the identifier of the target alarm, the system uses this alarm as an "anchor" and concurrently initiates query requests to multiple pre-configured, heterogeneous data sources within the time range defined in S101 to automatically aggregate all possible contextual information related to the alarm. This process breaks down the barriers of data silos and the need for manual cross-platform troubleshooting in traditional operations and maintenance.

[0030] Continuing with Example A, the system will automatically query various data sources using the alarm identifier span_id: 716847f24000145c and its time range. For example... Figure 2The diagram illustrating data aggregation and normalization shows that the system pulls data from multiple heterogeneous data sources 202 based on user input 201, and then performs data aggregation and correlation 203. For example, it queries the Platform as a Service (PaaS) monitoring system for KubePodUnhealthy alerts related to the promotion-engine service associated with the shopping cart service; it queries the Infrastructure as a Service (IaaS) monitoring system for Ping Latency High network latency alerts in the Hedan IDC data center, as well as RedisBgsave and Redis FullReplSync alerts related to the Redis cluster rsc-pcm-pcm-new that the promotion-engine service depends on; and it queries the application change management system for whether there were any related service releases or configuration change events within that time period. In this way, the system constructs a panoramic, cross-level data view around the target alerts.

[0031] S103, perform multi-stage preprocessing on context event data to generate high-fidelity context data. The multi-stage preprocessing includes: grouping and aggregating event data of a predetermined type to associate discrete point-like event data into composite event data with business meaning.

[0032] Directly using raw, unprocessed data from multiple data sources for analysis not only consumes significant computational resources but also easily leads to misjudgments in the analytical model. Therefore, this application designs a multi-stage, high-fidelity data preprocessing pipeline, such as... Figure 3 As shown. This pipeline aims to refine the normalized event list 301 to remove noise, identify patterns, eliminate known interference, and ultimately generate a highly condensed, accurate core contextual data.

[0033] A core component of this preprocessing pipeline is event aggregation and association (S303, grouping aggregation). The system aggregates specific types of events, associating a series of scattered, low-level point events into a linear or surface-like composite event with a clear business meaning.

[0034] In Example A's scenario, assuming the promotion-engine service underwent a release process within the analysis timeframe, this might generate multiple discrete events, such as "Pod A terminating," "Pod B initializing," and "Pod B becomes ready." Through event aggregation and association (S303), the system can aggregate these scattered underlying events into a single, composite event with a clear business meaning: "The promotion-engine service completes a release operation." This approach allows subsequent analysis to be based on higher-dimensional business actions, rather than focusing on instantaneous state changes at the lower level. This significantly improves the problem of "isolated and scattered alarms and events lacking correlation," and helps to reconstruct the complete propagation chain of faults.

[0035] S104, based on the alarm type of the target alarm, select a corresponding prompt word template from multiple pre-defined prompt word templates.

[0036] To effectively guide large language models to perform professional and accurate root cause inference, rather than unconstrained text generation, this application employs a template-based dynamic prompt construction strategy. The system pre-configures multiple prompt templates for different alarm types (such as network anomalies, database performance issues, application errors, etc.). These templates are managed using template engines such as Jinja2 and contain complex instruction structures and domain knowledge.

[0037] Upon receiving a target alert, the system analyzes its type. In Example A, "API response timed out for retrieving shopping cart details" falls under the API performance issue category. Therefore, as... Figure 4 The flowchart shown illustrates the interaction between the prompt word construction and the large language model. The system executes step S403, which dynamically selects a prompt word template based on the target alarm (e.g., through target alarm metadata 401). This template is chosen from a pre-set template library specifically for analyzing API performance issues. This template may focus on guiding the large language model to analyze service dependencies, downstream latency, resource bottlenecks, etc. This dynamic selection mechanism ensures that the analysis strategy is highly aligned with specific fault scenarios, significantly improving the accuracy and relevance of the analysis.

[0038] S105, inject high-fidelity contextual data into the selected prompt word template to construct input prompt words.

[0039] After selecting a prompt word template, the system will fill the preset data placeholders in the template with the high-fidelity context data obtained after processing in S103. For example... Figure 4As shown, the high-fidelity context data 402 and target alarm metadata 401, after data compaction processing S404, are used for data injection and rendering of the prompt word template S405, ultimately generating a complete input prompt word 406 with extremely high information density and clear reasoning guidance.

[0040] In Example A, the preprocessed key events, such as Redis Bgsave alerts, KubePodUnhealthy alerts, and network latency alerts, are formatted and injected into the API performance issue template. The final generated input prompts not only include the original alert information and refined contextual events, but also the role setting of the large language model (e.g., "You are a senior operations expert"), the analysis framework (e.g., "Please analyze the fault propagation chain in the order of 'application layer - middleware layer - infrastructure layer'"), and the output format requirements.

[0041] S106, input the input prompt words into the large language model, and obtain a structured root cause analysis report from the large language model.

[0042] In S407, the constructed input prompt 406 is sent to the large language model for processing. Because the prompt is carefully designed, the large language model can perform logically rigorous "guided deterministic reasoning" within a specified framework, rather than aimless "probabilistic generation," thereby greatly reducing the risk of generating "illusions" or erroneous associations.

[0043] After the large language model has finished processing, it will return a structured root cause analysis report (408).

[0044] In Example A, after receiving the prompt words containing all key contexts, the large language model analyzes and concludes that the high-load operations (Bgsave and FullReplSync) on the Redis cluster caused a sharp decline in its performance. The downstream promotion-engine service became unhealthy due to slow data read / write operations (KubePodUnhealthy), which in turn caused the upstream shopping cart API call to time out. Finally, the system outputs a detailed report, as shown in the technical disclosure diagram, which clearly lists the root cause probability ranking (High Redis Load Operations: 80%), the key causal chain deduction, and specific follow-up recommendations.

[0045] This embodiment automates the entire process from receiving alarms to generating root cause analysis reports using the method described above. It deeply integrates multi-source heterogeneous data, extracts high-fidelity analysis materials through multi-stage intelligent preprocessing, and utilizes advanced dynamic prompt word engineering technology to guide a large language model for accurate root cause inference. This not only solves the pain points of traditional operations and maintenance, such as data silos, noise interference, and over-reliance on human experience, but also improves the speed and accuracy of fault location, providing efficient and reliable technical support for ensuring the stability of complex systems.

[0046] According to some embodiments of this application, multiple heterogeneous data sources 202 include: Platform as a Service (PaaS) alarm data sources, Infrastructure as a Service (IaaS) alarm data sources, change event data sources (such as release records from JIRA), distributed tracing data sources, and application change data sources (such as Kubernetes cluster events).

[0047] In Example A, the PaaS alert data source provides KubePodUnhealthy alerts from the promotion-engine service, while the IaaS alert data source provides alerts for network latency and the Redis cluster. This fusion of multi-source data allows analysis to span multiple layers, including applications, middleware, and infrastructure, constructing a comprehensive view of the fault situation. This enables the tracing of the complete fault propagation chain, as in this example, from an underlying Redis issue to an upper-layer application timeout. This effectively overcomes the limitation of existing technologies that struggle with cross-layer root cause analysis due to limited data scope.

[0048] According to some embodiments of this application, after obtaining context event data from multiple heterogeneous data sources, such as Figure 2 As shown, it also includes: performing unified and normalized data processing S204, parsing and mapping context event data and metadata associated with target alarms into an internal event model with a flat JSON structure to form a normalized event list 205.

[0049] In Example A, the metric alerts from Prometheus, the infrastructure alerts from Zabbix, and the Pod events from the Kubernetes API Server all have different raw formats and field definitions. Through the S204 data unification and normalization process, all these heterogeneous data are transformed into uniform, flattened JSON objects with standard fields such as event type, timestamp, associated entities, and severity level. This step effectively solves the problems of inconsistent data formats and semantic ambiguity from multiple sources, providing high-quality, machine-readable, and consistent input data for subsequent automated processing pipelines, laying the foundation for efficient and accurate analysis.

[0050] According to some embodiments of this application, the multi-stage preprocessing further includes: before group aggregation, such as... Figure 3 As shown, general noise filtering S302 is performed, which removes known events that are unrelated to business application failures from the context event data based on predetermined filtering rules.

[0051] These filtering rules can be pre-configured based on the operations team's knowledge base and historical experience. For example, rules can be configured to filter out periodic jitter alarms from certain known, non-critical systems, or low-priority events with limited impact that occur during the analysis period. In Example A, if there is also an alarm related to a non-core background task (such as report generation) within the same time period, the general noise filter S302 will remove it according to preset rules, allowing subsequent analysis to focus on events directly related to the core ToC business (shopping cart). This step can batch and automatically remove a large amount of background noise, significantly reducing the burden on subsequent processing stages and avoiding interference from irrelevant information in root cause determination.

[0052] According to some embodiments of this application, when the event data of the predetermined type is an application change event, the event aggregation and association S303 (group aggregation) specifically involves: [e.g., ...] Figure 3 As shown in the sub-steps, firstly, data classification 304 is performed. The system categorizes events into preset types based on their metadata, such as identifying which are application change events requiring aggregation and which are single alarm events that do not require aggregation. Subsequently, for the data classified as application change events, the system groups the data according to its location attributes (such as location) and instance name attributes (such as pod_name) S305, and performs data aggregation S306 and data sorting S307 based on the earliest occurrence time (firstTimestamp) and latest occurrence time of events within each group.

[0053] For example, a service deployment process generates a series of events for different Pod instances in Kubernetes. Traditional methods struggle to connect these isolated events. This embodiment, by grouping these events by location (e.g., data center or cluster name) and pod_name, clearly identifies which events belong to the same deployment operation. Then, by aggregating the timestamps of events within each group, the complete start and end times of this deployment operation can be determined. This allows the system to understand the business action of "a service deployment occurred" from a higher perspective, rather than just seeing the superficial phenomenon of "multiple Pod restarts," providing crucial contextual information for analyzing the correlation between deployment operations and failures.

[0054] According to some embodiments of this application, the multi-stage preprocessing further includes: after group aggregation, such as... Figure 3As shown, the business-level noise filtering S308 is executed. Based on the generated composite event data and the dynamically configured filtering rules, it identifies and filters out expected abnormal events that occur during compliant operations.

[0055] For example, brief service unavailability or performance fluctuations during a service release or scaling-up operation are expected. This embodiment intelligently identifies these "expected" abnormal events through business-level noise filtering S308 and filters them out. In the scenario of Example A, if the promotion-engine's KubePodUnhealthy alarm happens to occur within its own planned release window and is short in duration, this step will mark it as an expected event and filter it. This solves the core defect of "insufficient filtering of expected events" in the prior art, effectively avoiding misjudging normal phenomena in compliant operations as the root cause of failure, and further improving the accuracy of the analysis conclusions.

[0056] According to some embodiments of this application, the structure of the prompt word template includes: role setting, environmental background, built-in domain knowledge rules, structured output rules, and data placeholders for injecting high-fidelity context data.

[0057] Specifically, the "role setting" instructs the large language model to act as a "senior operations expert"; the "environmental background" describes the system architecture overview of the current analysis; the "built-in domain knowledge rules" contain some prior knowledge; and the "structured output rules" force the model to output reports in specific formats such as JSON and Markdown, ensuring the usability of the output. This highly structured template design transforms the analysis process from "probabilistic generation" to "guided deterministic reasoning," effectively constraining the model's output range and solving the problem of inaccurate and unreliable analysis results caused by directly using large language models in existing technologies.

[0058] According to some embodiments of this application, before injecting high-fidelity context data into the selected prompt word template, such as Figure 4 As shown, it also includes: performing data compaction processing S404 to convert high-fidelity context data into a compact string format.

[0059] Large language models typically have limitations on input length (number of tokens). To include as much key information as possible within a limited context window, this embodiment converts the structured, high-fidelity list of context data (such as an array of JSON objects) into a more compact string representation before injecting data. This operation significantly reduces the token consumption input into the large language model, directly lowering API call costs. More importantly, it ensures that more truly critical related events can be accommodated within the limited context window, thereby greatly improving the effective utilization of tokens and the accuracy of the final analysis.

[0060] According to some embodiments of this application, the structured root cause analysis report 408 includes at least one of the following information: target alarm profile, timeline of related events, deduction of key causal chains, ranking of root cause probabilities, and handling recommendations.

[0061] For example, the output report of Example A can show that the "Target Alarm Profile" summarizes the core characteristics of the alarm; the "Related Event Timeline" clearly displays all related events in chronological order; the "Key Causal Chain Deduction" logically reproduces the propagation path of the fault; the "Root Cause Probability Ranking" indicates the most likely root cause with quantified confidence; and the "Handling Recommendations" provides specific and feasible short-term and long-term solutions. This structured output format is not only intuitive and user-friendly for human engineers but also has good machine readability. It can be seamlessly integrated with automated operation and maintenance processes (such as automatically creating work orders and executing recovery plans), realizing an automated closed loop in the fault handling process and overcoming the difficulty of "limited automation and intelligence" in existing technologies.

[0062] Figure 5 This is a hardware structure block diagram of an electronic device that implements alarm root cause processing according to embodiments of this application.

[0063] like Figure 5 As shown, the electronic device 500 may include one or more processors 502, a system motherboard 508 connected to at least one of the processors 502, system memory 504 connected to the system motherboard 508, non-volatile memory (NVM) 506 connected to the system motherboard 508, and a network interface 510 connected to the system motherboard 508.

[0064] Processor 502 may include one or more single-core or multi-core processors. Processor 502 may include any combination of general-purpose processors and special-purpose processors (e.g., graphics processors, application processors, baseband processors, etc.). In embodiments of the invention, processor 502 may be configured to perform one or more embodiments according to various method embodiments of the present application.

[0065] In some embodiments, the system motherboard 508 may include any suitable interface controller to provide any suitable interface to at least one of the processors 502 and / or any suitable device or component communicating with the system motherboard 508.

[0066] In some embodiments, system motherboard 508 may include one or more memory controllers to provide an interface to system memory 504. System memory 504 may be used to load and store data and / or instructions. In some embodiments, system memory 504 of electronic device 500 may include any suitable volatile memory, such as suitable dynamic random access memory (DRAM).

[0067] The NVM 506 may include one or more tangible, non-transitory computer-readable media for storing data and / or instructions. In some embodiments, the NVM 506 may include any suitable non-volatile memory such as flash memory and / or any suitable non-volatile storage device, such as at least one of an HDD (Hard Disk Drive), a CD (Compact Disc) drive, or a DVD (Digital Versatile Disc) drive.

[0068] The NVM 506 may include a portion of the storage resources on a device installed on electronic device 500, or it may be accessible by the device, but is not necessarily part of the device. For example, the NVM 506 may be accessed over a network via network interface 510.

[0069] Specifically, system memory 504 and NVM 506 may each include a temporary copy and a permanent copy of instruction 520. Instruction 520 may include instructions that, when executed by at least one of processors 502, cause electronic device 500 to perform methods as described in embodiments of this application. In some embodiments, instruction 520, hardware, firmware, and / or its software components may additionally / alternatively be located in system motherboard 508, network interface 510, and / or processor 502.

[0070] Network interface 510 may include a transceiver for providing a radio interface to electronic device 500, thereby enabling communication with any other suitable device (e.g., front-end module, antenna, etc.) via one or more networks. In some embodiments, network interface 510 may be integrated into other components of electronic device 500. For example, network interface 510 may be integrated into at least one of processor 502, system memory 504, NVM 506, and firmware device (not shown) with instructions, wherein when at least one of processor 502 executes the instructions, electronic device 500 implements one or more embodiments of various method embodiments of this application.

[0071] The network interface 510 may further include any suitable hardware and / or firmware to provide a multiple-input multiple-output radio interface. For example, the network interface 510 may be a network adapter, a wireless network adapter, a telephone modem, and / or a wireless modem.

[0072] In one embodiment, at least one of the processors 502 may be packaged together with one or more controllers for the system motherboard 508 to form a system-in-package (SiP). In another embodiment, at least one of the processors 502 may be integrated on the same die with one or more controllers for the system motherboard 508 to form a system-on-a-chip (SoC).

[0073] The electronic device 500 may further include an input / output (I / O) device 512 connected to the system motherboard 508. The I / O device 512 may include a user interface enabling a user to interact with the electronic device 500; the peripheral component interface is designed to allow peripheral components to also interact with the electronic device 500. In some embodiments, the electronic device 500 may also include sensors for determining at least one type of environmental condition and location information related to the electronic device 500.

[0074] In some embodiments, I / O device 512 may include, but is not limited to, a display (e.g., a liquid crystal display, a touch screen display, etc.), a speaker, a microphone, one or more cameras (e.g., a still image camera and / or a video camera), a flashlight (e.g., a light-emitting diode flash), and a keyboard.

[0075] In some embodiments, the peripheral component interface may include, but is not limited to, a non-volatile memory port, an audio jack, and a power interface.

[0076] In some embodiments, the sensor may include, but is not limited to, a gyroscope sensor, an accelerometer, a proximity sensor, an ambient light sensor, and a positioning unit. The positioning unit may also be part of or interact with the network interface 510 to communicate with components of the positioning network, such as Global Positioning System (GPS) satellites.

[0077] It is understood that the structures illustrated in the embodiments of the present invention do not constitute a specific limitation on the electronic device 500. In other embodiments of this application, the electronic device 500 may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0078] Program code can be applied to input instructions to perform the functions described in this invention and generate output information. The output information can be applied to one or more output devices in a known manner. For the purposes of this application, a system for processing instructions including processor 502 includes any system having a processor such as a digital signal processor (DSP), microcontroller, application-specific integrated circuit (ASIC), or microprocessor.

[0079] The program code can be implemented using a high-level procedural language or an object-oriented programming language to communicate with the processing system. Assembly language or machine language can also be used when needed. In fact, the mechanisms described in this invention are not limited to any particular programming language. In either case, the language can be a compiled language or an interpreted language.

[0080] One or more aspects of at least one embodiment may be implemented by instructions stored on a computer-readable storage medium, which, when read and executed by a processor, enable an electronic device to implement the methods of the embodiments described in this invention.

[0081] According to some embodiments of this application, a computer storage medium is disclosed, on which instructions are stored, which, when executed on a computer, cause the computer to perform an alarm root cause processing method according to an embodiment of this application.

[0082] The method embodiments of this application correspond to this embodiment, and this embodiment can be implemented in conjunction with the method embodiments of this application. The relevant technical details mentioned in the method embodiments of this application are still valid in this embodiment, and will not be repeated here to reduce repetition. Accordingly, the relevant technical details mentioned in this embodiment can also be applied to the method embodiments of this application.

[0083] According to some embodiments of this application, a computer program product is disclosed, including computer-executable instructions that are executed by a processor to implement an alarm root cause processing method according to embodiments of this application.

[0084] The method embodiments of this application correspond to this embodiment, and this embodiment can be implemented in conjunction with the method embodiments of this application. The relevant technical details mentioned in the method embodiments of this application are still valid in this embodiment, and will not be repeated here to reduce repetition. Accordingly, the relevant technical details mentioned in this embodiment can also be applied to the method embodiments of this application.

[0085] It is understood that the specific embodiments described herein are merely for illustrative purposes and not for limiting the scope of this application. Furthermore, for ease of description, the accompanying drawings show only the parts relevant to this application, and not all of the structures or processes. It should be noted that similar reference numerals and letters in this specification denote similar items in the accompanying drawings.

[0086] It should be understood that although the terms "first," "second," etc., may be used herein to describe various features, these features should not be limited by these terms. The use of these terms is merely for distinction and should not be construed as indicating or implying relative importance. For example, without departing from the scope of the exemplary embodiments, a first feature may be referred to as a second feature, and similarly, a second feature may be referred to as a first feature.

[0087] In the description of this application, it should also be noted that, unless otherwise explicitly specified and limited, the terms "set up," "connected," and "linked" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection of two components. Those skilled in the art can understand the specific meaning of the above terms in this embodiment based on the specific circumstances.

[0088] The illustrative embodiments of this application include, but are not limited to, alarm root cause processing methods, devices, media, and computer program products.

[0089] Various aspects of the illustrative embodiments will be described using terminology commonly employed by those skilled in the art to convey the essence of their work to others skilled in the art. However, it will be apparent to those skilled in the art that some alternative embodiments will be practiced using the features partially described. Specific figures and configurations are set forth for purposes of explanation in order to provide a more thorough understanding of the illustrative embodiments. However, it will be apparent to those skilled in the art that alternative embodiments may be practiced without specific details. In some other instances, well-known features have been omitted or simplified herein to avoid obscuring the illustrative embodiments of this application.

[0090] Furthermore, the various operations will be described as multiple separate operations in a manner most conducive to understanding the illustrative embodiments; however, the order of description should not be construed as implying that these operations must depend on the order of description, and many of these operations may be performed in parallel, concurrently, or simultaneously. Moreover, the order of the operations may also be rearranged. The process may be terminated when the described operations are completed, but may also include additional steps not included in the figures. The process may correspond to a method, function, procedure, subroutine, subroutine, etc.

[0091] References to "an embodiment," "embodiment," "illustrative embodiment," etc., in this specification indicate that the described embodiment may include specific features, structures, or properties; however, each embodiment may or may not necessarily include specific features, structures, or properties. Furthermore, these phrases are not necessarily directed to the same embodiment. Additionally, when specific features are described in conjunction with specific embodiments, the knowledge of those skilled in the art can influence the combination of these features with other embodiments, whether or not those embodiments are explicitly described.

[0092] Unless the context otherwise specifies, the terms “comprising,” “having,” and “including” are synonyms. The phrase “A and / or B” means “(A), (B), or (A and B).”

[0093] As used herein, the term "module" may refer to, as part of, or include: a memory (shared, dedicated, or grouped), an application-specific integrated circuit (ASIC), electronic circuitry and / or a processor (shared, dedicated, or grouped), combinational logic circuitry, and / or other suitable components that provide the said functionality for running one or more software or firmware programs.

[0094] In the accompanying drawings, some structural or methodological features may be shown in a specific arrangement and / or order. However, it should be understood that such a specific arrangement and / or order is not necessary. Rather, in some embodiments, these features may be illustrated in a manner and / or order different from that shown in the illustrative drawings. Furthermore, the inclusion of structural or methodological features in a particular drawing does not mean that all embodiments need to include such features; in some embodiments, these features may be omitted or may be combined with other features.

[0095] In some cases, the disclosed embodiments may be implemented in hardware, firmware, software, or any combination thereof. The disclosed embodiments may also be implemented as instructions or programs carried or stored on one or more transient or non-transient machine-readable (e.g., computer-readable) storage media, which may be read and executed by one or more processors, etc. When the instructions or program are run by a machine, the machine may perform the various methods described above. For example, the instructions may be distributed via a network or other computer-readable media. Therefore, machine-readable media may include, but are not limited to, any mechanism for storing or transmitting information in a machine-readable (e.g., computer-readable) form, such as floppy disks, optical disks, optical disc read-only memories (CD-ROMs), magneto-optical disks, read-only memories (ROMs), random access memories (RAMs), erasable programmable read-only memories (EPROMs), electronically erasable programmable read-only memories (EEPROMs), magnetic cards or optical cards, or flash memory or tangible machine-readable storage for transmitting network information via electrical, optical, acoustic, or other forms of signals (e.g., carrier waves, infrared signals, digital signals, etc.). Therefore, machine-readable media includes any form of machine-readable medium suitable for storing or transmitting electronic instructions or machine-readable (e.g., computer-readable) information.

[0096] The embodiments of this application have been described in detail above with reference to the accompanying drawings. However, the use of the technical solutions of this application is not limited to the various applications mentioned in the embodiments of this application. Various structures and modifications can be easily implemented with reference to the technical solutions of this application to achieve the various beneficial effects mentioned herein. Within the scope of knowledge possessed by those skilled in the art, all changes made without departing from the spirit of this application should be considered within the scope of this patent application.

Claims

1. A method for handling alarm root causes, characterized in that, include: The identifier for receiving target alarms; Based on the identifier of the target alarm and the predetermined analysis time range, context event data is obtained from multiple heterogeneous data sources; The context event data is preprocessed in multiple stages to generate high-fidelity context data. The multi-stage preprocessing includes: grouping and aggregating event data of a predetermined type to associate discrete point-like event data into composite event data with business meaning. Based on the alarm type of the target alarm, select a corresponding prompt word template from multiple pre-defined prompt word templates; The high-fidelity context data is injected into the selected prompt word template to construct input prompt words; The input prompts are fed into a large language model, and a structured root cause analysis report is obtained from the large language model.

2. The method according to claim 1, characterized in that, The multiple heterogeneous data sources include: Platform as a Service alarm data source, Infrastructure as a Service alarm data source, Change Event Data Source, Distributed Tracing Data Source, and Application Change Data Source.

3. The method according to claim 2, characterized in that, After obtaining context event data from the multiple heterogeneous data sources, the process also includes: The context event data and metadata associated with the target alarm are parsed and mapped into an internal event model with a flat JSON structure to form a standardized event list.

4. The method according to claim 1, characterized in that, The multi-stage preprocessing also includes: Before the grouping and aggregation, known events that are unrelated to business application failures are removed from the context event data based on predetermined filtering rules.

5. The method according to claim 4, characterized in that, When the event data of the predetermined type is an application change event, the grouping aggregation includes: The events are grouped according to their location and instance name attributes, and then aggregated and sorted according to the earliest and latest occurrence times of the events within each group.

6. The method according to claim 5, characterized in that, The multi-stage preprocessing also includes: After the grouping and aggregation, based on the generated composite event data and combined with dynamically configured filtering rules, anticipated abnormal events generated during compliant operations are identified and filtered out.

7. The method according to claim 1, characterized in that, The structure of the prompt word template includes: character settings, environmental background, built-in domain knowledge rules, structured output rules, and data placeholders for injecting the high-fidelity context data.

8. The method according to claim 1, characterized in that, Before injecting the high-fidelity context data into the selected prompt word template, the method further includes: The high-fidelity context data is converted into a compact string format.

9. The method according to claim 1, characterized in that, The structured root cause analysis report shall include at least one of the following: target alarm profile, timeline of related events, derivation of key causal chains, ranking of root cause probabilities, and handling recommendations.

10. An electronic device, characterized in that, The electronic device includes a memory storing computer-executable instructions and a processor, which, when executed by the processor, cause the electronic device to perform the alarm root cause processing method according to any one of claims 1-9.

11. A computer storage medium, characterized in that, The computer storage medium stores instructions that, when executed on the computer, cause the computer to perform the alarm root cause processing method according to any one of claims 1-9.

12. A computer program product, characterized in that, It includes computer-executable instructions, which are executed by a processor to implement the alarm root cause processing method according to any one of claims 1-9.

Images