Lightweight alarm system based on multi-platform dynamic template rendering

Abstract

The invention relates to a lightweight alarm system based on multi-platform dynamic template rendering. The lightweight alarm system is characterized in that a dynamic template rendering module realizes multi-terminal adaptation by using a Freemarker engine, acquires attributes and self-defined parameters from Exception Message DTO, loads a template according to a template ID and injects the parameters, and generates an alarm message of multi-terminal adaptation; the lightweight rule engine module establishes an abnormal code and alarm level matching rule, and quickly matches and transmits a template ID and abnormal information during alarm; the rule configuration module supports binding of the abnormal code and an alarm level rule, so that a user defines binding of the abnormal code and a template ID; the alarm message pushing module sends messages by means of an open platform API, adopts a unified card template ID, and realizes standardized output and rapid configuration after a template table is modified. According to the method and the system, differential display, rapid configuration and accurate pushing of cross-platform alarm information are realized by combining a dynamic template rendering engine, instant messaging interface integration and a lightweight rule engine technology.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of system monitoring, in particular to a lightweight alarm system based on multi-platform dynamic template rendering. BACKGROUND

[0002] The existing alarm system has the following significant deficiencies:

[0003] Poor multi-platform adaptability: Traditional alarm systems are usually designed for a single technology stack (such as only supporting web terminals), making it difficult to adapt to the differentiated business logic and user interaction needs of PC, APP, and small program systems, resulting in chaotic alarm information display and low operational efficiency.

[0004] Template configuration rigidity: Existing solutions mostly use fixed templates, which cannot dynamically render alarm messages based on exception types or business modules, and lack the ability to customize parameter expansion, resulting in poor readability of alarm information and time-consuming problem localization.

[0005] High complexity of rule engine: Alarm triggering mechanisms that rely on complex data analysis or association rules (such as machine learning models) consume a large amount of computing resources, making it difficult to meet real-time requirements, and lack configuration flexibility, which can easily result in false positives or false negatives.

[0006] Weak consistency of service configuration: The binding of alarm rules and backend services lacks strict constraints, and configuration errors often lead to alarm failures, affecting system stability.

[0007] One of the existing technologies manages alarm configuration through hardware layer configuration management to ensure that alarm rules take effect after device restart, so it is only applicable to hardware device alarms and does not involve multi-platform adaptation and dynamic template rendering for software systems, making it impossible to solve the problem of differentiated display of cross-platform alarm information.

[0008] Another existing technology uses secondary decision-making to suppress alarm false positives, introducing a data analysis model to verify alarm events twice to reduce false positive rates. Due to the reliance on complex computing models, real-time performance is poor, and there is no lightweight rule binding mechanism.

[0009] Yet another existing technology studies the fusion of alarm information from multiple heterogeneous systems and proposes an alarm information aggregation strategy based on data fusion, but does not involve dynamic template rendering technology, resulting in a single alarm information display format that cannot meet the needs of multiple platforms.

[0010] Still another existing technology uses a lightweight microservice alarm framework design, involving an alarm triggering mechanism based on service granularity, but the service binding relies on manual configuration, lacks automatic association with frameworks (such as Spring Boot), and is prone to configuration errors.

[0011] The information disclosed in this Background section is only for the purpose of enhancing the understanding of the general background of the application, and should not be taken as admitting or implying that the information forms the prior art that is already known to those skilled in the art. SUMMARY

[0012] In view of the defects in the prior art, the purpose of the present application is to provide a lightweight alarm system based on multi-platform dynamic template rendering, which combines dynamic template rendering engine, instant messaging interface integration and lightweight rule engine technology to realize differentiated display, rapid configuration and accurate push of cross-platform (PC terminal, mobile terminal APP, applet) alarm information.

[0013] To achieve the above purpose, the technical solution adopted by the present application is:

[0014] The lightweight alarm system based on multi-platform dynamic template rendering comprises:

[0015] The dynamic template rendering module uses the Freemarker engine to realize the dynamic alarm template adaptation of multiple terminals, uses the template parameterization rendering function of the Freemarker engine to obtain attributes and custom parameters customParam from the abnormal information data transmission object ExceptionMessageDTO as template rendering parameters, loads the corresponding template according to the template ID, and injects the template rendering parameters to generate an alarm message adapted to multiple terminals;

[0016] The lightweight rule engine module matches the corresponding alarm template ID from the rule library by establishing the matching rules of abnormal codes and alarm levels, and delivers the template ID and the abnormal information data transmission object ExceptionMessageDTO to the dynamic template rendering module according to the matching rules when an alarm event occurs;

[0017] The rule configuration module supports two types of collection rules binding of abnormal codes exceptionCode and alarm levels alertLevel for each template, and provides user-defined binding relationship between abnormal codes and template IDs, and synchronizes the rule changes to the rule engine module in real time;

[0018] The alarm message push module sends the alarm message through the API of the third-party open platform, creates and uses a unified card template ID, and realizes the standardized output and rapid configuration of the alarm message after modifying the corresponding template table.

[0019] On the basis of the above technical solution, the attributes of the abnormal information data transmission object ExceptionMessageDTO include:

[0020] A source system sourceSystem, identifying the original system name generating the alarm information;

[0021] A service name serviceName, identifying the backend service name triggering the alarm;

[0022] An exception code exceptionCode, uniquely identifying the coding of the exception type.

[0023] On the basis of the above technical solutions, the properties of the exception information data transmission object ExceptionMessageDTO further include:

[0024] A business module businessModule, identifying the module name completing a specific business function in the system;

[0025] A trace identifier TraceId, uniquely identifying the request passed between multiple services;

[0026] An error code ErrCode, which is returned by the system when an exception occurs, and different ErrCodes represent different types of errors;

[0027] A message Message, used to describe the detailed information of the exception.

[0028] On the basis of the above technical solutions, the properties of the exception information data transmission object ExceptionMessageDTO further include:

[0029] An environment identifier env, used to identify the running environment to which the current alarm information belongs;

[0030] According to the environment identifier env, the deployment environment of different stages is distinguished, and it is ensured that the alarm information can be processed differently according to the environment.

[0031] On the basis of the above technical solutions, the differentiated processing refers to selecting different push channels or templates according to the env value.

[0032] On the basis of the above technical solutions, in the design of the lightweight rule engine, the following constraint conditions are set in the rule configuration:

[0033] When a new service is created, the service name must be consistent with the spring.application.name in the configuration file, and then the template is bound and the rule is configured.

[0034] On the basis of the above technical solutions, the lightweight rule engine stores the mapping relationship between the exception code exceptionCode and the alarm level alertLevel through a hash table, and realizes rule matching with O(1) time complexity.

[0035] Based on the above technical solution, the system collects alarm data from multiple terminals, including PC, mobile APP and mini program;

[0036] During the operation of business modules on each end, once an exception occurs, corresponding exception information will be generated and encapsulated in an ExceptionMessageDTO object.

[0037] The encapsulated ExceptionMessageDTO object is sent from each end to the alarm system's collection module via the data transmission channel.

[0038] Based on the above technical solution, the collected alarm data is first stored in a distributed search engine;

[0039] The system builds an index based on the timestamp and anomaly type of the data to quickly locate and retrieve specific alarm data.

[0040] Based on the above technical solution, after the lightweight rule engine starts, it obtains the latest stored alarm data and compares the exception code and alarm level in the alarm data according to the pre-established matching rules of exception code and alarm level.

[0041] If the match is successful, the corresponding alarm handling process will be triggered;

[0042] If a match fails, further processing will be performed according to the preset strategy;

[0043] The alarm handling process specifically includes:

[0044] Once a rule is successfully matched, the system determines the corresponding alarm template based on the matched rule, uses the Freemarker engine for template rendering, and obtains the attributes and custom parameter customParam from the ExceptionMessageDTO object as template rendering parameters.

[0045] The lightweight alarm system based on multi-platform dynamic template rendering described in this invention has the following beneficial effects:

[0046] 1. Dynamic alarm templates that adapt to multiple platforms

[0047] Based on the principles of template engine technology, the Freemarker engine achieves dynamic template rendering by parsing template instructions and obtaining corresponding parameters. When displaying alarm information on different terminals, the display format of the alarm information, such as font size, color, and layout, can be flexibly adjusted according to factors such as the screen size and interaction method of each terminal, thereby improving the user experience.

[0048] 2. Lightweight rules engine design

[0049] By leveraging data matching algorithms, indexes and matching rules are established based on exception codes and alarm levels. When an alarm event occurs, the system can quickly locate the corresponding rule, reducing the time complexity of traversal and calculation, improving alarm processing efficiency, and reducing computing resource consumption.

[0050] 3. Standardization of card templates

[0051] Based on data management and standardization specifications, a unified template ID is adopted to achieve standardized operations in database and configuration management. By modifying the template table, alarm messages can be quickly updated and configured, ensuring the consistency of message format, facilitating unified management and viewing by operations and maintenance personnel, and improving work efficiency.

[0052] 4. Strong consistency between service and alarm rules

[0053] Based on system configuration management principles, the service name is uniformly configured using `spring.application.name`, ensuring accurate association between services and alarm rules. This configuration method reduces inaccurate alarms caused by configuration errors, improving the stability and reliability of the alarm system from the system architecture level.

[0054] Compared to existing technologies, in terms of multi-terminal adaptation, existing technologies struggle to meet the diverse display needs of different terminals. This technical solution achieves precise adaptation through dynamic alarm templates. Regarding alarm processing efficiency, existing rule matching methods may consume significant computing resources and are slow. This solution's lightweight rule engine effectively solves this problem. In terms of message management, existing technologies suffer from inconsistent alarm message formats and inconvenient management. This solution's standardized DingTalk card templates improve the convenience of message management. Regarding service and rule association, existing technologies are prone to configuration errors. This solution avoids such problems through a strong consistency design, improving the accuracy and stability of the alarm system.

[0055] This technical solution is applicable to distributed system monitoring and operation and maintenance management scenarios, especially suitable for industries such as e-commerce and finance that require multi-terminal collaboration. It can be used to monitor, process, and notify alarms from multiple terminals such as PCs, APPs, and mini-programs, solving problems such as complex business modules and untimely and inaccurate alarm processing in multi-terminal systems. Attached Figure Description

[0056] The present invention includes the following figures:

[0057] The accompanying drawings are provided to better understand the invention and are not intended to unduly limit the scope of the invention. Wherein:

[0058] Figure 1 The system architecture diagram of Embodiment 1 of the lightweight alarm system based on multi-platform dynamic template rendering described in this invention. Detailed Implementation

[0059] The present invention will be further described in detail below with reference to the accompanying drawings. This detailed description is an illustration in conjunction with exemplary embodiments of the invention, including various details of the embodiments to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of the invention. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0060] like Figure 1 As shown, the lightweight alarm system based on multi-platform dynamic template rendering of the present invention includes:

[0061] The dynamic template rendering module uses the Freemarker engine to implement dynamic alarm templates that are compatible with multiple platforms. It utilizes the Freemarker engine's template parameterized rendering function to obtain attributes and custom parameters customParam from the exception information data transmission object ExceptionMessageDTO as template rendering parameters. Freemarker is a Java-based template engine used to dynamically generate text output. The exception information data transmission object ExceptionMessageDTO is a structured data object used to encapsulate exception information.

[0062] The lightweight rules engine module establishes matching rules between exception codes and alarm levels. When an alarm event occurs, it quickly matches the corresponding rule based on the matching rules, reducing unnecessary consumption of computing resources and improving alarm processing efficiency.

[0063] The rule configuration module supports binding of two types of rules for each template: exception code (exceptionCode) and alarm level (alertLevel), ensuring the accuracy and efficiency of rule matching.

[0064] The alarm message push module sends alarm messages through the API of a third-party open platform, creates and uses a unified card template ID, and achieves standardized output and rapid configuration of alarm messages after modifying the corresponding template table; the third-party open platform includes but is not limited to DingTalk, WeChat Work, and Lark, with DingTalk interface being used by default.

[0065] In this embodiment, the Freemarker engine provides the foundation for multi-terminal adaptation, enabling different terminals to display alarm information that matches their own characteristics; the lightweight rule engine improves alarm processing efficiency by quickly matching rules based on exception codes and alarm levels, and combined with multi-terminal adapted alarm templates, it can provide alarm services to different terminals more accurately; the standardization of card templates ensures the standardization and convenience of alarm messages, making them easy to manage and view.

[0066] The collaboration process for each module is as follows:

[0067] The lightweight rule engine module matches the corresponding alarm template ID (such as `b9449641-4cd8-4883-a1e6-a73c07afb952.schema`) from the rule base based on the exception code (exceptionCode) and alarm level (alertLevel) in the exception information, and passes the template ID and exception information data transmission object (ExceptionMessageDTO) to the dynamic template rendering module. The rule engine stores the mapping relationship between exception code (exceptionCode) and alarm level (alertLevel) through a hash table to achieve rule matching with O(1) time complexity. When an alarm event occurs, the engine quickly locates the corresponding alarm template ID from the rule base based on the exception code and alarm level in ExceptionMessageDTO, and passes the template ID and exception information to the dynamic template rendering module. The rule configuration module allows users to dynamically bind a set of rules of exception code, alarm level and template ID through a visual interface or configuration file. After changes, the rules are synchronized to the engine in real time, improving the flexibility of the rules.

[0068] The dynamic template rendering module loads the corresponding template based on the template ID and uses the Freemarker engine to inject the attributes (sourceSystem, serviceName, etc.) and custom parameters (customParam) from the ExceptionMessageDTO into the template, generating multi-terminal alarm messages adapted to PCs, apps, and mini-programs. It employs the Freemarker engine to build a dynamic alarm template system, achieving parameterized template rendering based on the attributes (sourceSystem, exceptionCode, environment identifier, etc.) and custom parameters (customParam) in the exception information data transmission object (ExceptionMessageDTO). By designing dedicated templates for different terminals such as PCs, mobile apps, and mini-programs, and dynamically adjusting the display format (such as fonts, layout, and interactive components) according to the differences in screen size and interaction logic of each terminal, it solves the problem of poor multi-platform adaptability of traditional systems.

[0069] The alarm message push module receives rendered alarm messages and, combined with the third-party platform configuration corresponding to the template ID (such as DingTalk group session ID), calls the API to send standardized alarm messages. The alarm message push module achieves standardized output through a unified card template ID (such as DingTalk, WeChat Work, and other third-party platform APIs); the message format can be quickly adjusted by modifying the template table. It differentiates between development (dev), testing (test), and production (prod) deployment environments based on the environment identifier (env), and supports configuring differentiated push strategies according to the environment. For example: production environment (prod): pushes to the operations and maintenance group in real time to trigger emergency response; testing environment (test): pushes to the test channel with reduced notification priority; local environment (local): only logs are recorded, blocking notification interference.

[0070] The rule configuration module provides an interface or configuration file for users to define the binding relationship between exception codes and template IDs. After a rule is changed, it is synchronized to the rule engine module in real time to ensure that the matching logic is dynamically updated.

[0071] Based on the above technical solution, the attributes of the exception information data transmission object ExceptionMessageDTO include:

[0072] SourceSystem identifies the original system name that generated the alarm information;

[0073] Service Name: Identifies the name of the backend service that triggered the alert;

[0074] The exception code (exceptionCode) is a unique identifier for the exception type.

[0075] The exceptionCode is used to clearly identify the type of exception and plays a crucial role in the entire alarm system. It is an important basis for the lightweight rule engine to perform rule matching, and different exceptionCodes correspond to different alarm rules and processing procedures. For example, when the exceptionCode is "1001", it may indicate that the product inventory is insufficient. The system will match the corresponding alarm template based on this exception code and send an alarm message containing information about insufficient product inventory to the operations and maintenance personnel.

[0076] Based on the above technical solution, the properties of the exception information data transmission object ExceptionMessageDTO also include:

[0077] The business module (businessModule) identifies the module name that performs a specific business function in the system.

[0078] The trace identifier TraceId uniquely identifies a request that is passed between multiple services;

[0079] Error codes (ErrCode) are returned by the system when an exception occurs. Different ErrCodes represent different types of errors.

[0080] The Message is used to describe detailed information about the abnormal situation.

[0081] Each business module has its own independent business logic and data processing flow, and is responsible for completing a specific business function in the system. For example, product management, store management, and purchase order management all belong to different business modules, each completing its corresponding specific business. Business modules can help operations and maintenance personnel quickly locate the specific business area where an anomaly occurs. When an anomaly occurs in a business module, the corresponding alarm information will carry the module name, so operations and maintenance personnel can quickly know which business link has a problem.

[0082] When a request is passed between multiple services, the TraceId acts like a unique "ID card" throughout the entire process. It allows developers and operations personnel to trace the processing path of a request within a complex system architecture, quickly pinpointing which service node or processing stage is causing the problem, facilitating troubleshooting and performance analysis. For example, when a user places an order on an e-commerce app, this operation may involve multiple services such as order services, inventory services, and payment services. The TraceId will follow the request as it flows between these services, recording the entire process.

[0083] During system operation, if an abnormal situation occurs, the system will return the corresponding ErrCode. ErrCode is an error identifier represented by a number or letter code, which represents different types of errors. Developers and operations personnel can quickly identify the error type based on the ErrCode and then take targeted measures to handle it, thereby improving the efficiency of problem solving.

[0084] Compared to ErrCode, Message is more intuitive and specific, typically including the cause and location of the error, as well as possible solutions. For example, a message like "Database connection failed because the server address is misconfigured. Please check the configuration file" helps operations personnel gain a deeper understanding of the problem and quickly develop a solution.

[0085] Based on the above technical solution, the properties of the exception information data transmission object ExceptionMessageDTO also include:

[0086] The environment identifier env is used to identify the operating environment to which the current alarm information belongs.

[0087] The core function of the environment identifier env is to distinguish deployment environments at different stages, ensuring that alarm information can be processed according to environment differences. The difference processing refers to selecting different push channels or templates based on the env value.

[0088] For example, the possible values ​​and meanings of env are as follows:

[0089]

[0090] Example of differentiated processing: production environment (prod) alarms are pushed to the DingTalk operations and maintenance group, and test environment (test) alarms are pushed to the Slack test channel.

[0091] Environment-specific template example: Different alarm templates are used for different environments. For example, the template for a production environment should include emergency contact information.

[0092] Example of rule filtering and priority adjustment: In non-production environments, alarm levels can be automatically reduced (e.g., P1 level can be reduced to P3, where P1 level alarms are the highest priority alarms, and Priority 1Alert indicates a serious anomaly that needs to be handled immediately) to avoid false alarms.

[0093] Example of log and monitoring isolation: Logs are written to different storage systems based on the environment (env). For example, development environment logs are stored in local files, while production environment logs are stored in Elasticsearch. Monitoring data can also be tagged. For instance, in monitoring tools like Prometheus (an open-source system monitoring and alerting toolkit), env tags can be added to metrics to facilitate analysis of system status by environment.

[0094] Based on the above technical solution, the environment identifier env defaults to local.

[0095] This default value is a special value for the environment identifier (env), specifically referring to the local debugging environment running on the developer's personal computer. Its core function is to distinguish between the team-shared development environment (dev) and the personal local environment, enabling more granular alert control and log management. The differences between the local environment and the dev environment are as follows:

[0096]

[0097]

[0098] This application scenario is typically for local development and debugging. When developers are writing new features or fixing bugs, they start the service locally through an IDE (such as IntelliJ IDEA). In this case, the environment variable is automatically set to local, and it has the following characteristics:

[0099] In the local environment, the system automatically blocks non-critical alarms to avoid frequent pushes that may disturb developers. Developers may frequently trigger exceptions when debugging locally. If alarms are pushed according to the dev environment, the team communication tools will be overwhelmed with invalid information.

[0100] The local environment uses lightweight simulation services (such as H2 in-memory database and Mock third-party interfaces) to isolate it from the real services in the dev environment; in the local environment, problems can be quickly located through detailed logs (such as logLevel=DEBUG) without relying on external alarm systems;

[0101] Use lightweight components (such as embedded databases) in the local environment to reduce reliance on and usage of shared team resources (such as Dev databases).

[0102] To improve compatibility, when multiple environment configurations exist simultaneously, local takes precedence over dev, ensuring that local configurations override shared team configurations. In logs and monitoring data, env=local is explicitly marked to easily distinguish between local issues and team environment issues.

[0103] Based on the above technical solution, the following constraints are set in the rule configuration of the lightweight rule engine design:

[0104] When creating a new service, the service name must match the spring.application.name in the configuration file. Then bind the template and configure the rules.

[0105] This embodiment ensures strong consistency between services and alerting rules through `spring.application.name`, guaranteeing the accuracy and stability of the alerting system from an overall architectural perspective. By ensuring that the service name matches the `spring.application.name` in the Spring Boot configuration file, it ensures accurate binding of alerting rules to backend services, preventing alert failures due to configuration errors. Combined with `TraceId` (request tracing identifier), it enables cross-service request chain tracing, assisting in quickly locating abnormal nodes.

[0106] Based on the above technical solution, the lightweight rule engine stores the mapping relationship between exception codes (exceptionCode) and alert levels (alertLevel) through a hash table, achieving rule matching with O(1) time complexity. O(1) time complexity (constant time complexity) means that the execution time of the algorithm is a constant, independent of the size n of the input data. No matter how large the amount of input data is, the execution time of the algorithm (or the number of basic operations) is fixed.

[0107] Based on the above technical solution, the system collects alarm data from multiple terminals, including PC, mobile APP and mini program;

[0108] During the operation of business modules on each end, once an exception occurs, corresponding exception information will be generated and encapsulated in an ExceptionMessageDTO object.

[0109] The encapsulated ExceptionMessageDTO object is sent from each end to the alarm system's collection module via the data transmission channel.

[0110] For example, the system can collect multi-terminal alarm data through message queues, HTTP interfaces, or RPC frameworks, encapsulate it into ExceptionMessageDTO, store it in a distributed search engine (such as Elasticsearch), and build an index based on timestamps and exception types to support fast retrieval and analysis. After the lightweight rule engine starts, it obtains the latest alarm data in real time. If a match is successful, it triggers template rendering and message push; if a match fails, it records logs or re-verifies rules according to preset strategies.

[0111] Based on the above technical solution, the data transmission channel is a method and path for transmitting data between different components or systems, pre-planned and configured during system architecture construction. The data transmission channel pre-planned and configured in the alarm system can be any one of the following:

[0112] The message queue is where the ExceptionMessageDTO objects generated by each end are sent, and the alarm system's collection module retrieves data from the message queue.

[0113] HTTP / HTTPS protocol interface, each end calls the interface developed based on HTTP or HTTPS protocol, and sends the ExceptionMessageDTO object in JSON or XML format to the collection module of the alarm system;

[0114] The RPC (Remote Procedure Call) framework allows each endpoint to send ExceptionMessageDTO objects to the alarm system's collection module in a manner similar to calling a local method.

[0115] Based on the above technical solution, the collected alarm data is first stored in a distributed search engine, such as Elasticsearch, to provide persistent storage for the alarm data, facilitating subsequent querying and analysis.

[0116] The system builds an index based on the timestamp and anomaly type of the data to quickly locate and retrieve specific alarm data.

[0117] Based on the above technical solution, after the lightweight rule engine starts, it obtains the latest stored alarm data and compares the exception code and alarm level in the alarm data according to the pre-established matching rules of exception code and alarm level.

[0118] If the match is successful, the corresponding alarm handling process will be triggered;

[0119] If a match fails, further processing is performed according to the preset strategy, such as logging or re-checking the rules.

[0120] Each template supports binding of two types of set rules: exception code (exceptionCode) and alert level (alertLevel). The rule engine uses an efficient algorithm to quickly traverse the matching rule library and find the rule that matches the current alert data.

[0121] Based on the above technical solution, when a rule is successfully matched, the system determines the corresponding alarm template according to the matched rule, uses the Freemarker engine for template rendering, and obtains the attributes and custom parameter customParam from the ExceptionMessageDTO object as template rendering parameters.

[0122] Based on these parameters and the syntax rules of the alarm template, the Freemarker engine dynamically generates alarm messages that meet the display requirements of different terminals. For PCs, it may generate detailed table-style alarm information, displaying more details of the anomaly; for apps and mini-programs, it may generate concise pop-up alarms, highlighting key information.

[0123] Based on the above technical solutions, the system sends alarm messages through the API of a third-party open platform and can switch flexibly through configuration;

[0124] The third-party open platform can be any one of the following: DingTalk, WeChat Work, or Lark.

[0125] Taking DingTalk as an example, the system uses a unified card template ID (such as b9449641-4cd8-4883-a1e6-a73c07afb952.schema). Based on this template ID, it retrieves relevant configuration information from the corresponding template table, formats the alarm message to conform to the DingTalk message display format, and then calls the DingTalk Open Platform API to send the formatted alarm message to the specified DingTalk group or individual.

[0126] After receiving an alarm message, maintenance personnel handle the issue, and the results are fed back to the alarm system. The system records the handling results, including the handling time, personnel involved, and handling method. Simultaneously, the system analyzes the handling results and historical alarm data to optimize the matching rules of the rule engine and adjust template parameter settings to improve alarm accuracy and processing efficiency. If errors occur during data processing, such as data transmission failures or template rendering errors, the system records error logs and takes appropriate action based on the error type, such as retrying or notifying the administrator, to ensure system stability and reliability.

[0127] The contents not described in detail in this specification are existing technologies known to those skilled in the art.

[0128] The above description is only a preferred embodiment of the present invention. The scope of protection of the present invention is not limited to the above embodiments. Any equivalent modifications or changes made by those skilled in the art based on the content disclosed in the present invention should be included in the scope of protection set forth in the claims.

Claims

1. A lightweight alarm system based on multi-platform dynamic template rendering, characterized in that, include: The dynamic template rendering module uses the Freemarker engine to implement dynamic alarm templates that are adapted to multiple platforms. It utilizes the template parameterized rendering function of the Freemarker engine to obtain attributes and custom parameters customParam from the exception information data transmission object ExceptionMessageDTO as template rendering parameters. It loads the corresponding template according to the template ID, injects the template rendering parameters, and generates alarm messages that are adapted to multiple platforms. The lightweight rule engine module establishes matching rules for exception codes and alarm levels. When an alarm event occurs, it quickly matches the corresponding rule according to the matching rules, matches the corresponding alarm template ID from the rule library, and passes the template ID and exception information data transmission object ExceptionMessageDTO to the dynamic template rendering module. The rule configuration module supports binding of two types of rules for each template: exception code (exceptionCode) and alarm level (alertLevel). This allows users to define the binding relationship between exception codes and template IDs. Rule changes are synchronized to the rule engine module in real time. The alarm message push module sends alarm messages through the API of a third-party open platform, creates and uses a unified card template ID, and achieves standardized output and rapid configuration of alarm messages after modifying the corresponding template table.

2. The lightweight alarm system based on multi-platform dynamic template rendering as described in claim 1, characterized in that, The properties of the ExceptionMessageDTO object include: SourceSystem identifies the original system name that generated the alarm information; Service Name: Identifies the name of the backend service that triggered the alert; The exception code (exceptionCode) is a unique identifier for the exception type.

3. The lightweight alarm system based on multi-platform dynamic template rendering as described in claim 2, characterized in that, The properties of the ExceptionMessageDTO object also include: The business module (businessModule) identifies the module name that performs a specific business function in the system. The trace identifier TraceId uniquely identifies a request that is passed between multiple services; Error codes (ErrCode) are returned by the system when an exception occurs. Different ErrCodes represent different types of errors. The Message is used to describe detailed information about the abnormal situation.

4. The lightweight alarm system based on multi-platform dynamic template rendering as described in claim 2, characterized in that, The properties of the ExceptionMessageDTO object also include: The environment identifier env is used to identify the operating environment to which the current alarm information belongs; Different deployment environments are distinguished based on the environment identifier env, ensuring that alarm information can be processed according to environment differences.

5. The lightweight alarm system based on multi-platform dynamic template rendering as described in claim 4, characterized in that, The differentiated processing refers to selecting different push channels or templates based on the env value.

6. The lightweight alarm system based on multi-platform dynamic template rendering as described in claim 1, characterized in that, In the design of the lightweight rule engine, the following constraints are set in the rule configuration: When creating a new service, the service name must match the spring.application.name in the configuration file. Then bind the template and configure the rules.

7. The lightweight alarm system based on multi-platform dynamic template rendering as described in claim 1, characterized in that, The lightweight rule engine stores the mapping relationship between exception code and alarm level through a hash table, achieving rule matching with O(1) time complexity.

8. The lightweight alarm system based on multi-platform dynamic template rendering as described in claim 1, characterized in that, The system collects alarm data from multiple terminals, including PC, mobile APP, and mini-program. During the operation of business modules on each end, once an exception occurs, corresponding exception information will be generated and encapsulated in an ExceptionMessageDTO object. The encapsulated ExceptionMessageDTO object is sent from each end to the alarm system's collection module via the data transmission channel.

9. The lightweight alarm system based on multi-platform dynamic template rendering as described in claim 8, characterized in that, The collected alarm data is first stored in a distributed search engine; The system builds an index based on the timestamp and anomaly type of the data to quickly locate and retrieve specific alarm data.

10. The lightweight alarm system based on multi-platform dynamic template rendering as described in claim 9, characterized in that, After the lightweight rule engine starts, it retrieves the latest stored alarm data and compares the exception code and alarm level in the alarm data according to the pre-established matching rules for exception codes and alarm levels. If the match is successful, the corresponding alarm handling process will be triggered; If a match fails, further processing will be performed according to the preset strategy; The alarm handling process specifically includes: Once a rule is successfully matched, the system determines the corresponding alarm template based on the matched rule, uses the Freemarker engine for template rendering, and obtains the attributes and custom parameter customParam from the ExceptionMessageDTO object as template rendering parameters.

Images