Alarm record generation method based on JSON condition tree

Abstract

The application discloses a kind of alarm record generation methods based on JSON condition tree, belong to alarm data processing technical field.It includes: obtaining alarm rule configuration data, configuration data is defined with JSON format a condition tree, each node of condition tree includes node type, condition expression and child node list;Parse the condition tree, assign node identifier to each node, and build the parent-child relationship mapping table with node identifier as key;Receive real-time event data, for each event, traverse the condition tree from the root node, for each traversed node, whether the event data meets the condition according to the node type and condition expression of this node;When event data meets the condition of all nodes on the path from root node to a certain leaf node, extract the node identifier of all nodes on the path to form a path identification sequence;Generate an alarm record according to path identification sequence, alarm record includes event timestamp, event source identification and path identification sequence.

Description

Technical Field

[0001] This invention relates to the field of alarm data processing technology, specifically to a method for generating alarm records based on a JSON condition tree. Background Technology

[0002] Alarm systems typically rely on predefined rules to judge real-time events and trigger corresponding notifications. Existing alarm rules often use fixed-field threshold lists or simple combinations of single conditions, with each rule independently expressing a single plane of judgment logic. This rule definition method struggles to describe complex conditions with multi-level nested relationships and cannot flexibly express recursive logical combinations of "AND," "OR," and "NOT." When business scenarios require multiple conditions to interact at different levels, existing methods must be broken down into numerous redundant rules, resulting in high configuration and maintenance costs and failing to intuitively reflect the hierarchical relationships between conditions. At the alarm record level, existing solutions generally only generate alarm notifications containing the trigger time, event source, and a brief result description, lacking precise records of the specific condition branch that triggered the alarm. When the same alarm type corresponds to multiple similar but not identical condition paths, operations personnel find it difficult to directly locate the actual effective condition link from the alarm records, leading to reduced efficiency in fault diagnosis and root cause analysis. Therefore, how to utilize structured data formats to flexibly define complex logic in alarm rules and achieve accurate condition path tracing when an alarm is triggered has become an urgent problem to be solved. Summary of the Invention

[0003] This paper provides a method for generating alarm records based on a JSON condition tree, which enables alarm rules to flexibly define multi-level logical combination conditions in a tree structure, and generates alarm records containing precise path identifiers when the event meets the complete condition path, supporting the traceability of alarm triggering.

[0004] To achieve the above objectives, the present invention provides the following technical solution: The present invention provides a method for generating alarm records based on a JSON condition tree, comprising: Obtain alarm rule configuration data. The configuration data defines a condition tree in JSON format. Each node of the condition tree contains a node type, a condition expression, and a list of child nodes. The condition tree is parsed, a node identifier is assigned to each node, and a parent-child relationship mapping table is constructed with the node identifier as the key; Receive real-time event data, and for each event, traverse the condition tree starting from the root node. For each traversed node, evaluate whether the event data meets the conditions based on the node type and condition expression of that node. When the event data satisfies the condition of all nodes on the path from the root node to a certain leaf node, extract the node identifiers of all nodes on that path to form a path identifier sequence. An alarm record is generated based on the path identifier sequence. The alarm record includes an event timestamp, an event source identifier, and a path identifier sequence.

[0005] By uniformly modeling alarm rules as JSON condition trees and uniquely identifying and storing the relationships between nodes, the expression and execution process of complex rules are separated, thereby obtaining complete and unique matching path identifiers in event evaluation. Alarm records generated based on path identifier sequences not only accurately locate the triggered rule path but also provide structured information for alarm tracing and rule hit analysis.

[0006] Preferably, when obtaining alarm rule configuration data, the system receives the subscribed topic name through the configuration interface and retrieves the corresponding JSON string from the configuration center based on the topic name. The JSON string is then subjected to syntax validation. If the validation passes, a JSON parser is used to parse it into a tree-like data structure in memory, where each node corresponds to a JSON object. A unique UUID is added to each node as a node identifier. This standardizes the loading and parsing process of rule configuration, ensuring the correctness of the configuration data and the global uniqueness of the node identifier.

[0007] As a technical solution of the present invention, when parsing the condition tree, the tree data structure is traversed recursively. For each node visited, a UUID is generated as the node identifier. During the traversal, the parent node identifier of the current node is recorded, and the list of child node identifiers is associated with the parent node identifier and stored in a hash table to form a parent-child relationship mapping table. This establishes a bidirectional association between nodes and supports efficient subsequent searches starting from any node.

[0008] Furthermore, after receiving real-time event data, the data is encapsulated into event objects, which include an event type, event source, and an event attribute dictionary. The list of child nodes of the root node is retrieved from the parent-child relationship mapping table, and the current node is set as the root node. A stack structure is used to implement depth-first traversal, pushing the root node onto the stack and repeatedly popping the top node to determine its type. This depth-first stack traversal evaluates nodes in path order, resulting in more natural recording of path information.

[0009] For each traversed node, the node type determination includes: if the node type is a condition node, extracting the attribute values ​​related to the conditional expression from the event attribute dictionary and performing the comparison operation defined in the conditional expression to obtain a Boolean result; if the node type is a logical AND node, recursively evaluating all child nodes, and returning true when all child nodes return true; if the node type is a logical OR node, returning true when at least one child node returns true; and if the node type is a logical NOT node, inverting the evaluation results of the child nodes. Through the above semantic processing of logical combination nodes, the condition tree can express arbitrarily complex alarm triggering logic, and the evaluation behavior is clear and controllable.

[0010] When extracting the path identifier sequence, a path stack is maintained during the depth-first traversal. Each time a child node is entered, its identifier is pushed onto the path stack. When an evaluation confirms that a leaf node has been reached and its conditions are met, all node identifiers from the root node to that leaf node are popped from the path stack and concatenated into a string sequence, connected by a delimiter. This serialized path identifier sequence serves as the trigger fingerprint for alarms, significantly improving their distinguishability and interpretability.

[0011] When generating an alarm record, an alarm record object is created, and the event timestamp, event source identifier, and path identifier sequence are filled in as fields. The conditional expression text corresponding to each node on the path is retrieved from the parent-child relationship mapping table, concatenated into the alarm description information, and also filled into the alarm record object. This ensures that the alarm information contains both a structured representation of the triggering path and readable rule text, making it easier for operations and maintenance personnel to quickly understand the cause of the alarm.

[0012] As a preferred implementation, when using a stack structure to implement depth-first traversal, an evaluation timeout threshold is set for each event, and the start time of evaluation is recorded when the top node of the stack is popped during looping. If the evaluation time of the current node exceeds the evaluation timeout threshold, the traversal of the child nodes of that node is skipped, and the node identifier is added to the timeout node list. This can avoid evaluation blocking caused by complex events or rule design flaws, and ensure the overall real-time performance of the alarm system.

[0013] The parent-child relationship mapping table can adopt a doubly linked list structure. Each node stores a list of child nodes and also stores the parent node identifier to support reverse lookup. This bidirectional association makes path reconstruction and extraction of conditional expression text more direct, reducing traversal overhead.

[0014] The comparison operations in the conditional expression include numerical comparison and string pattern matching. Furthermore, if the corresponding attribute value is missing from the event attribute dictionary, the conditional node is evaluated as false. This default processing strategy ensures the robustness of the evaluation process, prevents abnormal interruptions due to missing event data, and allows the alarm rules to continue operating normally even when data quality is unstable.

[0015] The technical effects and advantages provided by the present invention in the above technical solution are as follows: The alarm rule condition tree is defined using JSON format. Each node contains a node type, a condition expression, and a list of child nodes. Node types support conditional nodes, logical AND nodes, logical OR nodes, and logical NOT nodes. This nested structure allows complex alarm judgment logic to be described as a tree combination of arbitrary depth, enabling a single rule to carry multiple levels of logical operations. This avoids the redundancy and logical fragmentation caused by splitting nested conditions into multiple independent rules. The configured alarm rules intuitively reflect the membership and combination relationships between conditions, allowing configuration personnel to quickly understand the overall judgment process. During the rule parsing phase, a unique node identifier is assigned to each node, and a parent-child relationship mapping table is built. This transforms the JSON tree configuration into an internally traversable data model. The mapping table supports quick lookup of node parent-child relationships, allowing the traversal and evaluation process to directly locate child nodes and pass evaluation results, improving event processing efficiency.

[0016] During the event traversal and evaluation process, when event data satisfies the conditions of all nodes on the path from the root node to a certain leaf node, the node identifiers of all nodes on that path are extracted to form a path identifier sequence, which is used as a key field in the alarm record. The alarm record not only includes the event timestamp and event source identifier, but also identifies the specific condition branch path that triggered the alarm. This path identifier sequence completely records the step-by-step judgment results from the root node condition to the final leaf node. Even if multiple branches are defined in the alarm rule, the alarm record can accurately distinguish the actual condition link that is met. When viewing alarms, operations and maintenance personnel can trace back the evaluation of each level of conditions through the path identifier sequence, eliminating the need for manual re-checking of the correspondence between event data and rule conditions, significantly shortening the time for alarm analysis and fault localization. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this invention. For those skilled in the art, other drawings can be obtained based on these drawings.

[0018] Figure 1 This is a flowchart of the alarm log generation method based on JSON condition tree; Figure 2 This is a flowchart of the real-time event condition tree evaluation process; Figure 3 This is a comparison chart of event evaluation time and timeout threshold; Figure 4 This is a distribution diagram of the number of alarm record path nodes. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0020] See Figure 1 This invention provides a method for generating alarm records based on a JSON condition tree. The method includes: acquiring alarm rule configuration data, which defines a condition tree in JSON format, where each node of the condition tree contains a node type, a condition expression, and a list of child nodes; parsing the condition tree, assigning a node identifier to each node, and constructing a parent-child relationship mapping table with the node identifier as the key; receiving real-time event data, and for each event, traversing the condition tree starting from the root node, evaluating whether the event data meets the conditions based on the node type and condition expression of each traversed node; when the event data meets the conditions of all nodes on the path from the root node to a certain leaf node, extracting the node identifiers of all nodes on the path to form a path identifier sequence; and generating an alarm record based on the path identifier sequence, wherein the alarm record contains an event timestamp, an event source identifier, and the path identifier sequence.

[0021] Example 1: In practice, the process of obtaining alarm rule configuration data is collaboratively handled by the configuration interface, the configuration center, and the JSON parser. The configuration interface provides the alarm log generation system with a channel to receive subscription information from external sources. It receives the subscribed topic name, a string type, used to uniquely identify the storage location of a type of alarm rule within the configuration center. In some embodiments, the configuration interface is implemented as a RESTful endpoint based on the HTTP protocol. The endpoint address is bound to the alarm rule management service, and the caller includes the topic name parameter in the request body. The configuration interface parses the request and extracts the topic name. The configuration interface also has an authentication function for the caller, using methods such as token verification or certificate verification. After successful authentication, the topic name is transmitted to the configuration center interaction module.

[0022] The configuration center retrieves the corresponding JSON string based on the extracted topic name. The configuration center maintains a mapping between topic names and JSON strings, where the JSON string is a serialized representation of a condition tree. In some embodiments, the configuration center uses a distributed key-value store system, with the topic name as the key and the JSON string as the value. The retrieval operation is completed via a network request. The configuration center's interaction module constructs a query request containing the topic name. Upon receiving the query request, the configuration center searches for a JSON string matching the topic name. If a match is found, the JSON string and a status code are returned; otherwise, an error message is returned. Optionally, a caching mechanism can be enabled during the retrieval process. This involves temporarily storing the retrieved JSON string in local memory and setting a cache expiration time. When a request for the same topic name is received again, it is preferentially read from the cache to reduce the frequency of access to the configuration center.

[0023] After obtaining the JSON string, its syntax and validity are validated. Syntax validation checks whether the JSON string conforms to the JSON format specification, preventing anomalies in subsequent parsing. The validation process is executed by a pre-defined validator, which scans the JSON string character by character based on the standard JSON syntax rules. These scanning rules include: checking if the string uses curly braces or square brackets as start and end symbols; checking if key-value pairs are separated by commas; checking if the string is enclosed in double quotes; checking if the numeric format is valid; and checking for disallowed control characters. In some embodiments, the validator also validates structural constraints specific to the condition tree, such as ensuring that each node object must contain a node type field and a list of child nodes, that the value of the node type field must be one of the preset enumerated values, and that the condition expression field in the condition node cannot be empty. If the validation fails, the validator generates a validation report containing the error line number and error type, interrupts the subsequent process, and returns a syntax validation failure response to the caller.

[0024] After successful validation, a JSON parser is used to parse the JSON string into a tree-like data structure in memory. The JSON parser recursively parses the JSON object, mapping each key-value pair in the JSON object to a property of the memory object. The root node of the tree-like data structure is generated from the outermost object of the JSON string and contains three basic properties: node type, conditional expression, and a list of child nodes. The list of child nodes is an array, where each element is a JSON object corresponding to a child node. During parsing, the list of child nodes is processed recursively, creating a memory object for each child node and establishing parent-child reference relationships, ultimately forming a complete tree-like data structure in memory, where each node corresponds to a JSON object. Optionally, each node in the tree-like data structure stores its properties using a dictionary mapping, with the property names matching the JSON keys for easy and fast access.

[0025] After the tree data structure is constructed, a unique UUID is added to each node as a node identifier. The UUID generation uses the standard UUID version 4 algorithm to ensure the global uniqueness of different node identifiers. The process of adding a node identifier is as follows: traverse all nodes in the tree data structure, generate a UUID string for each node, and assign the UUID string to the node's identifier attribute. During the traversal, either depth-first or breadth-first traversal order can be used; the traversal order does not affect the uniqueness and subsequent use of the node identifier. After adding the node identifier, each node has a fixed identity marker, which can be accurately referenced during the subsequent construction of the parent-child relationship mapping table and the generation of path identifier sequences. After the node identifier assignment is completed, the complete condition tree along with the node identifiers is passed to the parsing module for further processing.

[0026] Example 2: In specific implementation, please refer to Figure 2 The process of receiving real-time event data is completed by the event access module, which obtains real-time event data streams from event sources such as message middleware, log collectors, or monitoring agents. Each piece of real-time event data arrives in a structured format, including an event timestamp, event source identifier, event type description, and a set of event attribute key-value pairs. The event access module preprocesses the raw event data, including field integrity verification and illegal character filtering. Ineligible event data is discarded and a discard log is recorded.

[0027] For preprocessed real-time event data, the event access module encapsulates the real-time event data into event objects. The event object is an in-memory data structure containing three top-level fields: event type, event source, and event attribute dictionary. The event type field stores the name of the event category; the value of the event type is defined by the event source, such as "CPU usage alarm" or "insufficient disk space." The event source field stores the hostname, container identifier, or service instance identifier that generated the event. The event attribute dictionary field is a collection of key-value pairs, where the key is the attribute name string, and the value is the corresponding value of the attribute; the value type can be numeric, string, or boolean. During the encapsulation process, the event access module parses the original fields of the real-time event data, mapping the event type field to the corresponding position in the event object, mapping the event source identifier to the event source field, and filling the remaining attribute fields into the event attribute dictionary. When some attributes are missing in the original event data, no corresponding key is created in the event attribute dictionary; the missing attribute is handled according to the set rules during subsequent condition evaluation, returning false.

[0028] After encapsulating the event object, the traversal control module retrieves the list of child nodes of the root node from the constructed parent-child relationship mapping table. This mapping table is generated during the condition tree parsing phase and stores the parent-child relationships associated with the structure and node identifiers. The traversal control module queries the record corresponding to the root node identifier in the mapping table and reads the list of child node identifiers. When the condition tree is loaded for the first time, the list of child nodes of the root node is already determined and remains unchanged during subsequent traversals. If the mapping table does not contain a record for the root node identifier or the list of child nodes is empty, it indicates that the condition tree only contains the root node or there is a configuration error. In this case, the traversal control module directly ends the evaluation of the current event without generating an alarm record.

[0029] After obtaining the list of child nodes of the root node, the traversal control module sets the current node reference as the root node. The current node reference is a state variable during the traversal process, used to mark the position of the node being processed. The root node is the top-level node of the condition tree, and its node type is one of logical AND, logical OR, or logical NOT nodes. The root node does not contain a conditional expression. After initializing the current node, the traversal control module enters the depth-first traversal process.

[0030] A stack structure is used to implement depth-first traversal. The stack is a last-in-first-out linear data structure, and the elements in the stack are the node identifiers of the nodes to be evaluated. At the beginning of the traversal, the traversal control module creates an empty stack and pushes the node identifier of the root node onto the top of the stack. Then, a loop popping process is entered: in each loop, a node identifier is popped from the top of the stack, and the corresponding node object is retrieved from the condition tree node index based on the node identifier. The node type field of the node is then read. Possible values ​​for the node type include condition node, logical AND node, logical OR node, and logical NOT node.

[0031] After popping the top node from the stack and reading its type, the node is evaluated. For logical AND and logical OR nodes, the traversal control module retrieves the list of child nodes from the parent-child relationship mapping table and pushes the child node identifiers onto the stack in reverse order, so that the left child node is processed first in the next loop, achieving a depth-first access order. For logical NOT nodes, since they have only one child node, the child node identifier is directly pushed onto the stack. For conditional nodes, the evaluation logic of the conditional expression is executed, and no new stack push operation is generated after the evaluation is completed.

[0032] During the process of popping the top node from the stack, an evaluation timeout threshold is set for each event. The evaluation timeout threshold is a time value in milliseconds, defining the upper limit of the cumulative evaluation time for a single event across all nodes in the condition tree. The value of the evaluation timeout threshold is obtained through a system configuration parameter named "event_evaluation_timeout_ms", with a default value of 500 milliseconds. Before starting the traversal of an event, the traversal control module records the event evaluation start timestamp; before each pop of the top node from the stack and before starting the condition evaluation of a node, it checks whether the difference between the current system time and the event evaluation start timestamp exceeds the evaluation timeout threshold.

[0033] If the difference between the current system time and the event evaluation start timestamp exceeds the evaluation timeout threshold when the current node begins evaluation, the traversal of the current node's child nodes is skipped. Specifically, the traversal control module does not perform node condition evaluation, nor does it push the node's child node identifiers onto the stack. Instead, it directly adds the current node's identifier to the timeout node list. The timeout node list is a linear list maintained during the current event evaluation process, used to record node identifiers that are skipped due to timeout. After adding a node to the timeout node list, the traversal control module continues the next loop, processing the remaining nodes in the stack. If the stack is empty, the event evaluation ends.

[0034] If the time difference does not exceed the evaluation timeout threshold when the current node begins evaluation, the node evaluation process proceeds normally. For conditional nodes, the evaluation operation extracts the attribute values ​​referenced in the conditional expression from the event attribute dictionary, performs comparison operations, and obtains a Boolean result. For logical nodes, the evaluation operation performs logical combinations based on the results of the already evaluated child nodes.

[0035] The condition tree traversal process for the current event ends when all reachable nodes have completed evaluation or been skipped due to timeout, and the stack is empty. The traversal control module outputs the list of timeout nodes along with the evaluation results of the conditions for satisfying the path, for use in the subsequent path identifier sequence generation stage. The list of timeout nodes can be used during the alarm record generation stage to mark which nodes have not completed evaluation, avoiding incomplete alarm descriptions due to missing information.

[0036] See Figure 3 In the graph, the horizontal axis represents the event sequence number, ranging from 0 to 500, and the vertical axis represents the event evaluation time, in milliseconds (ms), ranging from 0 to 2200. The scatter plot in the graph vividly illustrates the distribution of event evaluation times for the 500 real-time event data received in Example 2. The vertical distribution of the scatter points shows that the evaluation times for most events are concentrated in the range of 0 to 400 milliseconds, while the evaluation times for a few events are significantly higher, with the highest approaching 2000 milliseconds. This indicates that some events have a long computational delay during the condition tree traversal and node evaluation process.

[0037] The graph shows two horizontal reference lines. The solid red line represents the default evaluation timeout threshold of 500 milliseconds, while the dashed orange line represents a lower evaluation timeout threshold of 300 milliseconds. It can be seen that the vast majority of events take less than 300 milliseconds to evaluate, a small number of events take between 300 and 500 milliseconds, and a very small number of events take more than 500 milliseconds, reaching and exceeding the evaluation timeout threshold.

[0038] This figure illustrates the effectiveness of the traversal control module in applying the event evaluation timeout threshold in Example 2. The system defaults to 500 milliseconds as the upper limit for the cumulative event evaluation time. The data in the figure shows that this threshold can effectively limit the evaluation time of the vast majority of events, preventing the system's processing performance from degrading due to excessively long individual event processing times. Meanwhile, the dashed reference threshold of 300 milliseconds demonstrates a stricter standard for evaluation time control, helping the system adjust the timeout threshold parameter "event_evaluation_timeout_ms" according to actual needs, thus flexibly controlling the response time of event processing.

[0039] Example 3: In practice, the condition evaluation for each traversed node is performed by the node evaluation module. The node evaluation module receives three input parameters: the node object of the currently traversed node, the encapsulated event object, and the evaluation context. The node object is obtained from the node index of the condition tree by node identifier and contains a node type field, a condition expression field, and a list of child node identifiers field. The event object provides a dictionary of event type, event source, and event attributes. The evaluation context is used to pass intermediate results during recursive evaluation.

[0040] The node evaluation module reads the node type field from the node object and executes the corresponding evaluation logic based on the value of the node type. The node type can take four values: condition node, logical AND node, logical OR node, and logical NOT node. The evaluation logic for each of the four node types is as follows.

[0041] When the node type is a conditional node, the node evaluation module executes the conditional expression evaluation process. The conditional expression is stored as a string, defining a comparison operation. The comparison operation consists of three parts: the left operand, the comparison operator, and the right operand. The left operand is the attribute name from the event attribute dictionary, and the right operand is the comparison threshold. The comparison operators include eight types: equal to, not equal to, greater than, less than, greater than or equal to, less than or equal to, contain, and not contain. The node evaluation module parses the conditional expression string, extracting the attribute name, comparison operator, and comparison threshold. The extraction process uses regular expression matching; the regular expression pattern varies depending on the comparison operator. Upon successful matching, all three components are captured.

[0042] After extraction, the node evaluation module searches the event attribute dictionary for the attribute value corresponding to the extracted attribute name. The search process iterates through the key-value pairs in the event attribute dictionary using the attribute name as the key. When a key exactly matches the attribute name, the corresponding attribute value is retrieved. If the event attribute dictionary lacks a key corresponding to the attribute name (i.e., the attribute does not exist in the event data), the condition node's evaluation result directly returns false, and no further comparison operations are performed. When the event attribute dictionary contains a corresponding attribute value, the node evaluation module performs the appropriate comparison operation based on the type of comparison operator.

[0043] Comparison operations include two categories: numerical comparison and string pattern matching. When the comparison operator is equal to, not equal to, greater than, less than, greater than or equal to, or less than or equal to, numerical comparison is performed. Numerical comparison requires both the attribute value and the comparison threshold to be numeric types. The node evaluation module converts the string representation of the attribute value to a double-precision floating-point number, and also converts the string representation of the comparison threshold to a double-precision floating-point number. If the conversion fails, the evaluation result returns false. After successful conversion, the numerical size is compared according to the semantics of the comparison operator. The equality operator is determined when the absolute value of the difference between the attribute value (floating-point) and the comparison threshold (floating-point) is less than a very small positive number. This very small positive number is... The setting of the minimum positive number is based on the comparison tolerance convention of IEEE 754 double-precision floating-point numbers; the determination rule for the inequality operator is that the absolute value of the difference is greater than or equal to the minimum positive number; the determination rule for the greater than operator is that the floating-point value of the attribute is greater than the comparison threshold floating-point number; the determination rule for the less than operator is that the floating-point value of the attribute is less than the comparison threshold floating-point number; the determination rule for the greater than or equal to operator is that the floating-point value of the attribute is greater than the comparison threshold floating-point number or the absolute value of the difference is less than the minimum positive number; the determination rule for the less than or equal to operator is that the floating-point value of the attribute is less than the comparison threshold floating-point number or the absolute value of the difference is less than the minimum positive number.

[0044] When the comparison operator is either inclusive or exclusive, string pattern matching is performed. String pattern matching requires that both the attribute value and the comparison threshold be treated as strings. The node evaluation module converts the attribute value into a string representation and uses the comparison threshold as the matching pattern. The inclusion operator searches for the comparison threshold string within the attribute value string; if a substring match is found, it returns true; otherwise, it returns false. The exclusive operator negates the inclusion, searching for the comparison threshold string within the attribute value string; if not found, it returns true; otherwise, it returns false. String pattern matching uses a case-sensitive substring search algorithm. When the comparison threshold string is empty, the inclusion operator returns true; the exclusive operator returns false.

[0045] When the node type is a logical AND node, the node evaluation module obtains the list of child node identifiers for that logical AND node. The evaluation logic of the logical AND node is to recursively evaluate the node object corresponding to each child node identifier in the list of child node identifiers, performing a logical AND operation on the Boolean result of each child node evaluation. The recursive evaluation process of child nodes is as follows: the node evaluation module traverses the list of child node identifiers, and for each child node identifier, retrieves the child node object from the node index, calls the node evaluation module with the child node object, event object, and evaluation context as parameters, and obtains the child node evaluation result; if the evaluation result of a certain child node returns false, the traversal of the remaining child nodes is stopped, and the logical AND node directly returns false; if the evaluation results of all child nodes return true, the logical AND node returns true. When the list of child node identifiers is empty, the logical AND node returns true.

[0046] When the node type is a logical OR node, the node evaluation module obtains the list of child node identifiers for that logical OR node. The evaluation logic of the logical OR node is to recursively evaluate the node object corresponding to each child node identifier in the list of child node identifiers, performing a logical OR operation on the Boolean result of each child node evaluation. The node evaluation module traverses the list of child node identifiers, and for each child node identifier, retrieves the child node object from the node index and calls the node evaluation module for recursive evaluation; if the evaluation result of a child node returns true, the traversal of the remaining child nodes stops, and the logical OR node directly returns true; if the evaluation results of all child nodes return false, the logical OR node returns false. When the list of child node identifiers is empty, the logical OR node returns false.

[0047] When the node type is a logical NOT node, the node evaluation module retrieves the identifiers of its child nodes. A logical NOT node has only one child node, and the child node identifier is a single value. The node evaluation module retrieves the child node object from the node index, calls the node evaluation module with the child node object, the event object, and the evaluation context as parameters, and obtains the child node evaluation result. A logical NOT node negates the child node evaluation result; that is, it returns false if the child node evaluation result is true, and true if the child node evaluation result is false. A logical NOT node returns true if the child node identifier does not exist.

[0048] The evaluation results for all four node types are Boolean values. The node evaluation module returns the Boolean result to the traversal control module. The traversal control module determines whether to continue traversing the path and whether to record path information based on the returned Boolean result. The evaluation process for conditional nodes involves extremely small positive numbers. In conditional expressions, this is used for tolerance handling when determining equality between double-precision floating-point numbers. The value of this extremely small positive number is specified by the system configuration parameter "float_comparison_epsilon", with a default value of [value missing]. The setting is based on the fact that the precision of a double-precision floating-point number is approximately [precision value missing] when the value is close to zero. Order of magnitude, take It can accommodate a reasonable tolerance for numerical equality determination in most application scenarios.

[0049] Example 4: In practice, the path maintenance module is responsible for maintaining the path stack during the depth-first traversal. The path stack is a linear data structure, implemented using an array or linked list, storing node identifier strings. The path stack is initially empty. Simultaneously, the path maintenance module pushes the root node identifier onto the path stack while the traversal control module pushes it onto the traversal stack. The path stack and traversal stack are updated synchronously, but the path stack records the complete node sequence from the root node to the currently visited node on the current depth-first traversal path, while the traversal stack records the set of nodes whose child nodes have not yet been evaluated.

[0050] During depth-first traversal, whenever the traversal control module determines to enter a child node, the path maintenance module pushes the current node identifier onto the path stack. Here, "current node" refers to the node that has just been popped from the traversal stack, has completed node type determination, and is about to recursively push its child nodes onto the stack. Specifically, after the traversal control module pops a node identifier from the traversal stack and obtains the node object, the path maintenance module reads the list of child node identifiers of the node object. When the list of child node identifiers is not empty, the traversal control module pushes the child node identifiers onto the traversal stack in reverse order. The path maintenance module then detects the increase in the traversal stack depth and pushes the node identifier of the node object onto the path stack. After the push operation is completed, the top element of the path stack is the newly expanded node identifier, and the sequence from the bottom to the top of the path stack is the path from the root node to the current node.

[0051] During traversal, when a node is evaluated and backtracking occurs, the path maintenance module needs to pop the corresponding node identifier from the path stack. Backtracking occurs when all child nodes of a node in the traversal stack have been processed. The path maintenance module determines whether to pop the node by comparing the depth of the top node identifier of the path stack with that of the node to be processed in the condition tree. If the depth of the currently processed node is shallower than that of the top node of the path stack, the path maintenance module performs the pop operation until the depth of the top node of the path stack matches that of the currently processed node. Depth is defined as the number of levels of a node in the condition tree from the root node, with the root node having a depth of 0. The depth value is calculated during the condition tree parsing phase and stored in the depth field of each node object.

[0052] When the evaluation reaches a leaf node, the leaf node is determined by whether the node object's child node identifier list is empty. After evaluating the leaf node conditions, if the leaf node conditions are met (i.e., the boolean result returned by the node evaluation module for the leaf node is true), the traversal control module triggers the path extraction process. At the moment the leaf node conditions are met, the sequence of node identifiers stored in the path stack exactly represents all node identifiers on the complete path from the root node to the leaf node. The path maintenance module creates a path identifier list and copies all elements from the path stack to the path identifier list in order from the bottom of the stack to the top. After copying, the order of elements in the path identifier list is consistent with the traversal order from the root node to the leaf node in the condition tree.

[0053] After obtaining the list of path identifiers, the path maintenance module concatenates all node identifiers in the list into a string sequence. During the concatenation operation, the path maintenance module creates a string builder, iterates through each node identifier in the list, appends the node identifier to the string builder, and inserts a separator between adjacent node identifiers. The separator is a single character, specifically the semicolon ";". The value of the separator is specified by the system configuration parameter "path_separator", with a default value of a semicolon. This default value is set because semicolons do not appear in UUID format node identifiers, thus avoiding confusion between the separator and the node identifier content. After concatenation, the string builder generates a string sequence, which is the path identifier sequence. The path identifier sequence completely records a node identifier path that satisfies the conditions of the event data.

[0054] After extracting the path identifier sequence, the alarm record generation module generates an alarm record based on the path identifier sequence. The alarm record generation module creates an alarm record object, which is a structure containing an event timestamp field, an event source identifier field, a path identifier sequence field, and an alarm description field. The value of the event timestamp field is extracted from the event object and is the UTC timestamp of the event occurrence, in ISO8601 string format. The value of the event source identifier field is extracted from the event source field of the event object. The value of the path identifier sequence field is the string sequence output by the path maintenance module.

[0055] The alarm logging module retrieves the conditional expression text corresponding to each node on the path from the parent-child relationship mapping table, which is used to concatenate the alarm description information. The parent-child relationship mapping table is constructed during the condition tree parsing phase. Besides storing parent-child relationships, it also stores the mapping between each node identifier and its detailed information. Node details include node type, conditional expression text, and node name. The alarm logging module parses the path identifier sequence, splitting it into multiple node identifiers using a delimiter. For each node identifier obtained from the splitting, the alarm logging module retrieves the corresponding detailed information from the parent-child relationship mapping table using the node identifier as the key, and reads the conditional expression text field from the node details. For node identifiers of logical AND, logical OR, or logical NOT node types, the conditional expression text field is empty, and the alarm logging module skips text concatenation. For node identifiers of condition node type, the conditional expression text field stores the original configured conditional expression string, which the alarm logging module concatenates sequentially. During concatenation, a connection string is inserted between adjacent conditional expression strings; the connection string varies depending on the node type. When the parent node type is a logical AND node, the connection string is "AND"; when the parent node type is a logical OR node, the connection string is "OR"; and when the parent node type is a logical NOT node, the connection string is "NOT". The parent node type is obtained as follows: for each node identifier in the path identifier sequence, look up the parent node identifier in the parent-child relationship mapping table, and then look up the corresponding node type using the parent node identifier. The root node identifier is not involved in the concatenation of the conditional expression text.

[0056] The assembled alarm description is a string describing the combination of conditions that triggered the alarm. The alarm record generation module fills the alarm description information into the alarm description field of the alarm record object. At this point, a complete alarm record object is generated, containing four fields: event timestamp, event source identifier, path identifier sequence, and alarm description information. The alarm record generation module then outputs the alarm record object to the alarm storage module or alarm notification module for further processing.

[0057] See Figure 4 In the graph, the horizontal axis represents the number of path nodes, that is, the number of nodes contained in the path from the root node to the leaf node, with a value ranging from 0 to 24; the vertical axis represents the number of alarm records for the corresponding number of path nodes, in units of records. The graph uses purple bars to show the distribution of the number of alarm records, and the red curve is the trend line of this distribution, reflecting the overall trend of the number of alarm records changing with the number of path nodes.

[0058] As observed in the graph, the number of alarm records gradually increases when the number of path nodes is small, reaching a peak of approximately 90 to 100 records when the number of path nodes is between 4 and 6, indicating that most paths meeting the alarm conditions are concentrated in the short to medium path range. Subsequently, after the number of path nodes exceeds 6, the number of alarm records begins to decrease significantly, showing a monotonically decreasing trend, until it approaches zero when the number of path nodes exceeds 15, indicating that alarms triggered by long path conditions are less frequent.

[0059] The trend line in the figure approximates a positively skewed distribution, indicating that the distribution of alarm path node numbers exhibits a significant skewness. Combined with the description of the path identifier sequence by the path maintenance module in Example 4, this distribution reflects the alarm path length characteristics generated by depth-first traversal based on the JSON condition tree structure. This indicates that the lengths of the condition-satisfying paths corresponding to the vast majority of alarm records are relatively concentrated, making it suitable for further optimization of the performance of the path maintenance and alarm description generation algorithms.

[0060] Furthermore, the number of alarm records is relatively low when the number of path nodes is between 1 and 3, indicating that fewer alarms are triggered by extremely short paths. This may be because the root node itself is a logical node and has no conditional expression, so triggering an alarm actually requires a combination of multiple conditional nodes. In the range where the number of path nodes exceeds 10, the number of alarm records is extremely low, reflecting that complex conditional paths are rarely satisfied, demonstrating the relationship between the hierarchical complexity of the condition tree and the actual alarm triggering frequency.

[0061] Example 5: In practice, the parsing of the condition tree is performed by the condition tree parsing module. This module receives a tree-like data structure after processing by the JSON parser. Each node in the tree structure corresponds to a JSON object, and each JSON object contains a node type field, a conditional expression field, and a list of child nodes. The condition tree parsing module recursively traverses the tree structure, starting from the root node, and performs node identifier assignment and parent-child relationship recording operations for each visited node.

[0062] The condition tree parsing module defines a recursive traversal function that accepts two input parameters: the currently visited node object and the identifier of its parent node. On the first call to the recursive traversal function, the root node of the tree data structure is used as the currently visited node object, and a null value is passed as the parent node identifier. A null value indicates that the currently visited node is the root node and has no parent node.

[0063] Inside the recursive traversal function, a UUID is first generated for the currently visited node as its node identifier. The UUID generation uses the UUID version 4 algorithm defined in RFC4122. This algorithm uses random or pseudo-random numbers to generate the various fields of the UUID, ensuring the global uniqueness of different node identifiers. After generation, the resulting UUID string is assigned to the node identifier attribute of the currently visited node, enabling it to be uniquely identified in subsequent processes.

[0064] After assigning node identifiers, the condition tree parsing module records parent-child relationships. The condition tree parsing module maintains a hash table as a parent-child relationship mapping table, with node identifiers as keys and relationship record structures as values. The relationship record structure contains two fields: a child node identifier list field and a parent node identifier field. The child node identifier list field stores the set of node identifiers for all direct child nodes of the currently visited node, and the parent node identifier field stores the node identifier of the parent node of the currently visited node.

[0065] For the currently visited node, the following operations are performed in the parent-child relationship mapping table: A relationship record structure is created in the parent-child relationship mapping table using the node identifier of the currently visited node as the key. The parent node identifier field of this relationship record structure is set to the parent node identifier parameter value passed to the recursive traversal function. The child node identifier list field of this relationship record structure is initialized to an empty list. Simultaneously, it is checked whether the passed parent node identifier parameter is null. If the parent node identifier parameter is not null, the corresponding relationship record structure is searched in the parent-child relationship mapping table using the parent node identifier parameter as the key. The node identifier of the currently visited node is appended to the child node identifier list of the found relationship record structure. Through the above operations, each node visit establishes a bidirectional association between the currently visited node and its parent node in the parent-child relationship mapping table.

[0066] After recording the relationships of the currently visited node, the condition tree parsing module obtains the list of child nodes of the currently visited node. This list is read from the JSON object of the currently visited node and is a JSON array. The condition tree parsing module iterates through each child node object in the list. For each child node object, it uses that child node object as the new currently visited node object and its identifier as the new parent node identifier, recursively calling the recursive traversal function. This recursive calling continues until all nodes in the tree data structure have been processed.

[0067] After all recursive calls are completed, the parent-child relationship mapping table is constructed. The parent-child relationship mapping table maintains a relationship record for each node in the condition tree, and each relationship record contains a list of child node identifiers and a parent node identifier. This structure logically forms a doubly linked list: starting from any node identifier, the direct child nodes can be traversed forward using the corresponding child node identifier list in the parent-child relationship mapping table; the direct parent node can be found backward using the corresponding parent node identifier in the parent-child relationship mapping table. Continuously using the parent node identifier for backward lookup allows traversing from the current node all the way back to the root node, achieving a complete reverse path traversal.

[0068] In the internal storage implementation of a hash table, the node identifier, acting as the key, needs to be mapped to a specific storage slot. The hash function uses a multiplicative hash algorithm, and the formula for calculating the hash function is as follows:

[0069] In the formula, This represents the calculated hash slot index number. It is an integer type. The range of values ​​for is arrive Closed intervals of integers between; This represents the total number of slots in the hash storage structure within the parent-child relationship mapping table. The value of is a prime number. The specific value is specified by the system configuration parameter "hash_table_size", with a default value of 0. Set the default value to The basis is To get closer Furthermore, for values ​​that satisfy the prime condition, using prime numbers as the hash table size can reduce the clustering phenomenon caused by modulo operations; This represents the integer value obtained by converting the node identifier. The node identifier is in UUID string format. The conversion method is as follows: after removing the hyphen from the UUID string, input it into the MD5 digest algorithm to generate a 128-bit digest value. Take the first 64 bits of the 128-bit digest value as the unsigned integer value. This unsigned integer value is the integer value. ; Represents the multiplication hash constant. The value is This value is the fractional part of the golden ratio. According to the theory of multiplicative hashing proposed by D. Knuth, using constants related to the golden ratio can make the distribution of keys more uniform. This represents real number multiplication; $\mod$ represents the modulo operation on a real number. This represents taking the decimal part of a product of real numbers; This represents the floor function. The hash function calculated above yields the result... The value is used to locate the corresponding slot in the internal storage array of the parent-child relationship mapping table, so as to achieve fast access to the relationship record structure.

[0070] With the parent-child relationship mapping table structured as described above (doubly linked list), when it's necessary to reverse-search for the parent node of a given node, the corresponding relationship record structure is directly searched in the parent-child relationship mapping table using the node identifier of that node as the key. The parent node identifier field in the relationship record structure is then read to obtain the parent node identifier. If the parent node identifier is not null, the search for the parent node's parent node identifier can continue using the parent node identifier as the key, repeating this process until the root node is reached. This doubly linked list structure simplifies the reverse search process required during alarm record generation, such as tracing back the path from leaf nodes and extracting conditional expression text.

[0071] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.

Claims

1. A method for generating alarm records based on a JSON condition tree, characterized in that, include: Obtain alarm rule configuration data. The configuration data defines a condition tree in JSON format. Each node of the condition tree contains a node type, a condition expression, and a list of child nodes. The condition tree is parsed, a node identifier is assigned to each node, and a parent-child relationship mapping table is constructed with the node identifier as the key; Receive real-time event data, and for each event, traverse the condition tree starting from the root node. For each traversed node, evaluate whether the event data meets the conditions based on the node type and condition expression of that node. When the event data satisfies the condition of all nodes on the path from the root node to a certain leaf node, extract the node identifiers of all nodes on that path to form a path identifier sequence. An alarm record is generated based on the path identifier sequence. The alarm record includes an event timestamp, an event source identifier, and a path identifier sequence.

2. The alarm record generation method based on JSON condition tree according to claim 1, characterized in that, The acquisition of alarm rule configuration data specifically includes: The system receives the subscribed topic name through the configuration interface and retrieves the corresponding JSON string from the configuration center based on the topic name. The JSON string is subjected to syntax validity validation. After the validation passes, the JSON parser is used to parse it into a tree data structure in memory, where each node corresponds to a JSON object. Add a unique UUID to each node as a node identifier.

3. The alarm record generation method based on JSON condition tree according to claim 2, characterized in that, The process of parsing the condition tree, assigning a node identifier to each node, and constructing a parent-child relationship mapping table with the node identifier as the key specifically includes: The tree data structure is traversed recursively, and a UUID is generated for each node visited as the node identifier. During the traversal, the parent node identifier of the current node is recorded, and the list of child node identifiers is associated with the parent node identifier and stored in a hash table to form a parent-child relationship mapping table.

4. The alarm record generation method based on JSON condition tree according to claim 1, characterized in that, The process of receiving real-time event data and, for each event, traversing the condition tree starting from the root node specifically includes: Real-time event data is encapsulated into event objects, which contain event type, event source, and event attribute dictionary; Obtain the list of child nodes of the root node from the parent-child relationship mapping table, and set the current node as the root node; A stack structure is used to implement depth-first traversal. The root node is pushed onto the stack, and the top node is popped in a loop to determine the node type of the node.

5. The alarm record generation method based on JSON condition tree according to claim 1, characterized in that, The process of evaluating whether the event data satisfies the conditions based on the node type and condition expression for each traversed node specifically includes: If the node type is a condition node, the attribute values ​​related to the condition expression are extracted from the event attribute dictionary, and the comparison operation defined by the condition expression is performed to obtain a Boolean result; If the node type is a logical AND node, then all child nodes are evaluated recursively, and the node returns true when all child nodes return true. If the node type is a logical OR node, then the node returns true if at least one of its child nodes returns true; If the node type is a logical NOT node, then the evaluation result of the child nodes is inverted.

6. The alarm record generation method based on JSON condition tree according to claim 1, characterized in that, When the event data satisfies the condition of all nodes on the path from the root node to a certain leaf node, extracting the node identifiers of all nodes on that path to form a path identifier sequence specifically includes: During the depth-first traversal, a path stack is maintained, and the current node identifier is pushed onto the path stack whenever a child node is entered. When the evaluation shows that a leaf node has been reached and the conditions of that leaf node are met, all node identifiers from the root node to that leaf node in the path stack are popped out in sequence and concatenated into a string sequence, which is connected by a delimiter.

7. The alarm record generation method based on JSON condition tree according to claim 1, characterized in that, The step of generating an alarm record based on the path identifier sequence specifically includes: Create an alarm log object and fill in the event timestamp, event source identifier, and path identifier sequence as fields; The conditional expression text corresponding to each node on the path is retrieved from the parent-child relationship mapping table, concatenated into alarm description information, and then filled into the alarm record object.

8. The alarm record generation method based on JSON condition tree according to claim 4, characterized in that, The method of using a stack structure to implement depth-first traversal, pushing the root node onto the stack, and repeatedly popping the top node from the stack, specifically includes: Set an evaluation timeout threshold for each event and record the start time of evaluation when the top node of the stack is popped in a loop. If the current node's evaluation time exceeds the evaluation timeout threshold, skip the traversal of the node's child nodes and add the node's identifier to the timeout node list.

9. The alarm record generation method based on JSON condition tree according to claim 3, characterized in that, The parent-child relationship mapping table adopts a doubly linked list structure. In addition to storing a list of child nodes, each node also stores the parent node identifier to support reverse lookup.

10. The alarm record generation method based on JSON condition tree according to claim 5, characterized in that, The comparison operations in the conditional expression include numerical comparison and string pattern matching, and the conditional node evaluates to false when the corresponding attribute value is missing in the event attribute dictionary.

Images