Method, system, device, medium and program product for automatic adaptation of multi-source heterogeneous alarms

Abstract

The application provides a multi-source heterogeneous alarm automatic adaptation method, system, device, medium and program product. The method comprises the following steps: receiving alarm requests from different alarm sources through a unified access portal, extracting path aliases from path information of the alarm requests, and querying corresponding target alarm source configuration information in a preset alarm source mapping relationship library; based on the target alarm source configuration information, adaptively matching and loading a corresponding parser from a parser resource pool, the parser supporting hot plug loading and unloading; using the parser to parse data content of the alarm request, and converting the parsing result into a unified standardized data format for a downstream processing module to execute alarm strategy processing. The application introduces an alarm source identification based on path aliases and a parser dynamic adaptive mechanism, realizes automatic identification and dynamic adaptation of multi-source alarm access, and significantly improves the expansibility, reliability and operation automation level of the system.

Description

Technical Field

[0001] This application relates to the field of computer network operation and maintenance management technology, and in particular to an automatic adaptation method, system, device, medium and program product for multi-source heterogeneous alarms. Background Technology

[0002] With the rapid development of enterprise informatization and intelligent operation and maintenance, operation and maintenance monitoring systems typically need to receive alarm information from multiple monitoring platforms or business subsystems. Different monitoring systems (such as Zabbix, Prometheus, Alibaba Cloud Monitoring, etc.) have significant differences in alarm data format, field naming, transmission protocols, and reporting mechanisms, forming a typical multi-source heterogeneous alarm environment.

[0003] To achieve unified access to multi-source alarms, existing technologies typically employ the following methods:

[0004] (1) Multi-endpoint access method: Set up a separate receiving interface for each alarm source. This method is simple to implement, but the code needs to be modified or the system needs to be redeployed every time a new alarm source is added, resulting in poor scalability;

[0005] (2) Single-endpoint content sniffing method: All alarm requests are received through a unified receiving endpoint, and the source of the alarm is determined based on the feature fields in the request body. This method relies on the stability of the upstream data format. When the upstream system is upgraded or the fields are adjusted, it is easy to cause identification failure, and the content sniffing parsing overhead is large;

[0006] (3) Gateway routing method: Different routing rules are configured using the API gateway to forward alarm requests from different sources to the corresponding processing modules. This solution requires additional gateway components, resulting in a complex system architecture and high configuration and maintenance costs.

[0007] In summary, existing alarm processing architectures are generally characterized by a decentralized and siloed structure. Different monitoring systems independently handle alarm reception and parsing, forming isolated processing chains and lacking unified access specifications and data standards. As the number of alarm sources increases or interfaces change, the system needs repeated modifications and deployments, leading to problems such as poor scalability, low reliability, and bloated architecture, making it difficult to meet the needs of flexible access and automatic adaptation in multi-source heterogeneous environments. Summary of the Invention

[0008] To address the shortcomings of existing technologies, this application provides an automatic adaptation method, system, device, medium, and program product for multi-source heterogeneous alarms, which at least solves the problems of poor scalability, low reliability, and insufficient adaptability of alarm access architecture in existing technologies, so as to achieve unified access and automatic adaptation of multi-source heterogeneous alarms.

[0009] To achieve the above objectives and other advantages, some embodiments of this application provide the following aspects:

[0010] Firstly, some embodiments of this application provide an automatic adaptation method for multi-source heterogeneous alarms, including:

[0011] Alarm requests from different alarm sources are received through a unified access point;

[0012] Extract the path alias from the path information of the alarm request, and query the target alarm source configuration information corresponding to the path alias in the preset alarm source mapping relationship library;

[0013] Based on the target alarm source configuration information, the corresponding parser is adaptively matched and loaded from the parser resource pool. The parser resource pool includes multiple parsers, and the parser supports hot-swappable loading and unloading.

[0014] The parser is used to parse the data content of the alarm request and convert the parsing result into alarm data in a unified and standardized data format. The alarm data is used by the downstream processing module to execute alarm policy processing.

[0015] Secondly, some embodiments of this application provide an automatic adaptation system for multi-source heterogeneous alarms, including:

[0016] The general alarm receiving module is used to receive alarm requests from different alarm sources and extract path aliases through a unified access point;

[0017] The alarm source management module is used to maintain an alarm source mapping relationship library to store the binding relationship between path aliases and alarm source configuration information, and to query the corresponding target alarm source configuration information based on the path aliases;

[0018] The parser dynamic scheduling module is used to adaptively match and load the corresponding parser from the parser resource pool according to the target alarm source configuration information. The parser resource pool includes multiple parsers, and the parsers support hot-swappable loading and unloading.

[0019] The alarm parsing module is used to parse the data content of the alarm request using the parser, and convert the parsing result into alarm data in a unified and standardized data format. The alarm data is used by the downstream processing module to execute alarm policy processing.

[0020] Thirdly, some embodiments of this application also provide an electronic device, the electronic device comprising:

[0021] One or more processors; and a memory storing computer program instructions that, when executed, cause the processors to perform an automatic adaptation method for multi-source heterogeneous alarms as described above.

[0022] Fourthly, some embodiments of this application also provide a computer-readable storage medium having a computer program and / or instructions stored thereon, wherein the computer program and / or instructions, when executed by a processor, implement the automatic adaptation method for multi-source heterogeneous alarms as described above.

[0023] Fifthly, some embodiments of this application also provide a computer program product, including a computer program and / or instructions, which, when executed by a processor, implement the automatic adaptation method for multi-source heterogeneous alarms as described above.

[0024] Compared with existing technologies, the solution provided in this application introduces an alarm source identification and parser dynamic self-adaptation mechanism based on path aliases. This allows alarm requests from different monitoring systems to be accessed through a unified entry point, and automatically identifies alarm sources based on path aliases. This eliminates the need for independent configuration or code modification for each alarm source, significantly improving the scalability and maintenance efficiency of the automatic alarm adaptation system. By adaptively matching and loading corresponding parsers through a parser resource pool, dynamic parsing of different types of alarm requests is achieved, avoiding the vulnerability of traditional content sniffing methods and improving overall reliability and flexibility. The parsed alarm data is converted into a unified and standardized data format, providing a consistent data foundation for subsequent policy matching, storage, and notification. This simplifies the system architecture, improves the overall automation level and processing efficiency of operation and maintenance, and is suitable for unified alarm access and processing in multi-monitoring system environments. Attached Figure Description

[0025] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other implementation methods can be obtained based on these drawings without creative effort.

[0026] Figure 1 This is one of the flowcharts illustrating an automatic adaptation method for multi-source heterogeneous alarms provided in an embodiment of this application;

[0027] Figure 2 This is a second flowchart illustrating an automatic adaptation method for multi-source heterogeneous alarms provided in an embodiment of this application.

[0028] Figure 3 This is a schematic diagram of the multi-source heterogeneous alarm data flow provided in an embodiment of the present invention;

[0029] Figure 4 This is a schematic diagram of the logical structure of an automatic adaptation system for multi-source heterogeneous alarms provided in an embodiment of this application;

[0030] Figure 5 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

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

[0032] First Embodiment

[0033] The first embodiment of this application relates to an automatic adaptation method for multi-source heterogeneous alarms, referring to... Figure 1 , Figure 2 As shown, the method may include the following steps:

[0034] Step S1: Receive alarm requests from different alarm sources through a unified access point.

[0035] In this step, different alarm sources (such as the Zabbix monitoring system, Prometheus monitoring platform, Alibaba Cloud platform monitoring system, etc.) can send alarm information to the system's unified access point via HTTP POST requests. The unified access point can use a preset URL path format, such as: https: / / alert-system.com / api / v1 / receiver / {alias}, where {alias} is a pre-configured path alias used to uniquely identify the alarm source. For example, when the monitoring system is Zabbix, its corresponding path alias can be set to "idc_zabbix". The path from which this alarm source sends its request is: https: / / alert-system.com / api / v1 / receiver / idc_zabbix. After receiving this request, the system only extracts the alias portion {alias} from the path as the key identifier for subsequent alarm identification, without relying on the data content in the request body (Payload) for judgment. When adding a new alarm source, operations and maintenance personnel only need to configure an alias and bind the corresponding configuration information, without modifying the main system code or redeploying the service, thus achieving a flexible "configuration-and-use" access method. Through this mechanism, the alarm access method has changed from the traditional multi-endpoint or content sniffing to a path-driven unified access mode, significantly improving the system's scalability and maintainability.

[0036] Step S2: Extract the path alias from the path information of the alarm request, and query the target alarm source configuration information corresponding to the path alias in the preset alarm source mapping relationship database.

[0037] In this step, the system maintains an alarm source mapping database, which stores a set of data that maps path aliases to alarm source types and metadata information. This can be implemented using relational database tables, configuration files, or a cache structure, and is used to quickly query the target alarm source when an alarm request is received. When the system receives an alarm request, it first extracts the path alias from the requested URL. For example, when the request path is " / api / v1 / receiver / idc_zabbix", the system automatically extracts "idc_zabbix" as the path alias and performs a query in the mapping database to obtain the target alarm source configuration information bound to it. The target alarm source configuration information may include: alarm source type (e.g., Zabbix, Prometheus), country or region (e.g., East China, South China, overseas nodes), business line identifier (IDC data center monitoring, cloud resource alarms, etc.), authentication information or security verification parameters (including access token, signature key, or verification method), and data format identifier (e.g., JSON, XML, Form-Data, etc.).

[0038] Step S3: Based on the target alarm source configuration information, adaptively match and load the corresponding parser from the parser resource pool. The parser resource pool includes multiple parsers, and the parsers support hot-swappable loading and unloading.

[0039] In this step, the system sets up a parser resource pool, which integrates multiple parsers deployed in a pluggable manner. Each parser is used to process a specific type of alarm data, such as the Zabbix parser, Prometheus parser, and Aliyun parser. The parsers follow a unified interface specification (e.g., the parse(payload) method) to ensure pluggability and compatibility across different alarm sources.

[0040] After the system identifies the target alarm source configuration information in step S2, it obtains the alarm source type based on the configuration information and automatically matches and loads the corresponding parser instance. For example, when the alarm source type is "Zabbix", the system matches the Zabbix parser from the resource pool and instantiates the corresponding parser object.

[0041] The parser resource pool can be implemented using a factory pattern or a registry mechanism. It's used to automatically load or instantiate the corresponding parser at runtime based on the alarm source type. When a parser of a certain type is not yet loaded, the system can dynamically load and instantiate the module through a factory method or the registry. For example, the factory retrieves the parser class identifier from the configuration map based on the target alarm source type and loads and instantiates it at runtime. The configuration map stores the correspondence between alarm source types and parser identifiers. This configuration map can be maintained through database tables, configuration files, or a cache structure, allowing the parser factory to dynamically load and instantiate the corresponding parser at runtime based on the alarm source type. The registry mechanism refers to the parser registering its supported alarm source types and constructor information in the registry during loading. During the parsing scheduling phase, the constructor is directly retrieved from the registry based on the type and instantiated.

[0042] When the parser is not used for an extended period, it can be automatically unloaded or released by the system to reduce memory usage and improve system efficiency. This mechanism enables dynamic self-adaptation and on-demand loading of the parser, ensuring that the system can expand to include new alarm sources without modifying the main program or redeploying the service.

[0043] Step S4: Use a parser to parse the data content of the alarm request and convert the parsing result into alarm data in a unified and standardized data format. The alarm data is used by the downstream processing module to execute alarm policy processing.

[0044] In this step, after the parser is loaded, it performs parsing operations on the data content of the alarm request. Parsing rules may include steps such as field extraction, value type judgment, and structure mapping. After parsing, the system performs data type normalization (such as time format standardization, Boolean value conversion, and numerical unit unification) and format standardization on the mapped target fields. This ensures that alarm data from all different sources conforms to the data structure and format requirements uniformly defined within the system, generating a unified alarm entity that can be universally processed by downstream modules. In other words, the parsed alarm data will be output to downstream modules in a standardized format for operations such as policy matching, storage, notification, or work order generation.

[0045] like Figure 3 The diagram illustrates the flow of multi-source heterogeneous alarm data. Heterogeneous alarm data from different monitoring systems (e.g., Prometheus, Zabbix, and Alibaba Cloud alarm sources) are assigned unique path aliases (e.g., prometheus_alert, dc_zabbix, aliyun_alert) during the access configuration phase. Each alarm source includes the corresponding path alias in its URL path when sending an alarm request. Subsequently, based on the extracted path alias, the corresponding alarm source type information is queried in the alarm source mapping database, and the appropriate parser, such as PrometheusParser, ZabbixParser, or AliyunParser, is adaptively matched and loaded from the parser resource pool. Each parser, according to its predefined parsing rule set, parses and converts the received alarm requests, uniformly transforming the alarm data into an alarm data model (a unified alarm entity used to carry uniformly formatted data of alarms from different monitoring systems after parsing and conversion) that conforms to the system's internal standard data structure. The unified alarm entity is ultimately passed to the downstream unified processing flow for operations such as alarm policy matching, data storage, notification push, and work order generation. This diagram visually illustrates the entire process of multi-source heterogeneous alarms from access to standardized transformation, clearly demonstrating the technical solution proposed in this application that achieves unified access and standardized processing of multi-source alarms through path aliasing and dynamic self-adaptive resolution mechanisms. This solution effectively solves the problems of poor scalability, low compatibility, and complex maintenance existing in traditional alarm systems, laying a technical foundation for building a flexible, efficient, and maintainable intelligent operation and maintenance alarm system.

[0046] Compared with existing technologies, the solution provided in this application introduces an alarm source identification and parser dynamic self-adaptation mechanism based on path aliases. This allows alarm requests from different monitoring systems to be accessed through a unified entry point, and automatically identifies alarm sources based on path aliases. This eliminates the need for independent configuration or code modification for each alarm source, significantly improving the scalability and maintenance efficiency of the automatic alarm adaptation system. By adaptively matching and loading corresponding parsers through a parser resource pool, dynamic parsing of different types of alarm requests is achieved, avoiding the vulnerability of traditional content sniffing methods and improving overall reliability and flexibility. The parsed alarm data is converted into a unified and standardized data format, providing a consistent data foundation for subsequent policy matching, storage, and notification. This simplifies the system architecture, improves the overall automation level and processing efficiency of operation and maintenance, and is suitable for unified alarm access and processing in multi-monitoring system environments.

[0047] Second Embodiment

[0048] The second embodiment of this application relates to an automatic adaptation method for multi-source heterogeneous alarms. The second embodiment is an improvement upon the first embodiment, specifically in that the establishment and maintenance method of the alarm source mapping relationship database is optimized. Specifically, the establishment and maintenance of the alarm source mapping relationship database includes:

[0049] Create corresponding path aliases for each alarm source and configure the alarm source type and metadata information associated with the path alias to form corresponding configuration information. Store the configuration information in the alarm source mapping relationship library. When a new alarm source is added, perform a uniqueness check on the newly created path alias to ensure that each path alias is bound to only one alarm source.

[0050] In this embodiment, the system first establishes an alarm source mapping database to store the mapping relationship between the path aliases of each alarm source and the corresponding configuration information. Specifically, a corresponding path alias is created for each alarm source, and alarm source type information and metadata information associated with the path alias are configured. The metadata information may include the business line to which it belongs, the region identifier, the resolver binding information, authentication information, etc. The above configuration information is stored in the alarm source mapping database in the form of records so that when an alarm request is received subsequently, the corresponding alarm source type and its parsing rules can be quickly queried based on the path alias.

[0051] Furthermore, when the system needs to add a new alarm source, the operations and maintenance personnel only need to create a new path alias for that alarm source in the system and configure the corresponding configuration information. The system will automatically perform a uniqueness check before saving to ensure that each path alias is bound to only one alarm source, preventing alarm source identification conflicts or confusion in parsing results.

[0052] If the data structure of the new alarm source is compatible with an existing parser (e.g., belonging to the Zabbix or Prometheus series), the existing parser can be reused directly; if its data structure or protocol format is completely new, a new parser needs to be added, which is added and registered in the parser resource pool through a plug-in mechanism.

[0053] Through the above settings, dynamic configuration and consistent maintenance of alarm source mapping relationships are achieved, ensuring the stability and scalability of alarm source access in a multi-source heterogeneous environment. Thus, new alarm source registration and parsing adaptation can be completed without modifying the main system program, significantly improving the system's flexibility and operational efficiency.

[0054] Third Embodiment

[0055] The third embodiment of this application relates to an automatic adaptation method for multi-source heterogeneous alarms. The third embodiment is an improvement on the first embodiment, specifically in that a path resolution and exception handling mechanism is introduced, that is, step S2 can further include the following steps:

[0056] Step S201: Parse the URL path of the alarm request to obtain the path field information;

[0057] Step S202: Determine the corresponding path alias based on the path field information;

[0058] Step S203: Query the target alarm source configuration information corresponding to the path alias in the alarm source mapping relationship database;

[0059] Step S204: If the corresponding target alarm source configuration information is not found, the exception handling process is triggered to record the error log and return the exception prompt.

[0060] Specifically, when the system receives an HTTP request from the alarm source, the message carries a complete URL, such as: https: / / alert-system.com / api / v1 / receiver / idc_zabbix. Upon receiving this request at the network layer, the system first obtains the complete URL string. Therefore, it needs to perform URL parsing, breaking down the string into its syntax to distinguish the protocol (https), domain (alert-system.com), path ( / api / v1 / receiver / idc_zabbix), and parameters (such as ?token=abc123). Through this process, the system can accurately extract the URL's path field information: / api / v1 / receiver / idc_zabbix.

[0061] After obtaining the path field information, the identifier field at the end of the path segment is further extracted. The path end field can be extracted by string splitting, regular expression matching or path template matching, and the field is used as a path alias to identify a specific alarm source.

[0062] Query the target alarm source configuration information corresponding to the path alias in the alarm source mapping database. The target alarm source configuration information is used to indicate the type, data format, parser binding information and other metadata information of the alarm source, so that the corresponding parser can be loaded for data parsing in subsequent steps.

[0063] If no target alarm source configuration information corresponding to the path alias is found, an exception handling process is triggered, detailed error log information is recorded, and an exception prompt result is returned to inform the operations and maintenance personnel that the path alias has not been registered or is configured incorrectly. For example, the system can send this exception event to the alarm center or operations and maintenance notification channel (such as email or instant messaging) so that relevant operations and maintenance personnel can promptly supplement or correct the mapping relationship configuration.

[0064] Specifically, the system first records anomaly event logs. The logs include the complete URL of the current request, extracted path field information and path aliases, the request source IP, timestamps, and query conditions, for subsequent anomaly localization and analysis. The system can generate a unique event number for each anomaly and write the log information to the system log module or a dedicated anomaly database for cross-module tracing. After logging, the system returns a structured anomaly response message to the caller, such as an error code, message, path alias, and timestamp in JSON format, enabling upstream alarm sources to promptly detect anomalies and avoid sending duplicate requests.

[0065] In some implementations, the system can also perform self-healing or degradation processing, temporarily storing unidentified alarm requests in a backup queue and re-parsing them after the mapping relationship is updated. This degradation strategy can prevent a single anomaly from blocking the overall alarm processing flow, achieving fault tolerance and uninterrupted operation of the system.

[0066] Through the improvements in this embodiment, the system can accurately and quickly parse the path alias and locate the corresponding alarm source configuration when it receives an alarm request, ensuring that alarm requests from different sources can be correctly identified and processed. Simultaneously, through anomaly detection and logging mechanisms, identification failures or system interruptions caused by unregistered alarm sources can be effectively prevented, further enhancing the robustness and maintainability of the system.

[0067] Fourth embodiment

[0068] The fourth embodiment of this application relates to an automatic adaptation method for multi-source heterogeneous alarms. The fourth embodiment is an improvement on the first embodiment. Specifically, the improvement is that a dynamic loading and instance reuse mechanism for the parser is adopted, that is, step S3 can further include the following steps:

[0069] Step S301: Determine the type of the target parser based on the target alarm source configuration information, and identify whether the target parser is loaded in the parser resource pool;

[0070] Step S302: When the target resolver is not loaded in the resolver resource pool, dynamically load and instantiate the target resolver;

[0071] Step S303: When the target parser has been loaded in the parser resource pool, reuse the existing parser instance.

[0072] Specifically, the target alarm source configuration information includes an alarm source type identifier and parser binding information. The system can determine the appropriate parser type based on this information. For example, when the alarm source type is "Zabbix", the target parser is determined to be ZabbixParser; when the alarm source type is "Prometheus", the target parser is determined to be PrometheusParser. The parser type can be maintained in a parser mapping table through configuration mapping relationships. This mapping table indicates the binding relationship between different alarm source types and their corresponding parsers.

[0073] By querying the registry or cache index of the parser resource pool, it is determined whether a parser of this type has been loaded into memory or is in a reusable state. Specifically, the parser resource pool maintains two types of indexes: a parser registration index and a parser instance index. The parser registration index records the static binding relationship between each alarm source type and the parser, storing static information such as the parser's type identifier, classpath, version number, and loading entry point. The parser instance index records information about parser instances that have been loaded and are in a reusable state during system runtime, storing runtime information such as the parser type, its instance reference, status identifier, and last used time. To identify whether a target parser has been loaded, the parser instance index is first queried to determine if a record exists that completely matches its key value. If so, the runtime status (e.g., READY or ACTIVE), version consistency (version or hash matches the registration index), and health indicators (the most recent heartbeat or last_used time has not exceeded the expiration threshold) of the instance corresponding to that record are further verified. If all the above checks pass, the instance is considered "loaded" and can be reused directly. If the checks fail, or if they pass but the status is "VICTED, FAILED, or STALE", or the version signature does not match, the instance is considered "not loaded or not reusable".

[0074] When a target resolver is not loaded in the resolver resource pool, it is dynamically loaded and instantiated. The system reads the classpath or construction information of the target resolver from the resolver mapping table through the resolver factory module, loads the corresponding module using reflection or dynamic import, and instantiates it as a resolver object. During instantiation, the system can execute an initialization method to load the corresponding parsing rule set and standardized template, ensuring that the newly created resolver instance can be immediately used for alarm data parsing tasks. The dynamic loading method allows the system to introduce new resolvers on demand at runtime, achieving hot-swappable expansion of resolvers without restarting the main service.

[0075] When a target resolver has already been loaded into the resolver resource pool, the existing resolver instance is reused. That is, when the system receives a new alarm request, it first queries the resolver resource pool. If a resolver instance for the target type already exists, it directly calls that instance to perform the resolution operation, avoiding redundant loading and initialization overhead, thereby improving system performance and resource utilization efficiency. In some implementations, the resolver resource pool can employ a caching management strategy or a singleton pattern to periodically reclaim idle instances and manage their lifecycle, maintaining reasonable utilization of system memory resources.

[0076] This embodiment improves upon existing features by enabling dynamic loading and instance reuse of parsers. This allows the system to expand to include new parsers as needed during runtime without stopping or restarting the service. This mechanism effectively reduces the performance overhead of repeated parser loading and, through resource pool reuse and lifecycle management, enhances the concurrency performance and maintainability of multi-source heterogeneous alarm processing.

[0077] Fifth embodiment

[0078] The fifth embodiment of this application relates to an automatic adaptation method for multi-source heterogeneous alarms. The fifth embodiment is an improvement on the first embodiment. Specifically, the improvement is that it adopts a rule-driven parsing and standardized field mapping implementation method, that is, step S4 can further include the following steps:

[0079] Step S401: After being invoked, the parser is instantiated as the parser instance corresponding to the target alarm source;

[0080] Step S402: The parser instance parses the data content of the alarm request according to the predefined parsing rule set;

[0081] Step S403: Map the alarm fields in the parsing results to the target fields of the preset unified alarm field model, and perform data type normalization and format standardization processing on the target fields according to the data type and format specifications defined in the unified alarm field model to ensure that the converted alarm data conforms to the standardized format specified by the unified alarm field model. The unified alarm field model is used to define the general data structure of parsing results from different alarm sources.

[0082] Specifically, after the system receives an alarm request from the target alarm source, the parser dynamic scheduling module schedules a parser of the target type from the parser resource pool and instantiates it into a specific parser instance at runtime, such as a ZabbixParser, PrometheusParser, or AliyunParser instance. Each parser instance encapsulates a set of parsing rules that match its corresponding alarm source type to ensure that independent parsing processes can be executed for alarm requests from different sources.

[0083] The parser instance parses the data content of the alarm request according to a predefined set of parsing rules. The parsing rule set is a set of parsing logic predefined for the data structure and field semantics of a specific alarm source, such as field name mapping tables, regular expression matching rules, JSON path extraction expressions, or data format conversion templates.

[0084] The parsed results will be mapped to a unified alarm field model defined internally by the system. The unified alarm field model is a standardized data structure used to describe a common set of fields for parsing results from different alarm sources, enabling unified management and centralized processing of multi-source alarm data. This model provides a unified abstraction of the core attributes of alarms, including alarm resources, alarm levels, alarm hosts, alarm times, and alarm content. Specifically, the unified alarm field model may include, but is not limited to, the following fields: fields indicating the host or monitoring node of the alarm resource (e.g., `alert_resource`), fields indicating the severity of the alarm (e.g., `alert_level`), fields recording the time of alarm occurrence (e.g., `alert_time`), and fields storing detailed alarm information or descriptions (e.g., `alert_message`). Taking Zabbix alarms as an example, the parsing rule set can define the mapping relationships between fields as: host → `alert_resource`, severity → `alert_level`, timestamp → `alert_time`, description → `alert_message`, etc.

[0085] When performing the above mapping, the parser can simultaneously standardize the field data according to the specifications defined in the unified alarm field model. For example, it can uniformly convert the time format to the ISO 8601 standard format, map the text level of severity (such as "High" and "Disaster") to the enumeration level defined internally by the system (such as "critical", "major", and "minor"), and normalize the host identifier of alert_resource to ensure that all alarm data are consistent in terms of structure and semantics.

[0086] Through the improvements in this embodiment, different types of alarm data can be uniformly mapped to the same data structure, realizing automatic parsing and standardized conversion of different alarm source data formats, thereby achieving cross-platform and cross-system alarm data fusion and centralized processing. This mechanism effectively improves the identifiability and downstream compatibility of multi-source heterogeneous alarms, reduces data parsing coupling, and significantly improves the system's scalability and maintenance efficiency.

[0087] Sixth Embodiment

[0088] The sixth embodiment of this application relates to an automatic adaptation method for multi-source heterogeneous alarms. The sixth embodiment is an improvement on the first embodiment, specifically in that the parsing and execution mechanism of alarm requests is enhanced, that is, the automatic adaptation method further includes:

[0089] Each alarm request is executed in an independent task context. When an alarm request encounters an error during parsing, a degradation strategy is triggered, temporarily storing the alarm request data in a backup queue and sending an alarm notification to the administrator through a preset operation and maintenance notification channel to prevent the failure of parsing a single alarm request from blocking the normal processing of other alarm requests.

[0090] Specifically, each alarm request will be assigned an independent task context after it is received. The task context can be built based on a thread pool or an asynchronous task framework (such as an asynchronous message queue or an event-driven scheduling mechanism) to allocate an independent execution environment for each alarm request.

[0091] Based on this, the system can process alarm data from multiple different alarm sources simultaneously in an asynchronous and parallel manner, and perform real-time monitoring and isolation management of the running status of each task during execution. Through this task-level isolation mechanism, if an alarm request encounters an anomaly during parsing or standardization transformation, its abnormal state will be limited to the context of that task and will not propagate to the global scheduling thread or affect the normal execution of other alarm requests.

[0092] Furthermore, to prevent data loss or blockage due to parsing failures, the system introduces a queue-based degradation mechanism. When an anomaly is detected in the parsing phase of an alarm request (e.g., failure to match the corresponding parser, field structure not conforming to the expected format, or content parsing error), the system immediately triggers a degradation strategy, encapsulating the data content of the alarm request into a degradation task object and writing it to a separate backup queue for temporary storage. The backup queue can be implemented based on message middleware (such as Kafka, RabbitMQ, or Redis Stream) to ensure reliable persistence and subsequent traceability of abnormal data. Simultaneously, the system generates an abnormal alarm record and pushes it to administrators or operations personnel in real time through preset maintenance notification channels (e.g., email, WeChat, SMS, or alarm monitoring panel) to remind manual intervention for analysis and repair. After completing the degradation processing of the abnormal alarm, the system automatically releases the resources of the current task context and continues to process other alarm requests to be parsed, thereby achieving concurrent execution and fault isolation of different alarm tasks.

[0093] Through the improvements in this embodiment, the system has higher fault tolerance and operational stability when facing multi-source heterogeneous alarm data. It can achieve secure temporary storage of data and rapid alarm notification when anomalies occur, effectively avoiding the propagation of anomalies or system blockage, and ensuring high availability and stable operation in large-scale alarm scenarios.

[0094] The steps of the various methods described above are only for clarity. In practice, they can be combined into one step or some steps can be split into multiple steps. As long as they include the same logical relationship, they are all within the scope of protection of this application. Adding insignificant modifications or introducing insignificant designs to the algorithm or process, but without changing the core design of the algorithm and process, are also within the scope of protection of this application.

[0095] Seventh Embodiment

[0096] The seventh embodiment of this application relates to an automatic adaptation system for multi-source heterogeneous alarms, referring to... Figure 4 As shown, this system is used to achieve unified access, dynamic adaptation, and automated parsing of multi-source heterogeneous alarm data. The system mainly includes the following functional modules:

[0097] The general alarm receiving module is used to receive alarm requests from different alarm sources and extract path aliases through a unified access point.

[0098] The URL path format for alarm requests can include " / {api_base} / {version} / {alias}", where the last "{alias}" is the path alias field. This module is only responsible for receiving HTTP requests and parsing path information; it does not undertake alarm source identification or data parsing tasks, thus maintaining the lightweight and stability of the access layer.

[0099] The alarm source management module is used to maintain an alarm source mapping relationship library to store the binding relationship between path aliases and alarm source configuration information, and to query the corresponding target alarm source configuration information based on the path alias.

[0100] Alarm source configuration information can include metadata such as alarm source type, country, business line, and data format type. When a new alarm source is added, the system supports dynamically adding path aliases and configuration information through a graphical user interface (GUI) or API interface, and performs uniqueness verification during addition to ensure that each path alias is bound to only one alarm source, avoiding path conflicts and resolution confusion. During system runtime, this module can also query the corresponding target alarm source configuration information based on the received path alias to support subsequent modules in parser matching and scheduling.

[0101] The parser dynamic scheduling module is used to adaptively match and load the corresponding parser from the parser resource pool based on the target alarm source configuration information. The parser resource pool includes multiple parsers, and the parsers support hot-swapping loading and unloading.

[0102] The parser resource pool includes multiple parsers integrated in a plug-in manner, each corresponding to a specific alarm source type (such as Zabbix, Prometheus, or Alibaba Cloud). This module can dynamically load and instantiate parsers based on a factory pattern or registry mechanism. When the target parser is not loaded, a parser instance is dynamically loaded and registered; when the target parser already exists, the existing instance is directly reused, thereby improving system execution efficiency and resource utilization. Parsers support hot-swapping loading and unloading, enabling module expansion and updates without interrupting system services.

[0103] The alarm parsing module is used to parse the data content of alarm requests using a parser, and convert the parsing results into alarm data in a unified and standardized data format. The alarm data is used by downstream processing modules to execute alarm policy processing.

[0104] The alarm parsing module uses a parser to analyze the data content of alarm requests and maps the parsing results to a unified alarm field model defined within the system, thereby generating alarm data that conforms to a standardized data format. The unified alarm field model describes the standardized alarm data object, and its fields include, but are not limited to: alarm resource (alert_resource), alarm level (alert_level), alarm time (alert_time), and alarm description (alert_message). The design of the unified alarm field model ensures that heterogeneous alarm data from different sources is stored and processed with consistent field specifications. The generated standardized alarm data is then sent to downstream processing modules to perform operations such as policy matching, data storage, notification push, and work order generation.

[0105] Downstream processing modules may include an alarm processing engine, which performs operations such as policy matching, convergence filtering, data storage, notification push, and work order generation on the parsed and standardized unified alarm data. In specific implementation, the alarm processing engine matches the field information (such as alarm resource, alarm level, alarm time, and alarm content) in the standardized alarm data with a preset policy rule base to determine the corresponding response action.

[0106] When an alarm meets the triggering conditions, the alarm processing engine can call external interfaces or internal sub-modules to complete subsequent processing, such as writing the alarm result to the database, triggering message notifications, or generating automated work orders. Through this design, the system can achieve full-process automation and closed-loop management from multi-source alarm access, dynamic adaptation, automatic parsing to downstream response, significantly improving the real-time performance of alarm processing and the level of operation and maintenance automation.

[0107] Furthermore, this multi-source heterogeneous alarm automatic adaptation system can be implemented using a containerized deployment architecture. That is, each functional module of the system can be encapsulated as an independent container service unit, and uniformly scheduled and managed throughout its lifecycle through a container orchestration platform (such as Kubernetes, Docker Swarm, etc.). The modules interact with each other through lightweight communication interfaces (such as HTTP REST or message queues (MQ), thereby achieving module-level decoupling and independent expansion.

[0108] The content of the above-described automatic adaptation method embodiments for multi-source heterogeneous alarms is applicable to this system embodiment. The specific functions implemented in this system embodiment are the same as those in the above-described automatic adaptation method embodiments for multi-source heterogeneous alarms, and the beneficial effects achieved are also the same as those achieved in the above-described automatic adaptation method embodiments for multi-source heterogeneous alarms. To reduce repetition, further details are omitted here.

[0109] Furthermore, some embodiments of this application also provide an electronic device. The electronic device can be various forms of digital computer, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, etc. The electronic device can also be various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices.

[0110] The electronic device includes: one or more processors; and a memory storing computer program instructions, which, when executed, cause the processor to perform an automatic adaptation method for multi-source heterogeneous alarms as provided in any one or more of the above embodiments. Figure 5 An exemplary structural diagram of the electronic device is disclosed. The electronic device includes one or more processors 1101, a memory 1102, and interfaces for connecting the components, including high-speed interfaces and low-speed interfaces. The components are interconnected via different buses and can be mounted on a common motherboard or otherwise installed as needed. The processors can process instructions executed within the electronic device, including instructions stored in or on memory to display graphical information of a GUI on an external input / output device (such as a display device coupled to the interface). In some other embodiments, multiple processors and / or multiple buses can be used with multiple memories and multiple memory modules, if desired. Similarly, multiple electronic devices can be connected, each providing some of the necessary operations. The components, their connections and relationships, and their functions shown herein are merely examples and are not intended to limit the implementation of the present application described and / or claimed herein.

[0111] The electronic device may further include an input device 1103 and an output device 1104. The processor 1101, memory 1102, input device 1103, and output device 1104 may be connected via a bus or other means. Figure 5 Taking the example of a connection between China and Israel via a bus.

[0112] Input device 1103 can receive input numerical or character information, and generate key signal inputs related to user settings and function control of the electronic device, such as a touch screen, keypad, mouse, trackpad, touchpad, joystick, one or more mouse buttons, trackball, joystick, etc. Output device 1104 may include a display device, auxiliary lighting device (e.g., LED), and haptic feedback device (e.g., vibration motor). The display device may include, but is not limited to, a liquid crystal display, a light-emitting diode display, and a plasma display. In some embodiments, the display device may be a touch screen.

[0113] To provide interaction with the user, the electronic device can be a computer. The computer has: a display device (e.g., a cathode ray tube or LCD monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback); and input from the user can be received in any form (e.g., voice input or tactile input).

[0114] In this embodiment, a computer-readable medium stores a computer program / instruction, which, when executed by a processor, implements an automatic adaptation method for multi-source heterogeneous alarms provided in any one or more of the above embodiments. The computer-readable medium may be included in the electronic device described in the above embodiments; or it may exist independently and not assembled into the device. The computer-readable medium carries one or more computer-readable instructions.

[0115] The memory 1102 can serve as a non-transitory computer-readable storage medium, used to store non-transitory software programs, non-transitory computer-executable programs, and modules. The processor 1101 executes various functional applications and data processing of the server by running the non-transitory software programs, instructions, and modules stored in the memory 1102, thereby implementing the program instructions / modules corresponding to the methods provided in any one or more of the embodiments described above in this application.

[0116] The memory 1102 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the electronic device. Furthermore, the memory 1102 may include high-speed random access memory and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, the memory 1102 may optionally include memory remotely located relative to the processor 1101, and these remote memories can be connected to the electronic device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0117] It should be noted that the computer-readable medium described in this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. Computer-readable media can be, for example, but not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatuses, or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to, electrical connections having one or more wires, portable computer disks, hard disks, random access memory, read-only memory, erasable programmable read-only memory, optical fibers, portable compact disk read-only memory, optical storage devices, magnetic storage devices, or any suitable combination thereof. In this application, a computer-readable medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0118] Computer-readable media include permanent and non-permanent, removable and non-removable media, which can store information by any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory, static random access memory, dynamic random access memory, other types of random access memory, read-only memory, electrically erasable programmable read-only memory, flash memory or other memory technologies, read-only optical discs, digital versatile optical discs or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transfer medium that can be used to store information accessible by a computing device.

[0119] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including local area networks (LANs) or wide area networks (WANs), or it can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0120] In the above embodiments, all or part of the implementation can be achieved through software, hardware, firmware, or any combination thereof. For example, it can be implemented using an application-specific integrated circuit (ASIC), a general-purpose computer, or any other similar hardware device. In some embodiments, the software program of this application can be executed by a processor to implement the above steps or functions. Similarly, the software program of this application (including related data structures) can be stored in a computer-readable recording medium, such as RAM memory, magnetic or optical drives, floppy disks, and similar devices. In addition, some steps or functions of this application can be implemented in hardware, for example, as circuitry that cooperates with a processor to perform the various steps or functions.

[0121] The computer program product provided in this application includes one or more computer programs / instructions. When executed by a processor, these computer programs / instructions generate, in whole or in part, the processes or functions described in this application. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium may be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive), etc.

[0122] The flowcharts or block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of devices, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-specific system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0123] The scope of this application is defined by the appended claims rather than the foregoing description, and is therefore intended to encompass all variations falling within the meaning and scope of equivalents of the claims. No reference numerals in the claims should be construed as limiting the scope of the claims. Furthermore, it is clear that the word "comprising" does not exclude other units or steps, and the singular does not exclude the plural. Multiple units or devices recited in a device claim may also be implemented by a single unit or device in software or hardware. Terms such as "first," "second," etc., are used only for distinguishing descriptions and do not indicate any particular order, nor should they be construed as indicating or implying relative importance.

[0124] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily made 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. Therefore, the scope of protection of this application should be determined by the scope of the claims, and the above embodiments should be regarded as exemplary and non-limiting.

Claims

1. An automatic adaptation method for multi-source heterogeneous alarms, characterized in that, include: The system receives alarm requests from different alarm sources through a unified access point, which uses a preset URL path format and includes a path alias for uniquely identifying the alarm source. Extract the path alias from the path information of the alarm request, and query the target alarm source configuration information corresponding to the path alias in the preset alarm source mapping relationship library. The target alarm source configuration information includes alarm source type, region, service line identifier, authentication information and data format identifier. Based on the target alarm source configuration information, the corresponding parser is adaptively matched and loaded from the parser resource pool through the parser registration index and parser instance index maintained by the parser resource pool. The parser resource pool includes multiple parsers, and the parser supports hot-swappable loading and unloading. The parser registration index is used to record the static binding relationship between each alarm source type and the parser, and the parser instance index is used to record the parser instance information that has been loaded and is in a reusable state during system operation. The parser is used to parse the data content of the alarm request and convert the parsing result into alarm data in a unified and standardized data format. The alarm data is used by the downstream processing module to execute alarm policy processing. It also includes: creating corresponding path aliases for each alarm source, configuring the alarm source type and metadata information associated with the path alias to form corresponding configuration information, and storing the configuration information in the alarm source mapping relationship library. When a new alarm source is added, a uniqueness check is performed on the newly created path alias to ensure that each path alias is bound to only one alarm source, so that the main system code does not need to be modified or the service is redeployed, thus realizing a flexible access method that can be used immediately.

2. The automatic adaptation method for multi-source heterogeneous alarms according to claim 1, characterized in that, The step of extracting the path alias from the path information of the alarm request and querying the target alarm source configuration information corresponding to the path alias in the preset alarm source mapping relationship database includes: Parse the URL path of the alarm request to obtain the path field information; The corresponding path alias is determined based on the path field information; Query the target alarm source configuration information corresponding to the path alias in the alarm source mapping relationship database; If the corresponding target alarm source configuration information is not found, the exception handling process is triggered to record the error log and return an exception message.

3. The automatic adaptation method for multi-source heterogeneous alarms according to claim 1, characterized in that, The step of adaptively matching and loading the corresponding parser from the parser resource pool based on the target alarm source configuration information includes: The type of the target parser is determined based on the target alarm source configuration information, and it is identified whether the target parser is loaded in the parser resource pool. When the target parser is not loaded in the parser resource pool, the target parser is dynamically loaded and instantiated. When the target parser has already been loaded into the parser resource pool, the existing parser instance is reused.

4. The automatic adaptation method for multi-source heterogeneous alarms according to claim 1, characterized in that, The step of using the parser to parse the data content of the alarm request and converting the parsing result into alarm data in a unified standardized data format includes: The parser is instantiated as the parser instance corresponding to the target alarm source after being invoked; The parser instance parses the data content of the alarm request according to a predefined set of parsing rules; The alarm fields in the parsing results are mapped to the target fields of a preset unified alarm field model. According to the data types and format specifications defined in the unified alarm field model, the target fields are subjected to data type normalization and format standardization processing to ensure that the converted alarm data conforms to the standardized format specified by the unified alarm field model. The unified alarm field model is used to define a general data structure for parsing results from different alarm sources.

5. The automatic adaptation method for multi-source heterogeneous alarms according to claim 1, characterized in that, Also includes: Each alarm request is executed in an independent task context. When an error occurs during the parsing of an alarm request, a degradation strategy is triggered. The data content of the alarm request is temporarily stored in a backup queue, and an alarm notification message is sent to the administrator through a preset operation and maintenance notification channel to prevent the parsing failure of a single alarm request from blocking the normal processing of other alarm requests.

6. An automatic adaptation system for multi-source heterogeneous alarms, characterized in that, include: A general alarm receiving module is used to receive alarm requests from different alarm sources through a unified access point and extract path aliases. The unified access point adopts a preset URL path format, which includes path aliases used to uniquely identify alarm sources. The alarm source management module is used to maintain an alarm source mapping relationship database to store the binding relationship between path aliases and alarm source configuration information, and to query the corresponding target alarm source configuration information based on the path aliases. The target alarm source configuration information includes alarm source type, region, service line identifier, authentication information and data format identifier. The parser dynamic scheduling module is used to adaptively match and load the corresponding parser from the parser resource pool based on the target alarm source configuration information, through the parser registration index and parser instance index maintained by the parser resource pool. The parser resource pool includes multiple parsers, and the parsers support hot-swappable loading and unloading. The parser registration index is used to record the static binding relationship between each alarm source type and the parser, and the parser instance index is used to record the parser instance information that has been loaded and is in a reusable state during system operation. The alarm parsing module is used to parse the data content of the alarm request using the parser, and convert the parsing result into alarm data in a unified and standardized data format. The alarm data is used by the downstream processing module to execute alarm policy processing. It also includes: creating corresponding path aliases for each alarm source, configuring the alarm source type and metadata information associated with the path alias to form corresponding configuration information, and storing the configuration information in the alarm source mapping relationship library. When a new alarm source is added, a uniqueness check is performed on the newly created path alias to ensure that each path alias is bound to only one alarm source, so that the main system code does not need to be modified or the service is redeployed, thus realizing a flexible access method that can be used immediately.

7. An electronic device, characterized in that, The electronic device includes: One or more processors; and a memory storing computer program instructions, which, when executed, cause the processors to perform the automatic adaptation method for multi-source heterogeneous alarms as described in any one of claims 1-5.

8. A computer-readable storage medium having a computer program and / or instructions stored thereon, characterized in that, When the computer program and / or instructions are executed by the processor, they implement the automatic adaptation method for multi-source heterogeneous alarms as described in any one of claims 1-5.

9. A computer program product, comprising a computer program and / or instructions, characterized in that, When the computer program and / or instructions are executed by the processor, they implement the automatic adaptation method for multi-source heterogeneous alarms as described in any one of claims 1-5.

Images