Method, apparatus, device and storage medium for alarm processing

Abstract

A method, apparatus, device and storage medium for alarm processing are provided. The method proposed herein includes: receiving multi-source information related to an alarm event, the multi-source information including text information of the alarm event and at least one image related to an indicator of the alarm event, the at least one image representing a change trend of the indicator; obtaining a visual analysis result of the at least one image, the visual analysis result being obtained based on a pattern of the change trend in the at least one image; and providing a processing strategy for the alarm event, the processing strategy being obtained based on the text information and the visual analysis result, and the processing strategy indicating at least any one of a response level and a processing action of the alarm event. In this way, the efficiency of alarm processing can be improved.

Description

Technical Field

[0001] The examples in this article generally relate to the field of computers, and in particular to methods, apparatus, devices, and computer-readable storage media for alarm processing. Background Technology

[0002] With the continuous development of information technology and computing systems, various application systems typically reflect their operational status by collecting and analyzing operational metrics, and generate corresponding alarms when potential faults cause changes in operational status. Application system alarms notify administrators of system anomalies, allowing them to narrow down the diagnostic scope and quickly determine the cause of the fault. However, with the increase in system scale and business complexity, the number of alarms continues to rise, and sometimes a large number of noisy alarms may exist. Therefore, how to achieve more accurate and efficient alarm processing has become an urgent problem to be solved in the field of automated operation and maintenance and intelligent processing. Summary of the Invention

[0003] In a first aspect, a method for alarm processing is provided. The method includes: receiving multi-source information related to an alarm event, the multi-source information including textual information of the alarm event and at least one image related to an indicator of the alarm event, the at least one image representing a trend of change in the indicator; acquiring visual analysis results of the at least one image, the visual analysis results being obtained based on the morphology of the trend of change in the at least one image; and providing a processing strategy for the alarm event, the processing strategy being obtained based on the textual information and the visual analysis results, and the processing strategy indicating at least one of a response level and a processing action for the alarm event.

[0004] In a second aspect, an apparatus for alarm processing is provided. The apparatus includes: a receiving module configured to receive multi-source information related to an alarm event, the multi-source information including text information of the alarm event and at least one image related to an indicator of the alarm event, the at least one image representing a trend of change in the indicator; an acquiring module configured to acquire visual analysis results of the at least one image, the visual analysis results being acquired based on the morphology of the trend of change in the at least one image; and a providing module configured to provide a processing strategy for the alarm event, the processing strategy being acquired based on the text information and the visual analysis results, and the processing strategy indicating at least one of a response level and a processing action for the alarm event.

[0005] In a third aspect, an electronic device is provided. The device includes at least one processor; and at least one memory coupled to the at least one processor and storing instructions for execution by the at least one processor. When executed by the at least one processor, the instructions cause the device to perform the method of the first aspect.

[0006] In a fourth aspect, a computer-readable storage medium is provided. The computer-readable storage medium stores computer-executable instructions that can be executed by a processor to implement the method of the first aspect.

[0007] In a fifth aspect, a computer program product is provided, which is tangibly stored in a computer storage medium and includes computer-executable instructions that, when executed by a device, cause the device to perform the method of the first aspect.

[0008] This method can improve the efficiency of alarm processing.

[0009] It should be understood that the content described in this section is not intended to limit the key or important features of the examples in this article, nor is it intended to restrict the scope of the solution. Other features will become readily apparent from the following description. Attached Figure Description

[0010] The above and other features, advantages, and aspects of the various examples herein will become more apparent when taken in conjunction with the accompanying drawings and the following detailed description. In the accompanying drawings, the same or similar reference numerals denote the same or similar elements, wherein: Figure 1 A schematic diagram of the example environment is shown; Figure 2 A schematic diagram of an example framework for an alarm handling system is shown for some scenarios; Figure 3 The diagram illustrates example procedures for alarm handling in several scenarios. Figure 4 Flowcharts of example methods for alarm handling in some scenarios are shown; Figure 5 Block diagrams of example devices for alarm handling in several scenarios are shown; and Figure 6 A block diagram of an electronic device capable of implementing multiple illustrative scenarios is shown. Detailed Implementation

[0011] The examples in the text will now be described in more detail with reference to the accompanying drawings. While some examples are shown in the drawings, it should be understood that solutions can be implemented in various forms and should not be construed as limited to the examples presented herein. Rather, these examples are provided to provide a more thorough and complete understanding of the solutions. It should be understood that the drawings and examples in this document are for illustrative purposes only and are not intended to limit the scope of protection of the solutions.

[0012] It should be noted that the headings of any section / subsection provided herein are not restrictive. Various examples are described throughout this document, and examples of any type may be included under any section / subsection. Furthermore, examples described in any section / subsection may be combined in any way with any other examples described in the same section / subsection and / or different sections / subsections.

[0013] In the description of the examples in this document, the term "including" and similar terms should be understood as open inclusion, i.e., "including but not limited to". The term "based on" should be understood as "at least partially based on". The term "an example" or "the example" should be understood as "at least one example". The term "some examples" should be understood as "at least some examples". Other explicit and implicit definitions may also be included below. The terms "first", "second", etc., may refer to different or the same objects. Other explicit and implicit definitions may also be included below.

[0014] The examples in this document may involve user data, data acquisition, and / or use. All of these aspects comply with relevant laws, regulations, and provisions. In the examples presented herein, all data collection, acquisition, processing, manipulation, forwarding, and use are conducted with the user's knowledge and confirmation. Accordingly, when implementing each example, the type, scope of use, and usage scenarios of any data or information that may be involved should be communicated to the user and their authorization obtained through appropriate means, in accordance with relevant laws and regulations. The specific methods of notification and / or authorization can vary depending on the actual situation and application scenario; the scope of the solution is not limited in this regard.

[0015] In this manual and the sample solutions, any processing of personal information will be conducted only under legal grounds (such as obtaining the consent of the data subject or being necessary for the performance of a contract) and will only be carried out within the scope stipulated or agreed upon. A user's refusal to process personal information beyond what is necessary for basic functions will not affect the user's use of basic functions.

[0016] Example Environment Figure 1 A schematic diagram of example environment 100 is shown. (e.g.) Figure 1 As shown, example environment 100 may include electronic device 110. In this example environment 100, electronic device 110 may run application 120 that performs multiple functions. Application 120 may be any suitable type of application for providing multiple functions, such as a video sharing application, an audio sharing application, etc. User 140 may interact with application 120 via electronic device 110 and / or its attached devices.

[0017] exist Figure 1In environment 100, if application 120 is active, electronic device 110 can use application 120 to present interface 150 for providing a variety of functions.

[0018] In some cases, electronic device 110 communicates with server 130 to provide services to application 120. Electronic device 110 can be any type of mobile terminal, fixed terminal, or portable terminal, including mobile phones, desktop computers, laptop computers, notebook computers, netbook computers, tablet computers, media computers, multimedia tablets, handheld computers, portable gaming terminals, VR / AR devices, personal communication system (PCS) devices, personal navigation devices, personal digital assistants (PDAs), audio / video players, digital cameras / camcorders, positioning devices, television receivers, radio receivers, e-book devices, gaming devices, or any combination of the foregoing, including accessories and peripherals of these devices or any combination thereof. In some cases, electronic device 110 can also support any type of user-facing interface (such as "wearable" circuitry).

[0019] Server 130 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks, and big data and artificial intelligence platforms. Server 130 may include, for example, computing systems / servers such as mainframes, edge computing nodes, computing devices in a cloud environment, etc. Server 130 can provide background services for application 120 in electronic device 110 that supports alarm processing.

[0020] A communication connection can be established between server 130 and electronic device 110. This communication connection can be established via wired or wireless means. The communication connection can include, but is not limited to, Bluetooth, mobile network, Universal Serial Bus (USB), and Wireless Fidelity (WiFi) connections. In some cases, server 130 and electronic device 110 can exchange signaling information through their communication connection.

[0021] It should be understood that the structure and function of the various elements in environment 100 are described for illustrative purposes only and do not imply any limitation on the scope of the scheme. The examples will continue to be described below with reference to the accompanying drawings. In some cases, the application system may include electronic device 110 and / or server 130.

[0022] As mentioned above, in the operation and management of application systems such as cloud computing platforms, internet service systems, and resource scheduling systems, it is usually necessary to generate alarm events based on changes in operational indicators. Relevant processing mechanisms then assess the impact of these alarm events to determine whether further response measures are required. In practice, after an alarm event occurs, it is typically necessary to comprehensively judge the scope and urgency of the event by combining the status information at the time of the alarm and subsequent trends, and determine the corresponding response level and handling actions accordingly. For example, in some application operation management systems, alarm events may need to be classified into different levels based on their impact, triggering corresponding emergency response procedures.

[0023] Traditional alarm handling relies heavily on manual monitoring. Monitors typically need to quickly review information from multiple sources, such as alarm text descriptions, operational metric trend charts, historical data, and relevant processing records. They must rely on experience to determine the severity of the incident and make appropriate decisions. However, with the continuous increase in system scale and business complexity, the number of alarm events generated per unit of time has significantly increased, posing significant challenges to the efficiency and consistency of manual methods.

[0024] In real-world system operation and management scenarios, alarm event judgment often requires the integration of multiple types of information, such as alarm descriptions and changes in data metrics. In traditional alarm handling methods, this information is typically scattered across different interfaces or systems, requiring manual comparison and correlation analysis. This manual correlation-based information processing method is not only inefficient but also struggles to achieve unified and objective judgment standards. For example, for the same type of metric fluctuations, different personnel may make different judgments based on experience, thus affecting the consistency of the processing flow.

[0025] Furthermore, to improve system operation efficiency, some alarm handling solutions introduce data analysis models to process indicator data generated during system operation, enabling anomaly identification and correlation analysis. For example, by modeling historical operational data, time series analysis, cluster analysis, or pattern recognition can be used to determine the trend of operational status changes. However, in actual operational scenarios, changes in operational indicators are often reflected not only in numerical shifts but also in the overall morphological characteristics of the change process, such as whether the change exhibits a phased plateau, abrupt inflection points, or periodic fluctuations. The above methods typically build models around a single data format, offering limited synergistic understanding between textual descriptions, rule documents, and graphical trend information.

[0026] Other alarm handling solutions involve utilizing natural language understanding to semantically parse event descriptions, processing records, and operational procedures, and assisting users in problem analysis or decision generation through interactive dialogue. However, in practical applications, alarm events typically contain multiple types of information. If these multiple pieces of information are not combined for comprehensive judgment, it may lead to insufficient decision-making basis, thereby affecting the accuracy of the handling decision.

[0027] To at least partially address the aforementioned problems, a method for alarm processing is proposed. In summary, it first receives multi-source information related to an alarm event, including textual information about the alarm event and at least one image related to an indicator of the alarm event, whereby the at least one image represents the trend of the indicator's change. Then, it acquires visual analysis results of the at least one image, the visual analysis results being obtained based on the morphology of the trend in the at least one image. Furthermore, it can provide a processing strategy for the alarm event, the processing strategy being obtained based on the textual information and the visual analysis results, and the processing strategy indicating at least one of the alarm event's response level and processing action.

[0028] Specifically, the proposed method performs visual analysis on images representing the trend of indicator changes and obtains visual analysis results based on the morphology of the trend. This allows the processing of alarm events to not only rely on textual descriptions but also to make comprehensive judgments based on the overall state characteristics reflected by the trend changes. Since the morphology of the trend reflects the continuous characteristics of the indicator's evolution over time, the obtained visual analysis results can serve as a supplement to the textual information, thereby improving the completeness of the understanding of the alarm event status.

[0029] The proposed scheme can comprehensively utilize multi-source information when generating alarm event handling strategies, so that the determination process of handling strategies can simultaneously consider event description information and state characteristics reflected by indicator change trends. This helps to improve the rationality of response level judgment and handling action determination, and supports more consistent and stable handling of alarm events.

[0030] See Figure 2 and Figure 3 Describe the proposed technical solution. Figure 2 A schematic diagram of an example framework of a system 200 for alarm handling in some scenarios is shown. Figure 3 A schematic diagram of an example process 300 for alarm handling in some scenarios is shown.

[0031] For ease of discussion, we will combine Figure 1 Example environment 100 is shown to describe Figure 2 The system 200 shown and Figure 3 The example process 300 shown is merely illustrative. System 200 and process 300 may be deployed in or implemented by server 130, for example. For instance, system 200 and process 300 may be at least partially deployed or implemented in server 130. Alternatively, system 200 and process 300 may be at least partially deployed or implemented in electronic device 110. Yet another example is that a portion of system 200 and process 300 may be deployed or implemented in electronic device 110, and another portion may be deployed or implemented in server 130.

[0032] like Figure 2 As shown, in some cases, system 200 can be constructed using a layered architecture. For example, system 200 may include a data input layer 210, a multimodal analysis layer 220, a decision layer 230, and an execution and feedback layer 240. The layers can interact through structured information, enabling information from different sources to be processed and integrated step by step, thereby achieving the determination of the response level for alarm events and the generation and output of processing strategies.

[0033] like Figure 2As shown, the data input layer 210 can be used to receive multi-source information related to alarm events. The multimodal analysis layer 220 can be used to perform parallel analysis and semantic extraction on data of different modalities. For example, the multimodal analysis layer 220 may include a visual analysis module 221 for image analysis and a retrieval module 222 for knowledge-based retrieval. The decision layer 230 can be used to generate alarm handling strategies based on the structured analysis results from the multimodal analysis layer 220. For example, the decision layer 230 may include a decision module 231 and a conditional execution module 232. The execution and feedback layer 240 can be used to execute corresponding operations according to the generated processing strategy and record the execution results. For example, the execution and feedback layer 240 may include an execution feedback module 245 for triggering alarm handling actions, recording the processing process, and generating feedback information to support subsequent model optimization or strategy updates.

[0034] In some situations, the data input layer 210 can be used to acquire multi-source information related to alarm events. For example... Figure 3 As shown, one or more application systems 305 can trigger an alarm event (301) based on predetermined rules or state changes during operation, and provide system 200 with multi-source information related to the alarm event. This multi-source information can come from different types of business systems or service components and be presented in different forms.

[0035] In some scenarios, an alarm can represent a type of prompt or trigger signal generated by a business system during operation based on predetermined rules or state changes, indicating that a relevant object may have a situation requiring attention or action. An alarm event can represent a set of pending tasks surrounding an alarm. In some cases, an alarm event may consist of a single alarm. In other cases, multiple alarms related in time, object, or scope of impact can be grouped into a single alarm event for unified processing. An alarm event can be understood as a processing unit that organizes and correlates related alarm information, used for subsequent analysis, decision-making, and the execution of response actions.

[0036] In some scenarios, alarm events can be generated by the business system when it detects predetermined changes in key metrics. For example, if metrics such as business request processing volume, resource utilization, or service response time fluctuate significantly over a period of time, the corresponding system can generate alarm events and provide descriptive information related to the alarm events.

[0037] In practical applications, alarms triggered by changes in indicator values ​​are typically used to alert relevant objects to potential state changes. However, such triggering mechanisms often focus on numerical deviations within a single point in time or a limited time window, failing to reflect the overall change process of the indicator over continuous time. For example, an indicator may quickly recover after a short deviation from a predetermined range; or, although the indicator may not significantly exceed a preset threshold, it may exhibit a continuous downward trend or a phased change trend. Therefore, relying solely on numerical triggering results is insufficient to accurately represent the actual state of change corresponding to the alarm event. In some situations, images representing indicator change trends can serve as important criteria in the decision-making process. By identifying and structurally extracting the change patterns in the trend chart through a visual analysis module, the change process depicted in the image can participate in subsequent rule matching and response level determination.

[0038] In some scenarios, system 200 may receive text information 211 and at least one image 212 associated with an indicator related to the alarm event. The indicator may represent a data metric reflecting the operational status or service performance of a business object, such as resource usage, number of requests processed, task completion rate, response latency, or other quantitative parameters. At least one image may represent the trend of the indicator. For example, the image may represent the change of the indicator over time using curves, line graphs, or other visualizations, thereby supporting the subsequent multimodal analysis layer 220 in performing structured analysis of trend patterns and comparative judgments across time ranges.

[0039] In some cases, indicators that cannot be expressed in continuous time series form, such as discrete statistical results, staged state counts, or periodic summary data, can be visualized by constructing segmented change charts, cumulative change charts, or frequency distribution charts within the statistical period, thus reflecting their changing trends or structural characteristics. By performing unified structured feature extraction processing on the above images, the image information corresponding to different types of indicators can be made comparable and analyzable in the decision-making process.

[0040] As an example, multi-source information may include event titles, event description text, and multiple images representing indicator trends. These images can represent indicator trends over different time windows, such as trends for the current time period, trends over a longer time range, and trends for the same period in history. These images can also be associated with corresponding time range identifiers, indicator expressions, or contextual record information for subsequent comprehensive analysis of indicator changes. For example, multi-source information may include: text information representing the alarm event content, access addresses for multiple trend images, and time range identifiers corresponding to each trend image.

[0041] Continue to refer to Figure 3In some cases, the data input layer 210 may include a data preprocessing module 215. The data preprocessing module 215 can be used to perform structured information extraction (311) processing on the received multi-source information. For example, the data preprocessing module 215 can extract event identifiers, indicator types, trigger times, affected objects, and time range information from text information 211, and perform identifier association and time range alignment processing on at least one image 212, thereby forming structured input data in a unified format. By unifying the format and standardizing the fields of information from different sources, the expression differences between different information sources in subsequent analysis processes can be reduced, improving the efficiency and stability of multimodal collaborative analysis.

[0042] Furthermore, the data preprocessing module 215 can send a visual analysis request (312) to the multimodal analysis layer 220. In some cases, the data preprocessing module 215 can be implemented by a separate processing module or by an intelligent processing unit. For example, as an optional implementation, the data preprocessing module 215 can be implemented by an agent dedicated to data preprocessing to perform input normalization and information organization tasks. By separating the preprocessing responsibilities from the subsequent analysis modules, the coupling between the visual analysis module and other processing modules can be reduced, allowing each functional unit to focus on its own specialized tasks, thereby improving the maintainability and scalability of the overall architecture.

[0043] In some cases, the visual analysis module 221 can perform visual analysis (313) on at least one graph 212. For example, the visual analysis module 221 can identify information such as the direction of change of the trend curve along the time axis, the continuity of the change amplitude, the frequency of local fluctuations, the trend turning point, and the trend characteristics of the terminal area, and convert the above information into a structured feature representation. Based on these structured features, visual analysis results can be generated for subsequent rule matching and response level determination. By converting the continuous change process in the trend graph into a computable structured representation, image information can be used as a core judgment criterion to participate in the condition verification and decision generation in the subsequent decision-making process.

[0044] In some cases, (314) visual analysis results for at least one image can be obtained. The visual analysis results are obtained based on the morphology of the indicator change trend in at least one image 212. For example, during the visual analysis process, image data representing the indicator change trend can be obtained, and the trend curve presented in the image can be analyzed to determine the change state of the indicator within the corresponding time range. The visual analysis results can represent the trend state in a structured form for use in the subsequent processing strategy generation process. By converting the trend image into a structured visual analysis result, the subsequent decision-making process can make judgments based on the trend change characteristics.

[0045] In some cases, the visual analysis module 221 can extract structured features representing the shape of a trend based on at least one image. Furthermore, the visual analysis module 221 can generate visual analysis results based on these structured features. For example, after acquiring a trend image, the visual analysis module 221 can identify changes in the trend curve over time, including features such as the direction of change, the magnitude of change, the duration of change, and the degree of trend stability, and convert these features into structured descriptive information.

[0046] In some cases, the visual analysis module 221 can be implemented by either a visual analysis module or an intelligent processing unit. For example, as an optional implementation, the visual analysis module 221 can be implemented by a visual analysis agent in a multi-agent collaborative architecture. The visual analysis agent can focus on image morphology understanding tasks, and its output can be provided to the decision layer in the form of structured fields. In this way, the visual analysis module 221 can maintain its specialized capabilities while forming a collaborative relationship with other processing modules, thereby improving the stability and interpretability of the overall system.

[0047] In some cases, visual analysis results can indicate whether there are anomalous patterns in the trend of change represented in at least one image 212, such as abrupt changes, continuous declines, or abnormal fluctuations. This analysis can be used to distinguish between changes caused by short-term fluctuations and trend changes with ongoing risks, thus providing a basis for subsequent response level determination.

[0048] In some cases, anomalies can include sudden changes in indicator trends, continuous downward trends, abnormal fluctuations, or obvious trend reversals. For example, anomalies may manifest as a rapid decline in an indicator within a short period, an indicator remaining consistently below historical levels over a continuous timeframe, or a clear inflection point or sharp drop in the indicator's curve. Different anomalies correspond to different degrees of event impact, and identifying anomalies can provide a basis for generating subsequent processing strategies.

[0049] In some cases, visual analysis results can indicate the duration of anomalous patterns. The duration of anomalies can be used to reflect the stability of a changing state. For example, short-duration changes may correspond to transient disturbances, while long-duration changes may indicate that the relevant state is continuously evolving, thus supporting subsequent judgments on the urgency of the response.

[0050] In some cases, visual analysis results can indicate the degree of anomaly corresponding to a trend. For example, visual analysis module 221 can determine the proportion of anomalies within the overall time range based on the change range of the trend curve within a predetermined time range. By identifying the proportion of anomalies, it is possible to further distinguish between local disturbances and overall changes, thereby providing a quantitative basis for determining the response level or selecting processing actions in subsequent processing strategies.

[0051] In some cases, visual analysis results can indicate the degree of difference between a first trend of change indicated by a first image and a second trend of change indicated by a second image. For example, the first trend of change could be the trend of the indicator within the current time frame, while the second trend could be the trend of the indicator within a historical time frame. This degree of difference can be used to determine whether the current change deviates from historical cyclical patterns. For instance, if the trend of the indicator within the current time frame is consistent with the historical trend for the same period, the change can be determined to be cyclical. If the difference is significant, it can indicate a possible abnormal change, thus providing a reference for generating subsequent processing strategies.

[0052] As an example, at least one image 212 may include images representing the trend of indicator changes over a more recent time range (e.g., 30 minutes), a longer time range (e.g., 3 hours), and a historical period. A historical period can represent a time range in history that has the same or similar business cycle characteristics as the current time period, such as the same time period of the previous day or week. The visual analysis module 221 can perform joint analysis based on the trend images at the above multiple time scales to determine whether the current indicator change is a periodic change or an abnormal change.

[0053] In some situations, visual analytics can indicate whether a trend is in a recovery phase. Identifying the recovery phase helps distinguish between anomalies that are still developing and those that have subsided or stabilized. In practice, some alarms may have already been mitigated through automatic adjustments or business self-recovery mechanisms after being triggered. Executing a high-level response process based on the initial alarm status could lead to unnecessary actions or resource allocation. By identifying whether the trend of indicator changes has entered the recovery phase, a dynamic basis reflecting the current actual situation can be provided for subsequent decision-making processes.

[0054] In some scenarios, the visual analysis module 221 can determine whether a trend is in a recovery state by identifying features of the trend at the end of the time axis in at least one image. For example, it can analyze whether the trend curve shows an upward trend, a convergence of fluctuation amplitude, or a plateau shape at the end of the time axis. When the direction of change in the end region is opposite to that of the abnormal phase or tends to stabilize, it can be determined that the trend has entered a recovery state. By determining the recovery state based on the end region of the time axis, the visual analysis results can reflect the real-time changes of the indicators, thereby supporting subsequent dynamic decision-making adjustments.

[0055] In some cases, aggregated event information can be formed based on textual information, visual analysis results, and event context information, and then sent (321) to the decision layer 230 for subsequent processing strategy generation. The aggregated event information may include structured visual evidence, event description information, and trend status indicators, thereby providing a unified input for the decision layer.

[0056] During the long-term operation of an application system, a large amount of experiential information related to alarm event handling is usually accumulated in the form of historical processing records, review documents, or operating procedures. However, this information is mostly in unstructured form and is difficult to automatically utilize when an alarm event occurs, thus limiting the supporting role of historical experience in real-time decision-making. In some cases, the multimodal analysis layer 220 may include a retrieval module 222. The retrieval module 222 can be used to obtain reference information 214 related to the alarm event. For example, the retrieval module 222 can retrieve historical alarm events similar to the current alarm event from an internal knowledge base or other data sources based on event text information and visual analysis results, and obtain corresponding reference processing strategies, historical processing records, or contextual experiential information.

[0057] In some cases, the retrieval module 222 can be implemented by a knowledge retrieval module or an intelligent processing unit. For example, as an optional implementation, the retrieval module 222 can be implemented by a knowledge retrieval agent in a multi-agent collaborative architecture. The knowledge retrieval agent can be used to incorporate historical experience information into the current decision-making process, thereby enhancing the contextual basis for generating processing strategies.

[0058] In some cases, a handling strategy for alarm events can be provided. This strategy is based on textual information and visual analysis results, and it indicates at least one of the response level and handling action for the alarm event. For example, system 200 can perform fusion analysis on aggregated information from the visual analysis module and the retrieval module through decision layer 230 to generate structured response level identifiers and corresponding candidate handling actions.

[0059] refer to Figure 2In some cases, the decision layer 230 may include a decision module 231. The decision module 231 can be used to generate a processing strategy for alarm events based on aggregated event information from the multimodal analysis layer 220. For example, the decision module 231 can be implemented by a rule engine module, a strategy generation model, or an intelligent processing unit. Alternatively, the decision module 231 can be implemented by a decision agent in a multi-agent collaborative architecture. The decision agent can synthesize visual analysis results, reference information 214, and processing rules 213 to determine the response level or processing action for the alarm event.

[0060] In some scenarios, the decision layer 230 may include a condition execution module 232 for obtaining a processing rule 213 corresponding to the alarm event. The processing rule 213 may indicate at least one candidate triggering condition and a corresponding candidate processing action. For example, the processing rule 213 may be derived from a Standard Operating Procedure (SOP) document.

[0061] As an example, the processing rules for a graphics processing unit (GPU) in an abnormal scenario may include: if the trend shows a continuous decline and does not recover, the response level is determined to be an incident level and an emergency coordination process is initiated. If the trend exhibits periodic fluctuation characteristics, the response level is determined to remain under observation. If it is determined to be a false alarm, repeated alarms within a certain time window are blocked. The conditional execution module 232 can parse the above processing rules and convert the triggering conditions into structured logical variables. Furthermore, the conditional execution module 232 can verify the triggering conditions item by item based on the visual analysis results, and only determine the corresponding candidate processing action as an executable processing action when the condition is met.

[0062] In some cases, a model can be used to obtain a processing strategy. The processing strategy is output by the model according to a predetermined priority strategy, based on at least one of the following: textual information, visual analysis results, and reference information and processing rules. For example, the model can be implemented as a decision module 231. The model can receive structured aggregated event information and output a response level and corresponding processing action. The model-generated results can be further passed to a conditional execution module 232 for rule consistency verification to ensure that the output conforms to preset operational constraints.

[0063] See Figure 3 In some cases, decision module 231 can determine (322) the priority of each piece of information for the decision based on a predetermined priority strategy. The predetermined priority strategy can be used to specify the order of adjudication or coverage rules for different information sources in conflict situations. For example, it can be specified that the recovery status determination rule has a higher priority.

[0064] In some situations, a pre-defined prioritization strategy can indicate that visual analysis results take precedence over textual information during the acquisition and processing of information. For example, if an event title or text description suggests an anomaly, but the visual analysis results indicate that no abnormal pattern has been identified, the trend pattern judgment result can be prioritized as the basis for decision-making. By using trend pattern recognition results as the core source of evidence, decisions are based on the structured analysis of continuously changing data, thereby improving the intuitiveness and accuracy of response level determination.

[0065] In some scenarios, a predefined priority strategy can instruct a response to visual analysis results indicating a recovery trend, thereby lowering the response level of the alarm event. For example, the visual analysis results might indicate an abnormal trend, but the trend's end shows a continuous upward trend approaching historical normal levels. The decision module can then adjust the response level to either a risk alert or continuous monitoring. The recovery status determination can have a higher priority in the priority hierarchy, meaning it can trigger degrade logic more frequently when other abnormal characteristics exist. This high-priority coverage mechanism avoids over-responding to recovered events.

[0066] As an example, decision module 231 can execute a multi-dimensional priority evaluation process to achieve a logical mapping from perceived data to execution instructions. For instance, decision module 231 can receive structured input from multimodal analysis layer 220, which may include at least textual information representing visual analysis results, retrieved reference information, and alarm events. Furthermore, decision module 231 can perform hierarchical judgment based on a predetermined priority strategy. For example, hierarchical judgment includes a recovery status determination phase. Decision module 231 prioritizes extracting recovery status information from the visual analysis results. If the visual feature indicates that the indicator is in a recovery state, then according to the predetermined priority strategy, the alarm information in the text can be ignored, and the event response level can be automatically downgraded to the observation level. By introducing a priority-based hierarchical control mechanism, the decision results can better reflect the actual changes in the indicators.

[0067] Continue to refer to Figure 3 The standard operating procedure and the real-time visual analysis results can be dynamically integrated through the conditional execution module 232. For example, the decision module 231 can send a (323) conditional execution request to the conditional execution module 232.

[0068] In some cases, in response to a conditional execution request, the conditional execution module 232 can perform a conditional matching operation (324). For example, the conditional execution module 232 can parse standard operation flow text, extract conditional descriptions and operation instructions from it, and convert the conditional descriptions into at least one verifiable candidate triggering condition and the operation instructions into corresponding candidate processing actions. Further, the conditional execution module 232 can match and verify at least one candidate triggering condition with the visual analysis results from the visual analysis module 221, and determine the corresponding candidate processing action as an executable action when the verification is satisfied.

[0069] By matching and analyzing the rules in standard operating procedures with visual analysis results, dynamic execution of processing rules can be achieved. This allows processing decisions to incorporate real-time visual features, rather than relying solely on alarm text descriptions. In traditional alarm handling solutions, standard operating procedures often include descriptions such as "abrupt change," "gap," and "significant decline." Without visual analysis, the model may not accurately understand these descriptions or determine their validity, leading to a decrease in alarm handling accuracy. By correlating and verifying rule execution conditions with visual trend features, erroneous executions caused by semantic ambiguity or delayed state updates can be avoided. Under this mechanism, executable processing actions must simultaneously satisfy both rule conditions and visual trend support. In this way, processing procedures that previously relied on manual confirmation can be safely executed with verifiable evidence, thereby improving the overall reliability and automation of the processing flow.

[0070] Continue to refer to Figure 3 In some cases, after completing the condition matching operation, the condition execution module 232 may send an execution suggestion (325) to the decision module 231. For example, the execution suggestion may include: a Boolean flag indicating whether the execution conditions are met, a list of met trigger conditions, and information such as the recommended processing action or response level.

[0071] As an example, a processing rule determined based on standard operating procedures indicates that if the system load index continuously decreases by more than a predetermined amount and lasts for more than 10 minutes, a service restart operation should be performed. The visual analysis results output by the visual analysis module 221 indicate that the index change trend shows an abnormal pattern of continuous decline, with a decrease of approximately 35% and a duration of 15 minutes. The conditional execution module 232 can perform item-by-item matching and verification between the rule conditions and the visual analysis results. If the verification results show that the decrease exceeds the predetermined threshold and the duration exceeds the threshold time, the conditional execution module 232 can mark "execute service restart operation" and "call recovery interface" as executable processing actions and send them to the decision module 231 as execution suggestions.

[0072] In some situations, decision module 231 can determine (326) the final processing strategy. For example, the processing strategy may include: the response level of the alarm event, one or more executable response actions, the scope of objects to be notified, etc. If there is a conflict between the execution suggestion and the priority overriding logic, such as when the indicator has entered the recovery state, decision module 231 may give priority to the recovery overriding logic, cancel the automatic execution action and reduce the response level of the alarm event.

[0073] Return to reference Figure 2 System 200 may include an execution and feedback layer 240. The execution and feedback layer 240 can be used to implement corresponding processing actions according to the processing strategy generated by the decision layer 230, and record and provide feedback on the execution results, thereby forming a closed-loop processing flow. For example, the execution and feedback layer 240 may include an execution feedback module 245. The execution feedback module 245 can be implemented by a linkage feedback agent in a multi-agent collaborative architecture. The linkage feedback agent can be used to receive processing strategies, trigger automated actions, coordinate cross-system linkages, and generate execution result feedback information.

[0074] refer to Figure 3 In some cases, the decision module 231 can send a processing strategy (331) to the execution feedback module 245. The execution feedback module 245 can execute the corresponding processing action based on the processing strategy. For example, the execution feedback module 245 can execute a linkage operation (332). The linkage operation may include: synchronizing event status between different operation and maintenance platforms, pushing alarm results to multiple terminal devices or management platforms, writing event conclusions into the event log, etc.

[0075] Alternatively or additionally, the execution feedback module 245 may perform corresponding processing actions by sending (333) automated actions to one or more application systems 305. For example, the automated actions may be pre-defined operation instructions in the system for the business or resources involved in the alarm event. The one or more application systems 305 may include gateway layer systems, publishing platforms, scaling services, or database management systems, etc. For example, if the processing policy indicates that the current event is due to system pressure caused by traffic overload, the automated actions may include sending a rate limiting instruction to the gateway layer system. If the processing policy identifies that the anomaly is caused by a specific version release, the automated actions may include sending a version rollback instruction to the publishing platform.

[0076] In some cases, the execution and feedback layer 240 can store (334) multi-source information, visual analysis results, processing strategies, and execution results of processing actions. For example, during an alarm processing process, the visual analysis module and retrieval module in the multimodal analysis layer 220, as well as the decision module and conditional execution module in the decision layer 230, can respectively complete processing tasks such as trend analysis, reference information acquisition, and processing strategy generation. The execution feedback module 245 can record the information generated at each stage in association, thereby forming a complete processing link information for the corresponding alarm event. By uniformly storing the alarm event input information, the analysis results of each intelligent processing unit, and the final execution results, the event processing process can be made interpretable and traceable, and provide a reference for subsequent event processing.

[0077] In some scenarios, the execution feedback module 245 can update the reference information in the system based on stored multi-source information, visual analysis results, processing strategies, and the execution results of processing actions. For example, the execution feedback module 245 can structure and organize the trend of indicator changes, the processing strategies adopted, and the execution effects of the corresponding event, and write them into the internal knowledge base, thereby updating the reference information used for retrieval module calls. By associating and storing the actual handling results with the corresponding trend characteristics, it is possible to retrieve historical cases with verified processing results when similar trend patterns or similar event descriptions appear, thus supporting the subsequent decision-making process.

[0078] In some cases, the execution feedback module 245 can also update the model used in the system based on the execution results. For example, the execution feedback module 245 can use the stored information as sample data to optimize parameters or adjust strategies for the decision-making model or visual analysis model. This allows the model to continuously refine its judgment of the relationship between trend patterns and processing actions based on actual execution results. In some cases, model updates can be performed periodically or triggered after a predetermined number of event samples have been accumulated.

[0079] Through the above method, after completing the analysis, decision-making, and coordinated execution of an alarm event, the system can automatically record the complete decision chain, including original input information, intermediate analysis results, decision-making process, and execution results, and store this information in a structured form. The stored information can serve as new knowledge or training data for subsequent updates to reference information or model parameters in the system, thereby forming a self-learning processing mechanism that continuously optimizes based on actual handling results. In this way, the system can improve the accuracy and consistency of its processing strategy generation when handling similar alarm events in the future.

[0080] The alarm handling process of System 200 is illustrated below with a specific example. As an example, System 200 can receive multi-source information related to an alarm event, where the alarm event title is "Sudden Drop in GPU Resource Supply," and the text information includes resource model identifier, region identifier, and event tag information. Simultaneously, System 200 also receives multiple images representing the trends of indicator changes. These multiple images correspond to changes in GPU resource supply indicators over a 30-minute time range, a 3-hour time range, and a historical time range for the same period.

[0081] In some cases, the visual analysis module 221 in the multimodal analysis layer 220 can perform morphological analysis processing on multiple received trend images. The visual analysis module 221 can perform a unified analysis of indicator changes across different time ranges based on the overall morphological characteristics of the trend curves in the images. For example, the visual analysis module 221 can identify whether there are abrupt changes or sharp drops in the trend curves within short time windows, and determine whether the trend over a longer time range exhibits a continuous downward trend. The visual analysis module 221 can also compare and analyze the morphological consistency between the current time range trend and historical trends of the same period. Furthermore, the visual analysis module 221 can identify the change state of the trend curve in the region at the end of the time axis to determine whether the indicator trend is in a stable or recovering state.

[0082] In this example, the visual analysis results determined by the visual analysis module 221 indicate that the trend curves corresponding to the three time ranges all fluctuate around a certain value, and no sudden drops, abnormal oscillations, or continuous downward patterns are detected. The visual analysis results also indicate that the current trend curve is consistent with the historical curves of the same period in terms of the magnitude of change and the overall shape. At the same time, the trend curve shows a stable state in the end region of the time axis.

[0083] In some cases, the retrieval module 222 in the multimodal analysis layer 220 can construct retrieval conditions based on event text information and visual analysis results. For example, resource type identifiers, regional information, and indicator category information can be extracted from the text information, and combined with the trend anomaly morphological features indicated in the visual analysis results, a matching retrieval can be performed on the historical event knowledge set. Furthermore, the system 200 can structure and organize the event title, text tag information, trend image corresponding time range, visual analysis results, and retrieval-obtained reference information to form aggregated event information, and use this aggregated event information as input data for the decision layer 230.

[0084] In some cases, the conditional execution module 232 in the decision layer 230 can parse the standard operating procedure text associated with the alarm event to extract the triggering conditions and corresponding processing actions contained therein. For example, in this example, the standard operating procedure includes processing logic defined based on abnormal decline state, recovery state, and periodic fluctuation characteristics.

[0085] In some cases, the conditional execution module 232 can convert the text description in the standard operating procedure into structured trigger conditions and verify each trigger condition based on the trend pattern characteristics output by the visual analysis module 221. In this example, the conditional execution module 232 determines that the trigger condition indicating an abnormally continuous decline is not met, and also determines that the trend recovery condition is not triggered, while the condition indicating that the trend conforms to historical cycle patterns is met.

[0086] In some situations, the decision module 231 can comprehensively judge textual information, visual analysis results, and reference information based on a predetermined priority strategy. For example, when the event title contains abnormal prompts such as "sudden drop," but the visual analysis results do not verify the corresponding abnormal trend, the decision module 231 can prioritize the visual analysis results to avoid misjudgment based solely on text keywords. In this example, since the visual analysis results indicate that the indicator change is within a normal fluctuation range, and the historical reference information supports a periodic change scenario, the decision module 231 outputs an instruction to continue observation, while simultaneously determining that the current event state is stable and classifying the degree of abnormality as normal fluctuation.

[0087] In this way, by performing visual analysis based on the changing trend patterns of trend images related to alarm events, and combining this with structured verification using historical reference information and triggering conditions in standard operating procedures, the system can more accurately determine the status of alarm events even when there are discrepancies or conflicts in multi-source information. For example, when the event title indicates an anomaly but the trend pattern does not reflect a true anomaly, the system can verify the alarm based on visual evidence, thereby avoiding unnecessary escalation based solely on textual information. This reduces the likelihood of false triggering of response actions and improves the consistency and reliability of alarm handling decisions.

[0088] The proposed scheme enables a phased processing architecture that is collaboratively completed by multiple agents. Specifically, different agents can undertake responsibilities such as trend and pattern analysis, historical knowledge acquisition, rule condition verification, and comprehensive decision generation, breaking down complex alarm processing tasks into multiple clearly defined processing stages. This approach significantly reduces the human intervention load in the alarm processing process. Each processing stage can perform analysis and judgment within its respective area of ​​expertise and interact through structured information, thereby improving the consistency and stability of the overall judgment results while ensuring processing efficiency.

[0089] The proposed technical solution improves the accuracy and consistency of alarm processing decisions. By using the changing patterns in trend images as objective analysis criteria, and combining a unified decision logic hierarchy and standardized level mapping rules, alarm events from different sources are processed using consistent judgment standards, thereby reducing decision-making biases caused by experience differences or subjective judgments. In practical application scenarios, compared with manual processing methods, the proposed solution demonstrates more stable judgment results in critical event level determination tasks, effectively reducing misjudgments and omissions, and improving the consistency of decision results across different processing scenarios.

[0090] The proposed technical solution enhances the transparency and traceability of alarm handling processes. During the execution and feedback phases, the entire alarm handling process can be recorded in a structured manner. Different processing stages can be completed by clearly defined intelligent processing units, and transmitted through structured information. This creates a complete decision-making chain record. When it is necessary to review or analyze historical events, the system's judgment criteria at each stage can be traced back based on the stored processing chain information, thereby supporting process optimization and experience accumulation.

[0091] The proposed technical solution can improve the reliability and automation level of standard operating procedures. The triggering conditions in the rules can be dynamically matched and verified with the trend and pattern characteristics output by the visual analysis module. When the corresponding conditions are supported by trend evidence reflected in the actual operating state, the corresponding processing action is executed. This approach avoids improper automated operations caused by unclear rule descriptions or inconsistencies with actual conditions, enabling processing steps that originally required manual confirmation to be executed automatically when there is sufficient evidence.

[0092] Experimental and practical application results demonstrate that the alarm processing scheme based on multimodal information fusion analysis and multi-agent collaborative processing mechanism can achieve stable automated processing capabilities in complex business system environments. Compared with related technical solutions, the proposed solution shows improvements in processing efficiency, decision consistency, and system operation and maintenance costs, and is applicable to alarm processing scenarios in large-scale distributed systems, thereby enhancing the overall system operation assurance capability.

[0093] In summary, by using images representing the changing trends of indicators as key analytical evidence, and combining them with multi-source textual information, historical reference information, and processing rules for collaborative processing, the proposed technical solution constructs a visual evidence-driven alarm processing mechanism. In this mechanism, the model's reasoning process no longer relies solely on textual descriptions or preset rules, but is constrained by trend morphology information corresponding to the actual operating state, enabling the decision-making process to be verified and corrected based on objective changing characteristics. Furthermore, through a multi-agent collaborative architecture, functions such as visual analysis, knowledge retrieval, rule verification, and strategy decision-making are divided in responsibilities and structured for collaboration, allowing different types of information to complete fusion reasoning and cross-validation within a unified framework. This approach improves the efficiency of alarm processing.

[0094] Example process Figure 4 A flowchart of an example method 400 for alarm processing is shown for several scenarios. Method 400 can be implemented in an electronic device with processing capabilities. At block 410, multi-source information related to an alarm event is received, including textual information about the alarm event and at least one image associated with an indicator of the alarm event. The at least one image represents a trend in the indicator's change. At block 420, a visual analysis result of the at least one image is obtained, the visual analysis result being obtained based on the morphology of the trend in the at least one image. At block 430, a processing strategy for the alarm event is provided, the processing strategy being obtained based on the textual information and the visual analysis result, and the processing strategy indicating at least one of a response level and a processing action for the alarm event.

[0095] In some cases, the visual analysis results indicate at least one of the following: the presence of an anomalous pattern in the trend of change in at least one of the images, the duration of the anomalous pattern, or the degree of difference between a first trend of change indicated by a first image and a second trend of change indicated by a second image in at least one of the images, wherein the first trend of change is the trend of change of the indicator in the current time range and the second trend of change is the trend of change of the indicator in a historical time range.

[0096] In some cases, obtaining visual analysis results includes: extracting structural features representing morphological trends based on at least one image; and generating visual analysis results based on the structural features.

[0097] In some cases, visual analysis results also indicate whether a trend is in a recovery state, and obtaining visual analysis results also includes determining whether a trend is in a recovery state by identifying features of the trend in the end region of the time axis in at least one image.

[0098] In some cases, the processing strategy is obtained by: obtaining reference information related to the alarm event, including contextual information related to the alarm event and reference processing strategies for at least one historical event; obtaining processing rules corresponding to the alarm event, the processing rules indicating at least one candidate triggering condition and a corresponding candidate processing action; and using a model to obtain the processing strategy, which is output by the model according to a predetermined priority strategy, based on textual information, visual analysis results, and at least one of the reference information and processing rules.

[0099] In some cases, the acquisition of processing strategies includes: matching visual analysis results with at least one candidate triggering condition; and based on the matching results and reference information, acquiring at least one of the response level and processing action for the alarm event.

[0100] In some cases, a predetermined priority strategy indicates that visual analysis results have a higher priority than text information during the acquisition and processing of the strategy.

[0101] In some cases, the predetermined priority strategy indicates that, in response to visual analysis results indicating that the trend of change is in a recovery state, the response level of the alarm event is reduced.

[0102] In some cases, method 400 also includes: performing processing actions; and storing multi-source information, visual analysis results, processing strategies, and the results of the processing actions.

[0103] Example devices and equipment A corresponding apparatus for implementing the above methods or processes is also provided. Figure 5 A schematic block diagram of an example device 500 for alarm processing under certain conditions is shown. Device 500 can be implemented as or included in an electronic device. The various modules / components in device 500 can be implemented by hardware, software, firmware, or any combination thereof.

[0104] like Figure 5As shown, the device 500 includes: a receiving module 510 configured to receive multi-source information related to an alarm event, the multi-source information including text information of the alarm event and at least one image related to an indicator of the alarm event, the at least one image representing a trend of change in the indicator; an acquisition module 520 configured to acquire visual analysis results of the at least one image, the visual analysis results being acquired based on the morphology of the trend of change in the at least one image; and a providing module 530 configured to provide a processing strategy for the alarm event, the processing strategy being acquired based on the text information and the visual analysis results, and the processing strategy indicating at least one of the response level and processing action of the alarm event.

[0105] In some cases, the visual analysis results indicate at least one of the following: the presence of an anomalous pattern in the trend of change in at least one of the images, the duration of the anomalous pattern, or the degree of difference between a first trend of change indicated by a first image and a second trend of change indicated by a second image in at least one of the images, wherein the first trend of change is the trend of change of the indicator in the current time range and the second trend of change is the trend of change of the indicator in a historical time range.

[0106] In some cases, the acquisition module 520 is further configured to: extract structural features representing morphological trends based on at least one image; and generate visual analysis results based on the structural features.

[0107] In some cases, the visual analysis results also indicate whether the trend of change is in a recovery state, and the acquisition module 520 is further configured to determine whether the trend of change is in a recovery state by identifying features of the trend of change in the end region of the time axis in at least one image.

[0108] In some cases, the processing strategy is obtained by: obtaining reference information related to the alarm event, including contextual information related to the alarm event and reference processing strategies for at least one historical event; obtaining processing rules corresponding to the alarm event, the processing rules indicating at least one candidate triggering condition and a corresponding candidate processing action; and using a model to obtain the processing strategy, which is output by the model according to a predetermined priority strategy, based on textual information, visual analysis results, and at least one of the reference information and processing rules.

[0109] In some cases, the acquisition of processing strategies includes: matching visual analysis results with at least one candidate triggering condition; and based on the matching results and reference information, acquiring at least one of the response level and processing action for the alarm event.

[0110] In some cases, a predetermined priority strategy indicates that visual analysis results have a higher priority than text information during the acquisition and processing of the strategy.

[0111] In some cases, the predetermined priority strategy indicates that, in response to visual analysis results indicating that the trend of change is in a recovery state, the response level of the alarm event is reduced.

[0112] In some cases, it further includes a processing module configured to: perform processing actions; and store multi-source information, visual analysis results, processing strategies, and the results of the processing actions.

[0113] The modules included in device 500 can be implemented in various ways, including software, hardware, firmware, or any combination thereof. In some cases, one or more modules can be implemented using software and / or firmware, such as machine-executable instructions stored on a storage medium. In addition to or as an alternative to machine-executable instructions, some or all of the units in device 500 can be implemented at least partially by one or more hardware logic components. By way of example and not limitation, exemplary types of hardware logic components that can be used include field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard parts (ASSPs), systems on a chip (SOCs), complex programmable logic devices (CPLDs), and so on.

[0114] Figure 6 A block diagram of an electronic device 600 in which one or more examples may be implemented is shown. It should be understood that... Figure 6 The electronic device 600 shown is merely exemplary and should not be construed as limiting the functionality and scope of the examples described herein. Figure 6 The illustrated electronic device 600 can be used to implement the electronic device 110 discussed above.

[0115] like Figure 6 As shown, electronic device 600 is in the form of a general-purpose electronic device. Components of electronic device 600 may include, but are not limited to, one or more processing units or processors 610, memory 620, storage device 630, one or more communication units 640, one or more input devices 650, and one or more output devices 660. Processor 610 may be a physical or virtual processor and is capable of performing various processes according to programs stored in memory 620. In a multiprocessor system, multiple processors execute computer-executable instructions in parallel to improve the parallel processing capability of electronic device 600.

[0116] Electronic device 600 typically includes multiple computer storage media. Such media can be any accessible media that is accessible to electronic device 600, including but not limited to volatile and non-volatile media, removable and non-removable media. Memory 620 can be volatile memory (e.g., registers, cache, random access memory (RAM)), non-volatile memory (e.g., read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory), or some combination thereof). Storage device 630 can be removable or non-removable media and can include machine-readable media, such as flash drives, disks, or any other media that can be used to store information and / or data and can be accessed within electronic device 600.

[0117] Electronic device 600 may further include additional removable / non-removable, volatile / non-volatile storage media. Although not explicitly stated... Figure 6 As shown, disk drives for reading from or writing to removable, non-volatile disks (e.g., "floppy disks") and optical disk drives for reading from or writing to removable, non-volatile optical disks can be provided. In these cases, each drive can be connected to a bus (not shown) via one or more data media interfaces. Memory 620 may include computer program product 626 having one or more program modules configured to perform various methods or actions of various examples.

[0118] The communication unit 640 enables communication with other electronic devices via a communication medium. Additionally, the functionality of the components of the electronic device 600 can be implemented using a single computing cluster or multiple computing machines capable of communicating via communication connections. Therefore, the electronic device 600 can operate in a networked environment using logical connections to one or more other servers, networked personal computers, or another network node.

[0119] Input device 650 can be one or more input devices, such as a mouse, keyboard, trackball, etc. Output device 660 can be one or more output devices, such as a monitor, speaker, printer, etc. Electronic device 600 can also communicate with one or more external devices (not shown) via communication unit 640 as needed. These external devices include storage devices, display devices, etc., and can communicate with one or more devices that enable user interaction with electronic device 600, or with any device that enables electronic device 600 to communicate with one or more other electronic devices (e.g., network card, modem, etc.). Such communication can be performed via an input / output (I / O) interface (not shown).

[0120] A computer-readable storage medium is provided that stores computer-executable instructions thereon, wherein the computer-executable instructions are executed by a processor to implement the methods described above. A computer program product is also provided, which is tangibly stored on a non-transitory computer-readable medium and includes computer-executable instructions, which are executed by a processor to implement the methods described above.

[0121] The flowcharts and / or block diagrams of the methods, apparatus, devices, and computer program products referred to herein describe various aspects. It should be understood that each block of the flowcharts and / or block diagrams, as well as combinations of blocks in the flowcharts and / or block diagrams, can be implemented by computer-readable program instructions.

[0122] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that, when executed by the processor of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner; thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0123] Computer-readable program instructions can be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions that execute on the computer, other programmable data processing apparatus, or other device to perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0124] The flowcharts and block diagrams in the accompanying figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products under various scenarios. In this respect, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction, which contains one or more executable instructions for implementing the specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than those shown in the figures. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0125] Various examples have been described above. The foregoing descriptions are exemplary and not exhaustive, nor are they limited to the disclosed implementations. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described implementations. The terminology used herein is chosen to best explain the principles, practical applications, or improvements to technology in the market, or to enable others skilled in the art to understand the various implementations disclosed herein.

Claims

1. A method for alarm processing, comprising: Receive multi-source information related to an alarm event, the multi-source information including text information of the alarm event and at least one image related to an indicator of the alarm event, the at least one image representing the changing trend of the indicator; Obtain visual analysis results for the at least one image, the visual analysis results being obtained based on the morphology of the changing trend in the at least one image; as well as A processing strategy for the alarm event is provided, the processing strategy being obtained based on the text information and the visual analysis results, and the processing strategy indicating at least one of the response level and processing action of the alarm event.

2. The method of claim 1, wherein the visual analysis result indicates at least one of the following: In the at least one of the images, does the trend of change exhibit any abnormal patterns? The duration of the abnormal morphology, or The degree of difference between a first trend of change indicated by a first image and a second trend of change indicated by a second image in the at least one image, wherein the first trend of change is the trend of change of the indicator in the current time range and the second trend of change is the trend of change of the indicator in a historical time range.

3. The method according to claim 1, wherein obtaining the visual analysis result includes: Based on the at least one image, extract structural features representing the morphological trend of change; as well as The visual analysis results are generated based on the structured features.

4. The method according to claim 2, wherein the visual analysis result further indicates whether the trend of change is in a recovery state, and obtaining the visual analysis result further includes: By identifying features of the change trend in the region at the end of the time axis in the at least one image, it is determined whether the change trend is in a recovery state.

5. The method according to claim 1, wherein the processing strategy is obtained in the following manner: Obtain reference information related to the alarm event, the reference information including context information related to the alarm event and reference processing strategies for at least one historical event; Obtain the processing rule corresponding to the alarm event, wherein the processing rule indicates at least one candidate triggering condition and a corresponding candidate processing action; as well as The decision module obtains the processing strategy, which is output by the decision module according to a predetermined priority strategy, based on at least one of the text information, the visual analysis results, the reference information, and the processing rules.

6. The method of claim 5, wherein obtaining the processing strategy comprises: The visual analysis results are matched with the at least one candidate triggering condition; as well as Based on the matching results and the reference information, at least one of the response level and processing action for the alarm event is obtained.

7. The method of claim 5, wherein the predetermined priority strategy indicates that, during the acquisition of the processing strategy, the visual analysis result has a higher priority than the text information.

8. The method of claim 5, wherein the predetermined priority strategy indicates: In response to the visual analysis results indicating that the trend of change is in a recovery state, the response level of the alarm event is reduced.

9. The method according to claim 1, further comprising: Perform the aforementioned processing action; as well as The system stores the multi-source information, the visual analysis results, the processing strategy, and the execution results of the processing actions.

10. An apparatus for alarm processing, comprising: The receiving module is configured to receive multi-source information related to an alarm event, the multi-source information including text information of the alarm event and at least one image related to an indicator of the alarm event, the at least one image representing the changing trend of the indicator; The acquisition module is configured to acquire visual analysis results of the at least one image, the visual analysis results being acquired based on the morphology of the change trend in the at least one image; as well as A module is configured to provide a processing strategy for the alarm event, the processing strategy being obtained based on the text information and the visual analysis results, and the processing strategy indicating at least one of the response level and processing action of the alarm event.

11. An electronic device, comprising: At least one processor; as well as At least one memory coupled to the at least one processor and storing instructions for execution by the at least one processor, the instructions causing the electronic device to perform the method according to any one of claims 1 to 9 when executed by the at least one processor.

12. A computer-readable storage medium having stored thereon computer-executable instructions that can be executed by a processor to implement the method according to any one of claims 1 to 9.

13. A computer program product tangibly stored in a computer storage medium and comprising computer-executable instructions that, when executed by a device, cause the device to perform the method according to any one of claims 1 to 9.

Images