Alarm aggregation rule cross-product transmission method and device and electronic equipment

Abstract

The invention relates to an alarm aggregation rule cross-product transmission method and device. According to the method, the alarm log containing the alarm large class, the alarm small class and the aggregation rule field is read from the alarm log source, the log is analyzed to extract the key information, and the aggregation rule table is dynamically updated or inserted according to the alarm large class and the alarm small class, so that automatic management and cross-product transmission of the alarm rule are realized. According to the method, the Flink stream processing technology is combined with the Kafka message queue, so that the real-time performance and the accuracy of the alarm information are ensured. And meanwhile, alarm rules of all products are periodically synchronized through an API interface, so that the automation level of the system is further improved. In addition, the alarm rule management efficiency and consistency are remarkably improved, manual configuration errors and operation and maintenance cost are reduced, it is ensured that the alarm information is highly consistent with all products during unified management, and the reliability and stability of an alarm system are enhanced.

Description

Technical Field

[0001] The present application belongs to the field of alarm management technology, and in particular, relates to a method, device, computer-readable storage medium, and electronic device for delivering alarm aggregation rules across products. Background Art

[0002] In the current alarm management field, although existing technologies have achieved alarm aggregation and management to a certain extent, there are still some significant defects and deficiencies, as follows: 1. Inconsistent rules The alarm rules of different products may be repeated, conflicting, or lack aggregation rules. This inconsistency leads to confusion in alarm management and makes it difficult to achieve unified management across products.

[0003] 2. Manual configuration is inefficient In a multi-product environment, manually configuring and synchronizing alarm rules is not only time-consuming but also error-prone. This inefficient configuration method seriously affects the overall operation and maintenance efficiency and increases the operation and maintenance costs.

[0004] 3. Alarm management is difficult When the alarm information of multiple products is synchronized to a unified management platform, it is difficult to maintain accuracy and consistency across products due to the lack of effective alarm aggregation rules or the existence of duplicate rules. This makes it difficult for operation and maintenance personnel to quickly locate and handle key alarms.

[0005] 4. Lack of dynamic adaptability In the prior art, most alarm rules are statically configured and difficult to dynamically adapt to complex monitoring scenarios. For example, alarm rules cannot dynamically adjust thresholds or aggregation strategies based on real-time data, resulting in insufficient flexibility of the alarm system.

[0006] 5. Insufficient alarm convergence and suppression In large-scale monitoring scenarios, the redundancy and duplication of alarm information still exist. Although the existing alarm convergence and suppression mechanisms can reduce some alarms, they still cannot effectively solve the alarm storm problem. Summary of the invention

[0007] In order to address the above problems, this application proposes a new method for cross-product transmission of alarm aggregation rules.

[0008] Specifically, this application provides the following technical solutions: A first aspect of the present application provides a method for delivering alarm aggregation rules across products, the method comprising: S1. Read the alarm log containing the alarm category, alarm subcategory, and aggregation rule fields from the alarm log source; S2. Parse the alarm log and extract the alarm categories, alarm subcategories, and aggregation rule fields; S3. Find the corresponding aggregation rule record in the aggregation rule table according to the alarm category and alarm subcategory; S4. If the corresponding aggregation rule record is found, the aggregation rule fields are compared, and if they are inconsistent, the aggregation rule record is updated; S5. If the corresponding aggregation rule record is not found, insert a new aggregation rule record into the aggregation rule table.

[0009] Furthermore, in the method of the present application, the alarm log source is a Kafka Topic, and in step S1, the alarm log is read from the Kafka Topic through the FlinkKafka Connector.

[0010] Furthermore, in the method of the present application, in step S2, the alarm log is parsed into a JSON format object, and the alarm major category, alarm minor category and aggregation rule fields therein are extracted.

[0011] Furthermore, in the method of the present application, in step S3, the corresponding aggregation rule record is searched in the aggregation rule table by the combination key of the alarm major category code and the alarm minor category code.

[0012] Furthermore, in the method of the present application, when the aggregation rule record is updated in step S4, the last updated time field is also updated at the same time.

[0013] Furthermore, in the method of the present application, when a new aggregation rule record is inserted in step S5, the record content includes the alarm major category, alarm minor category, aggregation rule field and the last update time.

[0014] Furthermore, in the method of the present application, the aggregation rule table is maintained through Side Output or BroadcastState of Flink.

[0015] Furthermore, the method of the present application also includes the steps of regularly obtaining alarm rules from each product through an API interface and updating the aggregation rule table; The API interface includes: (1) Get alarm rule list interface, used to obtain the alarm rule list of all products. This interface supports filtering alarm rules by product ID or last updated timestamp; (2) Update alarm aggregation rule table interface, which is used to update the aggregation rule table according to the acquired alarm rules. This interface supports batch update of aggregation rule records.

[0016] A second aspect of the present application provides a device for cross-product transmission of alarm aggregation rules, the device comprising: A reading module is used to read the alarm log containing the alarm major category, alarm minor category and aggregation rule fields from the alarm log source; Parsing module, used to parse alarm logs and extract alarm categories, alarm subcategories, and aggregation rule fields; A search module is used to search for corresponding aggregation rule records in the aggregation rule table according to the alarm major category and alarm minor category; An update module is used to compare the aggregation rule fields when the corresponding aggregation rule record is found, and update the aggregation rule record if they are inconsistent; The insert module is used to insert a new aggregation rule record into the aggregation rule table when the corresponding aggregation rule record is not found.

[0017] The device implements the steps of the aforementioned alarm aggregation rule cross-product transmission method when running.

[0018] A third aspect of the present application provides an electronic device, comprising: a memory and a processor; Memory: used to store computer programs; Processor: used to execute the computer program to implement the steps of the aforementioned alarm aggregation rule cross-product transmission method.

[0019] A fourth aspect of the present application provides a computer-readable storage medium having a computer program stored thereon, and when the computer program is executed by a processor, the steps of the aforementioned alarm aggregation rule cross-product delivery method are implemented.

[0020] In summary, the cross-product transmission method of alarm aggregation rules proposed in this application has the following advantages over the existing methods: (1) Improved efficiency and consistency of alarm rule management: This solution significantly improves the management efficiency and consistency of alarm rules by introducing an automated and standardized alarm rule management mechanism.

[0021] (2) Reduced manual configuration errors and operation and maintenance costs: Through automation and intelligent means, the need for manual configuration is greatly reduced, thereby reducing operation and maintenance costs and the risk of errors.

[0022] (3) Ensure the accuracy and consistency of alarm information: In the process of unified alarm management, various technical means are used to ensure the accuracy and consistency of alarm information.

[0023] (4) Implemented a cross-product synchronization mechanism: Through unified rule management and an efficient synchronization mechanism, it ensures that alarm information can be transmitted between different products in real time and accurately.

[0024] (5) Improved flexibility of alarm rules: Alarm rules can be adjusted dynamically based on real-time data, and can quickly adapt to changes in monitoring scenarios, further improving the flexibility and adaptability of alarm rules.

[0025] Other features and advantages of the present application will be described in detail in the subsequent description, or can be understood by implementing the relevant technical solutions of the present application. The purpose and other advantages of the present application can be achieved through the technical features and technical means clearly indicated in the description, claims and drawings, and obtained through the implementation process of these technical contents. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following is a brief introduction to the drawings involved in the description of the embodiments. It should be noted that the drawings only show some embodiments of the present application. For those skilled in the art, other related drawings can be derived from these drawings without creative work.

[0027] Figure 1 This is the flow chart for processing existing alarm log data.

[0028] Figure 2 This is an example diagram of an aggregation rule table definition shown in an embodiment of the present application.

[0029] Figure 3 This is the overall implementation flow chart of the cross-product delivery method of alarm aggregation rules for this application.

[0030] Figure 4 This is a structural diagram of the cross-product transmission device for alarm aggregation rules in this application.

[0031] Figure 5 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0032] In order to make the purpose, technical scheme and advantages of the embodiments of the present application clearer, the technical scheme in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. It should be clear that the described embodiments are only some embodiments of the present application, not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work belong to the scope of protection of the present application.

[0033] In this document, the term "including" and any of its variations (such as "including", "including", etc.) are open expressions and should be understood as "including but not limited to", that is, the listed contents are not exhaustive and may also include other contents not explicitly mentioned. The term "based on" should be understood as "based at least in part", that is, the basis or condition referred to may not be the only factor, and other relevant factors may also be involved. The term "one embodiment" should be understood as "at least one embodiment", that is, the described embodiment is not the only possible implementation method, and there may be other similar embodiments.

[0034] In this application, when the terms "one" and "multiple" are used to modify related elements or features, their expressions are illustrative rather than restrictive. Unless otherwise clearly stated in the context, "one" should be understood as "at least one" and "multiple" should be understood as "at least two". Those skilled in the art should reasonably interpret these terms based on the semantics and logical relationship of the context to ensure that they cover the possibility of "one or more".

[0035] Figure 3 The overall implementation process of the cross-product delivery method of the alarm aggregation rule provided by this application is shown, including the following steps: S1. Read the alarm log containing the alarm category, alarm subcategory, and aggregation rule fields from the alarm log source; S2. Parse the alarm log and extract the alarm categories, alarm subcategories, and aggregation rule fields; S3. Find the corresponding aggregation rule record in the aggregation rule table according to the alarm category and alarm subcategory; S4. If the corresponding aggregation rule record is found, the aggregation rule fields are compared, and if they are inconsistent, the aggregation rule record is updated; S5. If the corresponding aggregation rule record is not found, insert a new aggregation rule record into the aggregation rule table.

[0036] In order to more clearly illustrate the technical solution of the present application, further explanation will be given below through embodiments of specific scenarios.

[0037] At present, in the cloud computing environment, the alarm logs generated by various cloud products are uniformly accessed through a multi-source log integration module and integrated into the security management platform to support centralized management and monitoring. The specific implementation process is as follows: Figure 1 As shown, including: Log storage and access The alarm logs generated by various cloud products are stored in their corresponding Kafka topics. The security management platform performs preliminary processing on the logs through the multi-source log access module (with log access, parsing and forwarding capabilities) and determines whether to transfer them to alarm data.

[0038] Alarm Data Processing Flow If it is determined that the log needs to be archived as alarm data, when the Flink job (Flink_Job1:Threat-Alert) processes the original log, it will read the alarm aggregation rule table from the MySQL database.

[0039] Flink aggregates the logs according to the preset alarm aggregation rules.

[0040] After processing, the alarm details will be written into the ClickHouse database, while the alarm aggregation results will be stored in the MySQL database.

[0041] In the alarm aggregation table, the details of the last alarm are stored in JSON format for subsequent query and analysis.

[0042] However, there are still some problems in the above implementation process, which are described as follows: 1. Difficult to update and maintain the alarm aggregation rule table Currently, the update and maintenance of the alarm aggregation rule table relied on by Flink completely depend on manual operations and no automated update has been achieved. Whenever a new log type is introduced, developers need to actively consult the relevant product team about its alarm aggregation strategy and manually enter the data into the rule table.

[0043] 2. Defects of the manual process This highly manual process not only increases the risk of errors, but also weakens the reliability and stability of the system to a certain extent, affecting the overall operation and maintenance efficiency and the scalability of the system.

[0044] Figure 2 The following shows an example of the definition of an aggregation rule table.

[0045] Sample of the original alarm log:

[0046] From the above sample of the alarm log, information such as the major alarm data, minor alarm data, and log source can be obtained, but the alarm aggregation field rules are missing.

[0047] To solve this problem, the following two optimization strategies are adopted in this method: Strategy 1: Dynamic Aggregation Rule Update Method Based on Log Fields In a multi-product environment, each product writes the alarm log to its corresponding Kafka Topic and adds an aggregation rule field to the original log. Through Flink stream processing jobs, logs are read from the alarm Topic and aggregation rules are dynamically updated or inserted according to the alarm categories and subcategories. The specific implementation steps are as follows: 1. Read the log Various products write alarm logs to the specified Topic of Kafka. The logs contain the original alarm information and the newly added aggregation rule field. Flink reads logs by configuring Kafka Source and uses the KafkaConnector provided by Flink to efficiently read data from Kafka Topic. When configuring Kafka Source, you need to specify parameters such as the Kafka cluster address, Topic name, and consumer group ID to ensure correct connection and data reading.

[0048] For example:

[0049] 2. Parsing logs Parse the read logs into JSON (or other formats) objects and extract key fields (such as alarm major category, alarm minor category, aggregation rule field, etc.). The parsing process needs to ensure the correctness and consistency of the log format for subsequent processing.

[0050] The JSON format of the optimized alarm log is as follows:

[0051] aggregation_fields is the newly added aggregation rule field, rule_sub_type, rule_sub_type_encode, rule_type, and rule_type_encode are the alarm major category, alarm major category code, alarm minor category, and alarm minor category code respectively.

[0052] Parse the read log string into a JSON object For example:

[0053] 3. Update or insert aggregation rules Use Flink's Side Output or Broadcast State to maintain the aggregation rule table and perform the following operations for each log: Search: Search for corresponding records in the aggregation rule table based on the alarm major category and alarm minor category.

[0054] Compare and Update: (1) If the record is found and the aggregation_fields fields are exactly the same, the update operation is skipped.

[0055] (2) If the record is found but the aggregation_fields field is inconsistent, update the aggregation_fields and last_updated fields.

[0056] Insert: If no record is found, a new record is inserted. The record content includes information such as alarm major category, alarm minor category, aggregation rule field, etc.

[0057] 3.1 Define the aggregation rule table A "MapState" is used to store the aggregation rule table, where the key is a combination of the alarm category and the alarm subcategory, and the value is the aggregation rule and the last update time.

[0058] public class AggregationRule { public String aggregationFields; # aggregation rules public long lastUpdated; #Last updated time } 3.2 Define BroadcastProcessFunction Define "BroadcastProcessFunction" to process each log and update or insert aggregation rules based on the alarm major and minor categories.

[0059] public class AggregationRuleUpdater extends BroadcastProcessFunction<JSONObject, AggregationRule, Void> { / / Define MapState to store the aggregation rule table / / Key: A combination of the alarm major code and the alarm minor code (such as "NETWORK-001") / / Value: AggregationRule object, including aggregation fields and last update time private transient MapState<String, AggregationRule> aggregationRules; / / Called when the Flink task is initialized to initialize the state @Override public void open(Configuration parameters) throws Exception { / / Define the MapState descriptor, specifying the state name and key value type MapStateDescriptor<String, AggregationRule> descriptor = newMapStateDescriptor<>( "aggregation-rules", / / state name String.class, / / Key type (alarm major class code + alarm minor class code) AggregationRule.class / / value type (AggregationRule object) ); / / Get MapState from the runtime context aggregationRules = getRuntimeContext().getMapState(descriptor); } / / The core logic for processing each alarm log @Override public void processElement(JSONObject alert, ReadOnlyContext ctx,Collector <void>out) throws Exception { / / Extract alarm major category, alarm minor category, alarm major category code, alarm minor category code and aggregation fields from the log String ruleType = alert.getString("rule_type"); / / Alarm category String ruleTypeEncode = alert.getString("rule_type_encode"); / / Alarm category code String ruleSubType = alert.getString("rule_sub_type"); / / Alert subtype String ruleSubTypeEncode = alert.getString("rule_sub_type_ encode"); / / Alarm subtype code String aggregationFields = alert.getString("aggregation_fields"); / / Newly added aggregation rule fields / / Construct a unique key to identify the current alarm type (alarm major category code + alarm minor category code) String key = ruleTypeEncode + "-" + ruleSubTypeEncode; / / Find the rule corresponding to the current alarm type from the aggregation rule table AggregationRule rule = aggregationRules.get(key); / / Determine whether the corresponding rule is found if (rule != null) { / / If the rule is found and the aggregated field is inconsistent with the current log, update the rule if (!rule.aggregationFields.equals(aggregationFields)) { rule.aggregationFields = aggregationFields; / / Update aggregation fields rule.lastUpdated = System.currentTimeMillis(); / / Update the last updated time aggregationRules.put(key, rule); / / Write the updated rules back to the state } } else { / / If no rule is found, create a new rule and insert it into the state AggregationRule newRule = new AggregationRule(); newRule.aggregationFields = aggregationFields; / / Set aggregation fields newRule.lastUpdated = System.currentTimeMillis(); / / Set the last updated time aggregationRules.put(key, newRule); / / Insert new rules into the state } } } As an alternative, this method can also use the following strategy: Strategy 2: Various products provide API interfaces, and the security management platform can regularly call these interfaces to pull alarm rules and update the alarm aggregation rule table.

[0060] The API interface definition can be referenced (the database table structure and interface definition can be adjusted as needed): 1. Get the alarm rule list URL: / api / v1 / alerts / rules Method: GET Description: Get the list of alarm rules for all products.

[0061] Parameters: product_id (optional): Specify a product ID to get alert rules for a specific product.

[0062] last_updated (optional): Specify a timestamp to get the alert rules updated since that time.

[0063] Response: { "errorMsg": "", "errorCode": "", "success": true, "module": { "rules": { "rule_id": "12345", "product_id": "product_1", "class_name": "High CPU Usage", "class_code": "ALERT_CLASS_FILTER_AAAAA1", "type_name": "High CPU Usage", "type_code": "ALERT_CLASS_FILTER_AAAAA2", "agg_field": ["A","B","C","D"] "last_updated": "2023-10-01T12:00:00Z" } } } 2. Update the alert aggregation rule table URL: / api / v1 / alerts / aggregation Method: POST Request Body: { "rules": { "rule_id": "12345", "product_id": "product_1", "class_name": "High CPU Usage", "class_code": "ALERT_CLASS_FILTER_AAAAA1", "type_name": "High CPU Usage", "type_code": "ALERT_CLASS_FILTER_AAAAA2", ​"agg_field": ["A","B","C","D"] "last_updated": "2023-10-01T12:00:00Z" } ] } Response: { "errorMsg": "", "errorCode": "", "success": true, "module": null } Among them, product_id corresponds to alert_source in the database table, and rule_id corresponds to id in the database table.

[0064] Through the above steps, the method realizes the dynamic update of aggregation rules based on log fields, ensures the real-time and accuracy of alarm aggregation rules, reduces manual intervention, and improves the automation level and reliability of the system.

[0065] Figure 4 The present application shows a device for delivering alarm aggregation rules across products, the device comprising: A reading module is used to read the alarm log containing the alarm major category, alarm minor category and aggregation rule fields from the alarm log source; Parsing module, used to parse alarm logs and extract alarm categories, alarm subcategories, and aggregation rule fields; A search module is used to search for corresponding aggregation rule records in the aggregation rule table according to the alarm major category and alarm minor category; An update module is used to compare the aggregation rule fields when the corresponding aggregation rule record is found, and update the aggregation rule record if they are inconsistent; The insert module is used to insert a new aggregation rule record into the aggregation rule table when the corresponding aggregation rule record is not found.

[0066] When the above device is running, the steps of the alarm aggregation rule cross-product transmission method disclosed in this application are implemented.

[0067] The flowcharts and block diagrams in the accompanying drawings illustrate possible implementations of the apparatus, methods, and computer program products according to various embodiments of the present application, including architecture, functions, and operations. In these figures, each box may represent a module, a program segment, or a portion of a code, which contains one or more executable instructions for implementing a specified logical function. It should be noted that each box in the block diagram and / or flowchart, as well as the combination of these boxes, can be implemented using a dedicated hardware-based system to implement the specified function or operation, or can be implemented by a combination of dedicated hardware and computer instructions.

[0068] like Figure 5 As shown, the embodiment of the present application also discloses an electronic device, including: a processor 310, a communication interface 320, a memory 330 for storing a computer program executable by the processor, and a communication bus 340. The processor 310, the communication interface 320, and the memory 330 communicate with each other through the communication bus 340. The processor 310 runs the executable computer program to implement the steps of the above-mentioned alarm aggregation rule cross-product delivery method.

[0069] It is understandable that, in addition to the memory and the processor, the electronic device may also include an input device (such as a keyboard), an output device (such as a display) and other communication modules. These input devices, output devices and other communication modules communicate with the processor through an I / O interface (i.e., an input / output interface).

[0070] The operation of the present application can be implemented by writing computer program codes using one or more programming languages ​​or a combination thereof. The programming languages ​​include but are not limited to the following types: Object-oriented programming languages, such as Java, Smalltalk, C++, etc.; A conventional procedural programming language, such as "C" or a similar programming language.

[0071] The execution methods of program code include but are not limited to: Executes entirely on the user's computer; Partial execution on the user's computer and part execution on a remote computer; Implemented as a standalone package; Executes entirely on the remote computer or server.

[0072] In scenarios involving remote computers, the remote computer can be connected to the user's computer through any type of network, including but not limited to a local area network (LAN) or a wide area network (WAN). In addition, the remote computer can also be connected to an external computer through an Internet service provider, such as using the Internet.

[0073] Further, the present application also discloses a computer-readable storage medium. When the instructions in the computer-readable storage medium are executed by a processor of an electronic device, the electronic device can execute each step of the method for cross-product transmission of the alarm aggregation rules disclosed in the present application.

[0074] In the context of the present application, a computer-readable storage medium refers to a tangible medium that can store computer program code and related data. Specific examples include, but are not limited to, the following: (1) Portable computer disk: a removable magnetic storage medium such as a floppy disk.

[0075] (2) Hard disk: including fixed storage devices such as mechanical hard disks and solid-state drives.

[0076] (3) Random access memory (RAM): a volatile storage medium for temporarily storing data and program code.

[0077] (4) Read-only memory (ROM): a non-volatile storage medium for storing fixed programs and data.

[0078] (5) Erasable programmable read-only memory (EPROM) or flash memory: a non-volatile storage medium that supports multiple erasures and programming.

[0079] (6) Fiber optic storage device: a storage medium based on fiber optic technology.

[0080] (7) Portable compact disc read-only memory (CD-ROM): a read-only medium for storing data in the form of an optical disc.

[0081] (8) Optical storage device: a storage medium based on optical principles such as DVD, Blu-ray disc, etc.

[0082] (9) Magnetic storage device: a storage medium based on magnetic principles such as magnetic tape, magnetic disk, etc.

[0083] (10) Any suitable combination of the above: for example, multiple storage media are combined to meet different storage requirements.

[0084] These computer-readable storage media can be used to store the program code and related data described in the present application to support the operation of the program and the persistent storage of data.

[0085] In particular, according to an embodiment of the present application, the process described in the flowchart can be implemented as a computer software program. For example, an embodiment of the present application relates to a computer program product, which includes a computer program carried on a non-transitory computer-readable medium. The computer program includes program code for executing the alarm aggregation rule cross-product delivery method disclosed in the present application. When the computer program is executed by a processing device, the above-mentioned functions defined in the embodiments of the present application can be implemented.

[0086] Although the above discussion contains some specific implementation details, these details should not be interpreted as limiting the scope of this application. The above description is only a preferred embodiment of the present application and an explanation of the technical principles used. Those skilled in the art should understand that the disclosure scope involved in this application is not limited to the technical solutions formed by the specific combination of the above technical features. At the same time, this application should also cover other technical solutions formed by any combination of the above technical features or their equivalent features without departing from the above public concept.

[0087] Those skilled in the art should also understand that they can modify the technical solutions described in the above embodiments without departing from the spirit and scope of the technical solutions of the embodiments of the present application, or replace some of the technical features therein by equivalents. These modifications or replacements will not cause the essence of the corresponding technical solutions to deviate from the core spirit and scope of the technical solutions of the embodiments of the present application.< / void>

Claims

1. A method for delivering alarm aggregation rules across products, characterized in that: The method comprises: S1. Read the alarm log containing the alarm category, alarm subcategory, and aggregation rule fields from the alarm log source; S2. Parse the alarm log and extract the alarm categories, alarm subcategories, and aggregation rule fields; S3. Find the corresponding aggregation rule record in the aggregation rule table according to the alarm category and alarm subcategory; S4. If the corresponding aggregation rule record is found, the aggregation rule fields are compared, and if they are inconsistent, the aggregation rule record is updated; S5. If the corresponding aggregation rule record is not found, insert a new aggregation rule record into the aggregation rule table.

2. The method according to claim 1, characterized in that The alarm log source is Kafka Topic, and in step S1, the alarm log is read from Kafka Topic through Flink Kafka Connector.

3. The method according to claim 1, characterized in that: In step S2, the alarm log is parsed into a JSON format object, and the alarm major category, alarm minor category and aggregation rule fields are extracted.

4. The method according to claim 1, characterized in that In step S3, the corresponding aggregation rule record is searched in the aggregation rule table by the combination key of the alarm major category code and the alarm minor category code.

5. The method according to claim 1, characterized in that When the aggregation rule record is updated in step S4, the last updated time field is also updated.

6. The method according to claim 1, characterized in that When inserting a new aggregation rule record in step S5, the record content includes the alarm major category, alarm minor category, aggregation rule field and the last update time.

7. The method according to claim 1, characterized in that The aggregation rule table is maintained through Flink's Side Output or Broadcast State.

8. The method according to claim 1, characterized in that: The method also includes the steps of periodically obtaining alarm rules from each product through an API interface and updating an aggregation rule table; The API interface includes: (1) Get alarm rule list interface, used to obtain the alarm rule list of all products. This interface supports filtering alarm rules by product ID or last updated timestamp; (2) Update alarm aggregation rule table interface, which is used to update the aggregation rule table according to the acquired alarm rules. This interface supports batch update of aggregation rule records.

9. A device for transmitting alarm aggregation rules across products, characterized in that: The device comprises: A reading module is used to read the alarm log containing the alarm major category, alarm minor category and aggregation rule fields from the alarm log source; Parsing module, used to parse alarm logs and extract alarm categories, alarm subcategories, and aggregation rule fields; A search module is used to search for corresponding aggregation rule records in the aggregation rule table according to the alarm major category and alarm minor category; An update module is used to compare the aggregation rule fields when the corresponding aggregation rule record is found, and update the aggregation rule record if they are inconsistent; The insert module is used to insert a new aggregation rule record into the aggregation rule table when the corresponding aggregation rule record is not found.

10. An electronic device, characterized in that: include: Memory and processor; Memory: used to store computer programs; Processor: used to execute the computer program to implement the steps of the alarm aggregation rule cross-product delivery method as described in any one of claims 1-8.

Images