Alarm processing method and device

Abstract

The present specification provides an alarm processing method and device, the method comprises: acquiring a query text, and inputting the query text into a first large language model; generating identification information of a reference product based on the query text by the first large language model; searching in a real-time database based on the identification information of the reference product to obtain real-time related information of the reference product from the real-time database; wherein the real-time database is used to store the corresponding relationship between the identification information and the real-time related information of the product; based on the query text, the identification information and the real-time related information of the reference product, the identification information of the target product related to the query text is determined.

Description

Technical Field

[0001] This specification relates to one or more embodiments in the field of artificial intelligence, and more particularly to an alarm processing method and apparatus. Background Technology

[0002] In modern information technology systems, with the continuous expansion of system scale and the increasing complexity of architecture, the number of various software and hardware components is growing exponentially. These systems typically consist of a large number of interdependent nodes, services, or instances, collectively supporting the stable operation of critical functions. To ensure high availability and reliability, system maintenance generally relies on monitoring and alarm mechanisms to perceive and identify anomalies in real time. Therefore, how to implement system monitoring and alarms in practical applications has become a highly relevant issue. Summary of the Invention

[0003] In view of the above, one or more embodiments of this specification provide the following technical solutions: According to a first aspect of one or more embodiments of this specification, an alarm processing method is provided, the method comprising: Obtain real-time data streams from data sources that can be used for alarm determination, corresponding to at least one running instance; Identify abnormal data units in the real-time data stream and generate original alarm events based on the abnormal data units identified from the real-time data stream; Obtain the original alarm events within a preset time period, and merge the related original alarm events into a composite alarm event. Alarm processing is performed based on the composite alarm event.

[0004] According to a second aspect of one or more embodiments of this specification, an alarm processing apparatus is provided, the apparatus comprising: The acquisition module acquires real-time data streams from a data source that can be used for alarm judgment, corresponding to at least one running instance; The identification module identifies abnormal data units in the real-time data stream and generates original alarm events based on the abnormal data units identified from the real-time data stream. The merging module acquires the original alarm events within a preset time period and merges the related original alarm events into a composite alarm event. The alarm module performs alarm processing based on the composite alarm events.

[0005] According to a third aspect of one or more embodiments of this specification, an electronic device is provided, comprising: processor; Memory used to store processor-executable instructions; The processor executes the executable instructions to implement the steps of the method as described in any of the above embodiments.

[0006] According to a fourth aspect of one or more embodiments of this specification, a computer-readable storage medium is provided that stores computer instructions thereon, which, when executed by a processor, implement the steps of the method as described in any of the above embodiments.

[0007] According to a fifth aspect of one or more embodiments of this specification, a computer program product is provided, comprising a computer program / instructions that, when executed by a processor, implement the steps of the method as described in any of the above embodiments.

[0008] As can be seen from the above embodiments, firstly, a real-time data stream can be obtained from a data source that can be used for alarm judgment corresponding to at least one running instance. Then, abnormal data units in the real-time data stream can be identified, and original alarm events can be generated based on the abnormal data units identified from the real-time data stream. Then, original alarm events within a preset time period can be obtained, and the original alarm events that are related to each other in the obtained original alarm events can be merged into a composite alarm event. Finally, alarm processing can be performed based on the composite alarm event.

[0009] This approach separates anomaly identification from final alarm processing. After identifying anomaly data, raw alarm events are generated, but related raw alarm events are further merged into composite alarm events, which are then used for alarm processing. This reduces the number of alarm events and increases their information density, thereby improving operational efficiency and shortening fault recovery time. Attached Figure Description

[0010] Figure 1 This is a schematic diagram of an alarm processing system provided in an exemplary embodiment.

[0011] Figure 2 This is a flowchart of an alarm processing method provided in an exemplary embodiment.

[0012] Figure 3 This is a schematic diagram of an alarm processing flow provided in an exemplary embodiment.

[0013] Figure 4 This is a schematic diagram of the structure of a device provided in an exemplary embodiment.

[0014] Figure 5 This is a block diagram of an alarm processing apparatus provided in an exemplary embodiment. Detailed Implementation

[0015] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0016] The user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this manual are all information and data authorized by the user or fully authorized by all parties. The collection, use and processing of related data shall comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation portals shall be provided for users to choose to authorize or refuse.

[0017] In related technologies, system monitoring and alarming often employ methods based on fixed rules and static thresholds. These methods independently assess single performance metrics (e.g., response time, throughput, resource utilization), triggering an alarm of the corresponding level once a metric exceeds a preset threshold. While this mechanism is effective in small or simple systems, it has limitations in large-scale, highly coupled, complex system environments.

[0018] Because of the close dependencies between components within a system, a low-level or localized failure (e.g., network partitioning, core service interruption, shared resource contention) often triggers a chain reaction, causing abnormal behavior simultaneously on multiple upper-level components or related nodes. In this situation, traditional alerting mechanisms, lacking context awareness, generate a large number of repetitive, time-intensive, and logically related alert events, creating an "alert storm." These alerts are not only numerous but also mostly derivative, drowning out the signals that truly reflect the root cause. This makes it difficult for operations and maintenance personnel to quickly locate the source of the problem, prolonging the time required for troubleshooting and remediation.

[0019] Furthermore, existing alarm level classifications typically determine alarm levels based solely on the instantaneous deviation of a single metric on a single node, failing to adequately consider the actual scope of the fault's impact and its multi-dimensional composite effects. For example, a moderately severe anomaly affecting dozens or even hundreds of service units may have a far greater overall service impact than a high-priority alarm on an isolated node. Similarly, when a node experiences anomalies in multiple key metrics simultaneously (e.g., increased latency, resource exhaustion, increased error rate), the potential risk is far greater than when only a single metric exceeds the limit. However, traditional alarm mechanisms cannot comprehensively assess these multi-dimensional, cross-instance anomaly patterns, leading to a mismatch between alarm levels and actual fault severity, thus affecting emergency response prioritization decisions and resource scheduling efficiency.

[0020] In response to the increasingly prominent problems of alarm overload and inaccurate classification in the operation and maintenance of complex systems, this specification provides a technical solution for alarm handling through one or more embodiments. The alarm handling mechanism in this specification has adaptive capabilities, and can intelligently aggregate and accurately classify alarm events based on system topology, service dependencies, and real-time operating status, thereby improving operation and maintenance efficiency, shortening fault recovery time, and enhancing the overall observability and resilience of the system.

[0021] In the technical solutions provided in one or more embodiments of this specification, a real-time data stream can first be obtained from a data source that can be used for alarm judgment corresponding to at least one running instance. Then, abnormal data units in the real-time data stream can be identified, and original alarm events can be generated based on the abnormal data units identified from the real-time data stream. Then, original alarm events within a preset time period can be obtained, and the original alarm events that are related to each other in the obtained original alarm events can be merged into a composite alarm event. Finally, alarm processing can be performed based on the composite alarm event.

[0022] This approach separates anomaly identification from final alarm processing. After identifying anomaly data, raw alarm events are generated, but related raw alarm events are further merged into composite alarm events, which are then used for alarm processing. This reduces the number of alarm events and increases their information density, thereby improving operational efficiency and shortening fault recovery time.

[0023] refer to Figure 1 , Figure 1 This is a schematic diagram of an alarm processing system provided in an exemplary embodiment.

[0024] The alarm handling system described above can be used to monitor and issue alarms for a specific system. For example... Figure 1As shown, the alarm processing system may include software components or system modules such as a data lake, rule engine, correlation analyzer, scoring model, and routing engine, which are responsible for performing specific types of tasks or providing core functions.

[0025] The aforementioned data lake can be used to uniformly store data collected from data sources corresponding to at least one running instance and used for alarm judgment, and processed through specific procedures such as format unification, metadata tagging, and semantic standardization.

[0026] The aforementioned rule engine can be used to continuously consume real-time data streams from the aforementioned data lake, identify abnormal data units in the real-time data stream, and generate original alarm events based on the abnormal data units identified from the real-time data stream.

[0027] The aforementioned correlation analyzer can be used to merge original alarm events within a specific time period into composite alarm events based on a specific alarm merging strategy.

[0028] The scoring model described above can be used to dynamically calculate the score corresponding to a composite alarm event, thereby determining the alarm level of the composite alarm event based on the score corresponding to any one of the composite alarm events.

[0029] The aforementioned routing engine can be used to accurately and efficiently deliver finalized composite alarm events to specific alarm recipients.

[0030] Combination Figure 1 ,refer to Figure 2 , Figure 2 This is a flowchart of an alarm processing method provided in an exemplary embodiment.

[0031] In this embodiment, the alarm processing method described above can be applied to an alarm processing system corresponding to a specific system (e.g., a database system), meaning that the alarm processing system can be used to monitor and issue alarms for that system. This alarm processing system can be deployed on any computing device, such as: a server containing a single physical host, a server cluster consisting of multiple independent physical hosts, a virtual server or cloud server hosted by a host cluster, a desktop computer, a laptop computer, a PC (Personal Computer), a PDA (Personal Digital Assistant), a tablet computer, etc.

[0032] The alarm handling method described above may include the following steps: Step 202: Obtain a real-time data stream from a data source that can be used for alarm determination, corresponding to at least one running instance.

[0033] In this embodiment, for a system, a running instance refers to a running software service entity that can be independently monitored and managed. A running instance typically has a unique identifier (e.g., instance ID, IP address plus port number, Pod name, etc.) and continuously generates metrics, logs, and events.

[0034] Specifically, in operating systems, a running instance generally refers to the executing entity of a process or thread. Alternatively, in object-oriented programming (OOP), an instance is a concrete object of a class, while a running instance is an object created and active during program execution. Or, in cloud platforms, a running instance typically refers to a virtual machine instance, i.e., a virtual server started by a user in the cloud. In practical applications, a running instance can be a process on a physical machine, a service in a virtual machine, a Docker container, a Kubernetes Pod, a cloud-hosted PaaS (Platform as a Service) instance, etc.; as long as it runs independently, is observable, and has a unique identifier, it is a running instance.

[0035] Taking database systems as an example, a running instance in a database system usually refers to a database instance that is in operation.

[0036] For at least one running instance in the system, a real-time data stream can be obtained from a data source corresponding to that at least one running instance that can be used for alarm judgment.

[0037] In some embodiments, all observable data sources that can be used for alarm judgment can be uniformly collected and standardized. After collecting various types of raw data from the data sources, specific processing such as format unification, metadata tagging, and semantic standardization can be performed on these raw data. Furthermore, the processed data can be finally aggregated into a unified storage layer (e.g., a data lake or time-series database) to provide complete and consistent data support for subsequent real-time alarm detection and historical backtracking analysis.

[0038] The data sources mentioned above may include monitoring metrics, logs, and / or system events.

[0039] Taking database systems as an example, monitoring metrics can include continuous capture of time-series performance indicators of components such as the database, operating system, and middleware using data collection tools (e.g., Prometheus NodeExporter, Telegraf, self-developed data collection agents, etc.). Typical metrics include: CPU utilization, memory utilization, queries per second (QPS), active connections, response time (RT), and disk I / O throughput. All metrics can be identified at the runtime instance level (e.g., instance ID, hostname, service type, etc.) to ensure traceability.

[0040] Logs can include structured or semi-structured log data collected from sources such as database error logs and application service logs using collection tools (e.g., Filebeat, Logtail, Loki Promtail, self-developed collection agents, etc.). Special attention should be paid to content containing standard log-level keywords such as ERROR, WARN, and FATAL, as well as key business-defined exception markers (e.g., "connection pool exhausted," "master-slave synchronization interrupted," etc.). Log records can also be associated with runtime instance metadata for easier contextual analysis.

[0041] System events can include discrete events describing changes in system state, obtained through event subscription mechanisms (e.g., Kubernetes Event Watch), platform APIs (e.g., cloud vendor RDS / OpenAPI), or operation and maintenance system notification channels. Typical events include instance migration, service restart, node scheduling, and the opening / closing of planned maintenance windows. Event data can carry explicit timestamps, operation types, and target resource identifiers to assist in alarm suppression (e.g., maintenance-period non-distraction) or root cause analysis.

[0042] In some embodiments, a data unit in a real-time data stream refers to the smallest, indivisible logical data item that constitutes the data stream. It is the basic unit that is generated, transmitted, processed, and consumed in a stream processing system.

[0043] During monitoring and alerting, a data unit in the real-time data stream can be a timestamped, context-rich, structured observable record. For example, a data unit can be a monitoring metric point like the following: { "instance_id": "db-01", "metric": "cpu_usage", "value": 78.5, "ts": "2026-01-04T05:30:00Z"}, which includes the instance identifier, monitoring metric name, monitoring metric value, and timestamp.

[0044] In practical applications, while storing the data collected from the aforementioned data sources and processed in a unified manner in a data lake, the raw data collected from these data sources (e.g., a log entry, a monitoring metric, a system event) can also be encapsulated into a message and sent to a message queue (e.g., Kafka, Pulsar, RocketMQ). Consumers (e.g., the alarm processing tool in the aforementioned monitoring and alarm module) can subscribe to this queue and consume these messages sequentially or in parallel, thereby enabling the reading of real-time data streams; each message is a basic data unit in the real-time data stream. Alternatively, a data lake supporting "stream and batch processing" can be used to continuously consume real-time data streams from the data lake used to uniformly store data collected from the aforementioned data sources and processed in a unified manner.

[0045] Step 204: Identify abnormal data units in the real-time data stream and generate original alarm events based on the abnormal data units identified from the real-time data stream.

[0046] In this embodiment, abnormal data units in the aforementioned real-time data stream can be identified. In practical applications, alarms are typically triggered by the identified abnormal data units. For each abnormal data unit identified from the real-time data stream, an original alarm event can be generated based on that data unit.

[0047] In some embodiments, abnormal data units can be identified from the aforementioned real-time data stream based on predefined rules.

[0048] Specifically, each data unit in the aforementioned real-time data stream can be matched against a preset anomaly identification rule (e.g., cpu_usage>90%). If a data unit matches this anomaly identification rule, then that data unit can be identified as an anomalous data unit.

[0049] In practical applications, the aforementioned anomaly identification rules can be stored in an anomaly identification rule base. The rule engine can load this rule base and, by consuming the real-time data stream, obtain each data unit within it. This allows the engine to match each data unit with anomaly identification rules in the rule base. If a data unit matches any anomaly identification rule in the rule base, that data unit can be identified as an anomalous data unit.

[0050] When the aforementioned rule engine determines that a data unit matches any anomaly identification rule in the anomaly identification rule base, it can generate an original alarm event based on that data unit. The original alarm event can refer to an initial alarm record directly generated by a single rule without aggregation, suppression, deduplication, or correlation analysis.

[0051] Step 206: Obtain the original alarm events within the preset time period, and merge the related original alarm events into a composite alarm event.

[0052] In this embodiment, to reduce the number of alarm events ultimately output, original alarm events within a preset time period can be acquired, and related original alarm events can be merged into composite alarm events. The preset time period can include multiple time periods in a sliding time window format, such as 8:00-8:05, 8:05-8:10, and 8:10-8:15. The sliding time window size for these three time periods is 5 minutes, and the sliding step is also 5 minutes. For a given time period, the original alarm events within that time period can refer to those whose event occurrence time (i.e., the actual time when the problem reflected by the alarm occurs, usually from the timestamp of the original data) falls within that time period; or, they can refer to those whose alarm generation time (i.e., the time when the alarm rule is matched and the original alarm event is created) falls within that time period.

[0053] In practical applications, the alarm processing system described above can maintain a sliding time window. Each time the sliding time window is slid, the correlation analyzer can obtain all the original alarm events within the sliding time window and analyze the correlation between these original alarm events.

[0054] When the correlation analyzer identifies related original alarm events from the original alarm events, it can merge the related original alarm events to generate corresponding composite alarm events.

[0055] In some embodiments, during the process of merging the original alarm events within the aforementioned preset time period, the original alarm events generated based on data units that match the same anomaly detection rules can be merged into a composite alarm event; and / or, the original alarm events generated based on data units from data sources corresponding to the same running instance can be merged into a composite alarm event.

[0056] Specifically, an original alarm event may contain a "rule_id", which is the identifier of the anomaly detection rule that the original alarm event matches. In this case, original alarm events with the same "rule_id" can be merged into a composite alarm event. This alarm merging strategy can be called a horizontal merging strategy, and the resulting composite alarm event can reflect the scope of the alarm's impact.

[0057] Alternatively, an original alarm event may contain an "instance_id," which is the identifier of the running instance to which the data unit used to generate the original alarm event belongs. In this case, original alarm events originating from the same "instance_id" can be merged into a composite alarm event. This alarm merging strategy can be called a vertical merging strategy, and the resulting composite alarm event can reflect the severity of the combined alarms.

[0058] By employing two orthogonal merging strategies—horizontal (scope of impact) and vertical (compound severity)—original alarm events can be merged into compound alarm events, thereby resolving the "alarm storm" problem caused by a single root cause.

[0059] In some embodiments, upon receiving the aforementioned composite alarm event, the alarm level of the composite alarm event can be further determined. In practical applications, the alarm level of an alarm event can represent the severity of the alarm event.

[0060] Specifically, for any composite alarm event, the alarm level can be determined based on the number of running instances associated with the composite alarm event and the number of original alarm events of each alarm level included in the composite alarm event. The running instances associated with the composite alarm event can be the running instances affected by the composite alarm event; the instances affected by the alarm are a core concept in operations and observability systems, used to identify specific computing resources or service units that have experienced anomalies or may be affected.

[0061] In practical applications, the scores corresponding to composite alarm events can be dynamically calculated based on the scoring model, thereby determining the alarm level of a composite alarm event based on the score corresponding to any one of the composite alarm events.

[0062] By abandoning static rating and introducing a quantifiable and configurable scoring model, the horizontal breadth of the fault's impact and the vertical severity depth can be considered simultaneously, so that the alarm level can truly reflect the impact of the fault.

[0063] In some embodiments, when determining the alarm level of a composite alarm event, on the one hand, an impact range score corresponding to the composite alarm event can be calculated based on the number of running instances associated with the composite alarm event; on the other hand, a composite severity score corresponding to the composite alarm event can be calculated based on the number of original alarm events of each alarm level included in the composite alarm event. Subsequently, a weighted sum of the impact range score and the composite severity score can be calculated based on preset weights, and the alarm level corresponding to the weighted sum is determined as the alarm level of the composite alarm event. In practical applications, the weights of the impact range score and the composite severity score can be adjusted according to actual conditions and needs.

[0064] In some embodiments, in the process of calculating the composite severity score corresponding to the composite alarm event, the composite severity score corresponding to the original alarm event of each alarm level can be calculated first based on the number of original alarm events of each alarm level included in the composite alarm event, and then the composite severity score corresponding to the composite alarm event can be determined from the composite severity scores corresponding to the original alarm events of each alarm level.

[0065] That is, the total score corresponding to the above composite alarm event can be calculated using the following formula: S = (W_impact × Impact_Score) + (W_complexity × Complexity_Score); where S represents the total score, Impact_Score represents the impact range score, W_impact represents the weight of the impact range score, Complexity_Score represents the composite severity score, and W_complexity represents the weight of the composite severity score.

[0066] The impact score can be calculated using the following formula: Impact_Score = 100 - (50 / N); where N represents the number of running instances associated with the composite alarm event. An alarm event affects at least one running instance, therefore N is a positive integer.

[0067] The above composite severity score can be calculated in the following way: First, calculate the composite severity score corresponding to the original alarm event for each alarm level (assuming they are severe P1, warning P2, and alert P3, respectively), where: P1 Original Alarm Event Score = 100 - (10 / N1); where N1 represents the number of original alarm events of alarm level P1. If the above composite alarm event does not contain any original alarm events of alarm level P1, then the P1 Original Alarm Event Score = 0.

[0068] P2 Original Alarm Event Score = 100 - (30 / N2); where N2 represents the number of original alarm events of the P2 alarm level. If the above composite alarm event does not contain any original alarm events of the P2 alarm level, then the P2 Original Alarm Event Score = 0.

[0069] P3 Original Alarm Event Score = 100 - (60 / N3); where N3 represents the number of original alarm events of the P3 alarm level. If the above composite alarm event does not contain any original alarm events of the P3 alarm level, then the P3 Original Alarm Event Score = 0.

[0070] The composite severity score corresponding to the above composite alarm events is: Complexity_Score = max(P1 original alarm event score, P2 original alarm event score, P3 original alarm event score), which is the maximum value among these three.

[0071] Finally, the alarm level of the composite alarm event can be determined according to the score range of the total score corresponding to the above composite alarm event: when S>=70, the alarm level of the composite alarm event is P1 (critical); when 70>S>=50, the alarm level of the composite alarm event is P2 (warning); when S<50, the alarm level of the composite alarm event is P3 (hint).

[0072] Step 208: Perform alarm processing based on the composite alarm event.

[0073] In this embodiment, upon receiving the aforementioned composite alarm event, alarm processing can be performed based on the composite alarm event. For example, an alarm message can be generated based on the composite alarm event and sent to a specific alarm recipient. The alarm message may include information such as an event summary, final level, scope of impact, root cause analysis (possible root causes), and a detailed link.

[0074] In some embodiments, for any composite alarm event, if the alarm level of the composite alarm event is determined, alarm processing can be performed based on the composite alarm event according to the alarm processing strategy corresponding to the alarm level.

[0075] In some embodiments, the alarm handling strategy corresponding to the alarm level can specifically be a notification routing rule corresponding to the alarm level, that is, a rule used to specify the alarm receiver. In this case, for any composite alarm event, once the alarm level of the composite alarm event is determined, the composite alarm event can be sent to the alarm receiver specified by the notification routing rule according to the notification routing rule corresponding to the alarm level.

[0076] For example, the notification routing rule corresponding to the P1 (critical) alarm level could be: phone call + SMS + DingTalk group @everyone; the notification routing rule corresponding to the P2 (warning) alarm level could be: email + DingTalk group; and the notification routing rule corresponding to the P3 (notification) alarm level could be: internal work order system or knowledge base record, without real-time notification.

[0077] In some embodiments, the routing engine can obtain classified composite alarm events and match notification routing rules based on information such as the alarm level, business line, and duty schedule of the composite alarm event, so as to call different notification channel interfaces to send alarm messages according to the matched notification routing rules.

[0078] Combination Figure 1 and Figure 2 ,refer to Figure 3 , Figure 3 This is a schematic diagram of an alarm processing flow provided in an exemplary embodiment.

[0079] The core idea of ​​the Pipeline mechanism is to break down a complex task into several sequentially executed stages. Each stage handles a portion of the work and passes the result to the next stage, thereby improving overall efficiency, maintainability, and concurrency. Therefore, the Pipeline mechanism can be used to implement the entire alarm handling process.

[0080] Specifically, such as Figure 3 As shown, the alarm processing flow described above can include five stages: data acquisition, alarm detection, alarm merging, alarm classification, and alarm processing.

[0081] During the data acquisition phase, real-time data streams can be obtained from data sources corresponding to at least one running instance and usable for alarm assessment. Specifically, data can be collected from these data sources to form a real-time data stream that can be used for alarm assessment. These data sources may include monitoring metrics, logs, and / or system events.

[0082] During the alarm detection phase, abnormal data units in the aforementioned real-time data stream can be identified, and original alarm events can be generated based on the abnormal data units identified from the real-time data stream. Specifically, each data unit in the real-time data stream can be matched with preset anomaly identification rules; if a data unit matches any anomaly identification rule, then that data unit can be identified as an abnormal data unit.

[0083] During the alarm merging phase, original alarm events within a preset time period can be acquired, and related original alarm events can be merged into composite alarm events. Specifically, original alarm events generated based on data units matching the same anomaly detection rules can be merged into composite alarm events; and / or, original alarm events generated based on data units originating from data sources corresponding to the same running instance can be merged into composite alarm events.

[0084] During the alarm rating phase, the alarm level of the aforementioned composite alarm events can be determined. For any composite alarm event, the alarm level can be determined based on the number of running instances associated with the composite alarm event and the number of original alarm events of each alarm level included in the composite alarm event. For example, an impact range score corresponding to the composite alarm event can be calculated based on the number of running instances associated with the composite alarm event, and a composite severity score corresponding to the composite alarm event can be calculated based on the number of original alarm events of each alarm level included in the composite alarm event. Then, a weighted sum of the impact range score and the composite severity score can be calculated based on preset weights, and the alarm level corresponding to the weighted sum is determined as the alarm level of the composite alarm event.

[0085] During the alarm processing phase, alarm processing can be performed based on the aforementioned composite alarm events. Once the alarm level of a composite alarm event is determined, for any given composite alarm event, alarm processing can be performed according to the alarm processing strategy corresponding to that alarm level. This alarm processing strategy may include notification routing rules; specifically, the composite alarm event can be sent to the alarm receiver specified by the notification routing rule corresponding to the alarm level.

[0086] In the technical solutions provided in one or more embodiments of this specification, a real-time data stream can first be obtained from a data source that can be used for alarm judgment corresponding to at least one running instance. Then, abnormal data units in the real-time data stream can be identified, and original alarm events can be generated based on the abnormal data units identified from the real-time data stream. Then, original alarm events within a preset time period can be obtained, and the original alarm events that are related to each other in the obtained original alarm events can be merged into a composite alarm event. Finally, alarm processing can be performed based on the composite alarm event.

[0087] This approach separates anomaly identification from final alarm processing. After identifying anomaly data, raw alarm events are generated, but related raw alarm events are further merged into composite alarm events, which are then used for alarm processing. This reduces the number of alarm events and increases their information density, thereby improving operational efficiency and shortening fault recovery time.

[0088] Corresponding to the embodiments of the aforementioned alarm processing methods, this specification also provides embodiments of alarm processing devices.

[0089] refer to Figure 4 , Figure 4 This is a schematic diagram of the structure of a device provided in an exemplary embodiment. For example... Figure 4 As shown, device 400 mainly consists of a communication interface 402, a user interface 404, a processor 406, and a data storage 408. These components are interconnected and communicate with each other via a system bus, network, or other connection mechanism 410. The communication interface 402 enables device 400 to communicate with other devices, access networks, and transmission networks via analog or digital modulation. For example, the communication interface 402 may include a chipset and antenna for wireless communication with a radio access network or access point. Furthermore, the communication interface 402 can be a wired interface such as Ethernet, Token Ring, or a USB port, or a wireless interface such as Wi-Fi, Bluetooth, Global Positioning System (GPS), or a wide-area wireless interface (e.g., WiMAX or LTE). Of course, the communication interface 402 can also support other forms of physical layer interfaces and standard or proprietary communication protocols. The communication interface 402 may also include multiple physical communication interfaces, such as Wi-Fi, Bluetooth, and wide-area wireless interfaces.

[0090] User interface 404 includes receiving user input and providing output to the user. Therefore, user interface 404 may include input components such as a keypad, keyboard, touch-sensitive or presence-sensitive panel, computer mouse, trackball, joystick, microphone, still camera, and video camera, and output components such as a display screen (which may be combined with a touch-sensitive panel), CRT, LCD, LED, display using DLP technology, printer, and other similar devices known or developed in the future. User interface 404 may also generate auditory output via speakers, speaker jacks, audio output ports, audio output devices, headphones, and other similar devices known or developed in the future. In some embodiments, user interface 404 may include software, circuitry, or other forms of logic capable of transmitting and receiving data from external user input / output devices. Additionally or alternatively, device 400 may support remote access from other devices via communication interface 402 or another physical interface (not shown). User interface 404 may be configured to receive user input, the position and movement of which may be indicated by an indicator or cursor described herein. User interface 404 may also be configured as a display device for rendering or displaying text fragments.

[0091] Processor 406 may contain one or more general-purpose processors and / or special-purpose processors.

[0092] Data storage 408 may include one or more volatile and / or non-volatile storage components and may be integrated wholly or partially with processor 406. Data storage 408 may include removable and non-removable components.

[0093] Processor 406 is capable of executing program instructions 418 (e.g., compiled or uncompiled program logic and / or machine code) stored in data storage 408 to perform the various functions described herein. Data storage 408 may comprise a non-transitory computer-readable medium on which program instructions are stored, which, when executed by device 400, enable device 400 to perform any methods, processes, or functions disclosed in this specification and / or the accompanying drawings. Processor 406 executing program instructions 418 may result in processor 406 using data 412.

[0094] For example, program instructions 418 may include an operating system 422 (e.g., an operating system kernel, device drivers, and / or other modules) installed on device 400 and one or more applications 420 (e.g., a browser, social application, or game application). Similarly, data 412 may include operating system data 416 and application data 414. Operating system data 416 is primarily accessible to the operating system 422, while application data 414 is primarily accessible to one or more applications 420. Application data 414 may reside in a file system visible or hidden from the user of device 400.

[0095] Application 420 can communicate with operating system 422 through one or more application programming interfaces (APIs). These APIs help application 420 read and / or write application data 414, transmit or receive information via communication interface 402, receive or display information on user interface 404, etc.

[0096] In some terminology, application 420 may be simply referred to as "app". Furthermore, application 420 can be downloaded to device 400 through one or more online app stores or app markets. However, applications can also be installed on device 400 in other ways, such as through a web browser or a physical interface on device 400 (e.g., a USB port).

[0097] refer to Figure 5 , Figure 5 This is a block diagram of an alarm processing apparatus provided in an exemplary embodiment. This alarm processing apparatus can be applied to, for example... Figure 4 The device shown is used to implement the technical solution described in this specification.

[0098] The alarm processing device mentioned above may include: The acquisition module 502 acquires a real-time data stream from a data source that can be used for alarm judgment, corresponding to at least one running instance; The identification module 504 identifies abnormal data units in the real-time data stream and generates an original alarm event based on the abnormal data units identified from the real-time data stream. The merging module 506 acquires the original alarm events within a preset time period and merges the related original alarm events into a composite alarm event. Alarm module 508 performs alarm processing based on the composite alarm event.

[0099] In some embodiments, the data source includes monitoring metrics, logs, and / or system events.

[0100] In some embodiments, the data unit for identifying anomalies in the real-time data stream includes: Each data unit in the real-time data stream is matched with a preset anomaly identification rule; If the data unit matches the anomaly identification rule, then the data unit is identified as an anomalous data unit.

[0101] In some embodiments, merging interrelated original alarm events into a composite alarm event includes: From the acquired raw alarm events, those generated based on data units matching the same anomaly detection rules are merged into composite alarm events; and / or, The original alarm events obtained are merged into composite alarm events based on the data units generated from the data source corresponding to the same running instance.

[0102] In some embodiments, the apparatus further includes a rating module: Determine the alarm level of the composite alarm event; The alarm processing based on the composite alarm event includes: Alarm processing is performed based on the composite alarm event according to the alarm processing strategy corresponding to the alarm level.

[0103] In some embodiments, determining the alarm level of the composite alarm event includes: The alarm level of the composite alarm event is determined based on the number of running instances associated with the composite alarm event and the number of original alarm events of each alarm level contained in the composite alarm event.

[0104] In some embodiments, determining the alarm level of the composite alarm event based on the number of running instances associated with the composite alarm event and the number of original alarm events of each alarm level included in the composite alarm event includes: Calculate the impact range score corresponding to the composite alarm event based on the number of running instances associated with the composite alarm event; Calculate the composite severity score corresponding to the composite alarm event based on the number of original alarm events of each alarm level included in the composite alarm event; The impact range score and the composite severity score are calculated based on preset weights, and the alarm level corresponding to the weighted sum is determined as the alarm level of the composite alarm event.

[0105] In some embodiments, calculating the composite severity score corresponding to the composite alarm event based on the number of original alarm events of each alarm level included in the composite alarm event includes: Based on the number of original alarm events of each alarm level included in the composite alarm event, calculate the composite severity score corresponding to the original alarm events of each alarm level. The composite severity score corresponding to the composite alarm event is determined from the composite severity scores corresponding to the original alarm events of each alarm level.

[0106] In some embodiments, the step of performing alarm processing based on the composite alarm event according to the alarm processing strategy corresponding to the alarm level includes: According to the notification routing rules corresponding to the alarm level, the composite alarm event is sent to the alarm receiver.

[0107] For ease of description, the above devices are described by dividing them into various modules or units based on their functions. Of course, when implementing one or more of these specifications, the functions of each module or unit can be implemented in the same or different software and / or hardware, or a module that performs the same function can be implemented by a combination of multiple sub-modules or sub-units, etc. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed.

[0108] Based on the same concept as the methods described above, this specification also provides an electronic device, including: a processor; a memory for storing processor-executable instructions; wherein the processor performs the steps of the method as described in any of the above embodiments by executing the executable instructions.

[0109] Based on the same concept as the methods described above, this specification also provides a computer-readable storage medium having computer instructions stored thereon that, when executed by a processor, implement the steps of the methods as described in any of the above embodiments.

[0110] Based on the same concept as the methods described above, this specification also provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of the methods as described in any of the above embodiments.

[0111] What those skilled in the art will understand is: In this specification, the terms "comprising," "including," or any other variations thereof are intended to cover a non-exclusive inclusion, such that a process, method, product, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, product, or apparatus. Without further limitation, the presence of additional identical or equivalent elements in a process, method, product, or apparatus that includes said elements is not excluded.

[0112] In this specification, “a,” “an,” and “the” do not specifically refer to the singular, but may also include the plural.

[0113] In this specification, ordinal numbers such as "first," "second," etc., do not necessarily indicate order; they are often used to distinguish between objects. For example, "first server" and "second server" usually refer to two servers. To differentiate between these two servers, they are described as "first server" and "second server." Of course, sometimes these two servers may be the same server.

[0114] In this specification, unless explicitly stated otherwise, "receiving and sending data" does not necessarily mean direct receiving and sending; it can also mean indirect receiving and sending. For example, A receiving data sent by B can be understood as A directly receiving the data sent by B, or it can be understood as A indirectly receiving the data sent by B through other entities such as C. Similarly, B sending data to A can be understood as B sending the data directly to A, or it can be understood as B indirectly sending the data to A through other entities such as C. Here, C can be one entity, or it can be two or more entities.

[0115] In this specification, unless explicitly stated otherwise, the relationships between structures can be direct or indirect. For example, when describing "A is connected to B," unless it is explicitly stated that A and B are directly connected, it should be understood that A can be directly connected to B or indirectly connected to B. Similarly, when describing "A is on top of B," unless it is explicitly stated that A is directly above B (AB is adjacent and A is above B), it should be understood that A can be directly above B or indirectly above B (AB is separated by other elements, and A is above B). And so on.

[0116] This specification uses specific terms to describe embodiments thereof. Terms such as "an embodiment," "one embodiment," and / or "some embodiments" refer to a particular feature, structure, or characteristic associated with at least one embodiment of this specification. Therefore, it should be emphasized and noted that references to "an embodiment," "one embodiment," or "an alternative embodiment" in different locations throughout this specification do not necessarily refer to the same embodiment. Furthermore, those skilled in the art can combine and integrate the different embodiments or examples described herein, as well as the features of those different embodiments or examples, without contradiction.

[0117] Although one or more embodiments of this specification provide method steps as described in the embodiments or flowcharts, it is understood that the order of steps listed in the embodiments or flowcharts is only one of many possible execution orders and does not represent the only execution order. Therefore, when the claims involve method steps, any changes or adjustments to the order of such steps, or the parallelism between steps, are also within the scope of protection of the claims.

Claims

1. An alarm processing method, the method comprising: Obtain real-time data streams from data sources that can be used for alarm determination, corresponding to at least one running instance; Identify abnormal data units in the real-time data stream and generate original alarm events based on the abnormal data units identified from the real-time data stream; Obtain the original alarm events within a preset time period, and merge the related original alarm events into a composite alarm event. Alarm processing is performed based on the composite alarm event.

2. The method according to claim 1, wherein the data source includes monitoring metrics, logs, and / or system events.

3. The method according to claim 1, wherein the data unit for identifying abnormal data in the real-time data stream comprises: Each data unit in the real-time data stream is matched with a preset anomaly identification rule; If the data unit matches the anomaly identification rule, then the data unit is identified as an anomalous data unit.

4. The method according to claim 3, wherein merging the interrelated original alarm events in the acquired original alarm events into a composite alarm event includes: The original alarm events generated from data units that match the same anomaly detection rules are merged into composite alarm events. And / or, The original alarm events obtained are merged into composite alarm events based on the data units generated from the data source corresponding to the same running instance.

5. The method according to claim 1, further comprising: Determine the alarm level of the composite alarm event; The alarm processing based on the composite alarm event includes: Alarm processing is performed based on the composite alarm event according to the alarm processing strategy corresponding to the alarm level.

6. The method according to claim 5, wherein determining the alarm level of the composite alarm event includes: The alarm level of the composite alarm event is determined based on the number of running instances associated with the composite alarm event and the number of original alarm events of each alarm level contained in the composite alarm event.

7. The method according to claim 6, wherein determining the alarm level of the composite alarm event based on the number of running instances associated with the composite alarm event and the number of original alarm events of each alarm level included in the composite alarm event comprises: Calculate the impact range score corresponding to the composite alarm event based on the number of running instances associated with the composite alarm event; Calculate the composite severity score corresponding to the composite alarm event based on the number of original alarm events of each alarm level included in the composite alarm event; The impact range score and the composite severity score are calculated based on preset weights, and the alarm level corresponding to the weighted sum is determined as the alarm level of the composite alarm event.

8. The method according to claim 7, wherein calculating the composite severity score corresponding to the composite alarm event based on the number of original alarm events of each alarm level included in the composite alarm event comprises: Based on the number of original alarm events of each alarm level included in the composite alarm event, calculate the composite severity score corresponding to the original alarm events of each alarm level. The composite severity score corresponding to the composite alarm event is determined from the composite severity scores corresponding to the original alarm events of each alarm level.

9. The method according to claim 5, wherein the step of performing alarm processing based on the composite alarm event according to the alarm processing strategy corresponding to the alarm level includes: According to the notification routing rules corresponding to the alarm level, the composite alarm event is sent to the alarm receiver.

10. An alarm processing device, the device comprising: The acquisition module acquires real-time data streams from a data source that can be used for alarm judgment, corresponding to at least one running instance; The identification module identifies abnormal data units in the real-time data stream and generates original alarm events based on the abnormal data units identified from the real-time data stream. The merging module acquires the original alarm events within a preset time period and merges the related original alarm events into a composite alarm event. The alarm module performs alarm processing based on the composite alarm events.

11. An electronic device, comprising: processor; Memory used to store processor-executable instructions; The processor implements the steps of the method as described in any one of claims 1 to 9 by executing the executable instructions.

12. A computer-readable storage medium having stored thereon computer instructions that, when executed by a processor, implement the steps of the method as claimed in any one of claims 1 to 9.

13. A computer program product comprising a computer program / instructions that, when executed by a processor, implement the steps of the method as claimed in any one of claims 1 to 9.

Images