Association alarm processing method and system for multi-source heterogeneous audit data of satellite gateway station

Abstract

The invention provides an association alarm processing method and system for multi-source heterogeneous audit data of a satellite gateway station, and the method comprises the steps: preloading all plug-ins through a plug-in framework, loading a preset rule through a rule engine, and verifying the validity; receiving audit event records pushed by each event source system by using a server, and forwarding the audit event records to the plug-in framework; determining an event source system from which the audit event is derived according to the field of the audit event record by utilizing a plug-in framework, and finding a corresponding plug-in; extracting a standardized field from the audit event record by using the plug-in, and transmitting the standardized field to the rule engine; the rule engine traverses the triggering condition expressions of all alarms in the preset rule, and judges whether the triggering condition expressions of the alarms are met or not; if yes, triggering an alarm; otherwise, not triggering. According to the method and the system, by introducing a plug-in architecture and a rule engine, automatic identification, standardized extraction and intelligent alarm of heterogeneous audit data of audit events in various formats are realized, and expandability, low coupling and high adaptability are realized.

Description

Technical Field

[0001] This invention relates to the field of satellite communication gateway station (gateway station) operation and maintenance monitoring technology, and in particular to a method and system for correlated alarm processing of multi-source heterogeneous audit data of satellite gateway stations. This method is applicable to aerospace ground systems, enabling unified analysis and intelligent alarm generation of audit events from different devices, protocols, and architectures. Background Technology

[0002] With the development of commercial spaceflight, satellite gateway stations need to connect to various satellite terminals, ground equipment, and third-party systems. The audit event records generated by these systems have significant "multi-source heterogeneous" characteristics:

[0003] 1. Multi-source nature: Audit data comes from different manufacturers, different equipment types, and different subsystems (such as communication, power supply, environment, control, etc.);

[0004] 2. Heterogeneity: Different systems use different data formats (such as JSON, XML, custom binary), field naming rules, timestamp formats, encoding methods, etc.

[0005] In information security and operations monitoring, simply collecting audit logs has limited significance; the key lies in triggering effective alerts through correlation analysis. However, traditional audit systems have the following problems:

[0006] 1. Severe hard coding: The parsing logic is directly embedded in the main program, and the core code needs to be modified every time a new device or log format is added;

[0007] 2. Limited processing methods: It lacks a flexible rule matching mechanism and cannot support dynamic configuration and custom condition judgments;

[0008] 3. High coupling: The log parsing, rule judgment, and alarm output modules are tightly coupled, resulting in poor scalability and high maintenance costs;

[0009] 4. High access cost: Each new device requires the development of a dedicated parser, and the source of the field must be explicitly specified in the rules, making it difficult to reuse;

[0010] 5. High false alarm rate and incomplete coverage: The lack of a unified abstract model makes it difficult to achieve cross-system correlation analysis.

[0011] Therefore, there is an urgent need for a general, scalable, and loosely coupled multi-source heterogeneous audit data association alarm processing mechanism, which is especially suitable for integrated gateway station scenarios. Summary of the Invention

[0012] The purpose of this invention is to provide a method and system for processing correlation alarms of multi-source heterogeneous audit data of satellite gateway stations, so as to achieve scalability, loose coupling and high adaptability.

[0013] To achieve the above objectives, the present invention provides a method for handling correlated alarms of multi-source heterogeneous audit data from satellite gateway stations, comprising:

[0014] Step S1: Provide a server with a plugin framework, rule engine, and alarm output adapter installed; preload all plugins using the plugin framework, load preset rules using the rule engine, and verify the validity of the plugins and preset rules.

[0015] Step S2: Utilize the server to receive audit event records pushed from various event source systems and forward them to the plugin framework for event collection;

[0016] Step S3: Using the plugin framework, determine the source system of the event based on the fields of the audit event record, and find the corresponding plugin;

[0017] Step S4: Using the corresponding plugin, extract standardized fields from the audit event records and pass them to the rule engine as a standardized intermediate structure;

[0018] Step S5: The rule engine iterates through all alarm trigger condition expressions in the preset rules and determines whether the standardized intermediate structure satisfies the alarm trigger condition expression; if it does, the alarm is triggered and the alarm information is sent to the alarm terminal; otherwise, it is not triggered.

[0019] Each plugin corresponds to an audit event record format for one or a group of devices in the event source system, used to extract standardized fields.

[0020] The plugin is hot-swappable.

[0021] In step S2, the server obtains audit event records pushed by each event source system based on the HTTP callback mechanism.

[0022] In step S3, the plugin framework automatically identifies the event source system from which the audit event record originates by matching key fields in the original audit event record and constructing a matching key, or by matching the header feature fields of the original audit event record using regular expressions.

[0023] The standardized fields include at least one of the following: alarm number, specific problem description, event type, perceived severity level, fault location information, extended text information, other additional information, and timestamp;

[0024] The preset rules include at least one of the following: rule name, event type, rule description, alarm output content template, alarm priority, automatic response field, impact field, and measure suggestion field. The automatic response field is used to call the automatic post-processing function to perform automatic recovery actions when an alarm is triggered.

[0025] After the alarm trigger condition expression is met, the following steps are also included: using the alarm number and fault location information of the standardized fields as the keys of the alarm information, it is determined whether there is a duplicate alarm. If there is no duplicate alarm, an alarm is triggered; otherwise, no alarm is triggered.

[0026] The preset rules include an alarm output content template; in step S5, the alarm information is sent to the alarm output adapter, the alarm output adapter renders the alarm information on the alarm output content template, and the rendering result is sent to the alarm terminal to send the alarm information to the alarm terminal; the rendering result serves as the main body of the alarm message, and after secondary encapsulation according to different output channels to obtain the alarm message, it is sent to the alarm terminal.

[0027] The method for handling the correlation alarm of multi-source heterogeneous audit data of satellite gateway stations further includes step S6: the alarm terminal returns the response result of the alarm message to the server.

[0028] On the other hand, the present invention provides a correlation alarm processing system for multi-source heterogeneous audit data of satellite gateway stations, including a processor and a memory. The memory stores a computer program. When the computer program is executed by the processor, it implements the correlation alarm processing method for multi-source heterogeneous audit data of satellite gateway stations described above.

[0029] The method and system for handling correlation alarms of multi-source heterogeneous audit data of satellite gateway stations of the present invention introduces a plug-in architecture and a rule engine to achieve automatic identification, standardized extraction and intelligent alarm of heterogeneous audit data of audit events of various formats. It achieves efficient, flexible and scalable processing, avoids hard coding, reduces access costs, and improves the flexibility and maintainability of the system. It is particularly suitable for large-scale, multi-vendor and high-reliability aerospace ground system operation and maintenance scenarios. Attached Figure Description

[0030] Figure 1 This is a flowchart of the alarm processing method for the correlation of multi-source heterogeneous audit data of satellite gateway stations according to the present invention.

[0031] Figure 2 This is an overall architecture diagram of the satellite gateway station multi-source heterogeneous audit data association alarm processing system of the present invention.

[0032] Figure 3 This is a flowchart of the plugin framework for the alarm processing system for the correlation of multi-source heterogeneous audit data of satellite gateway stations according to the present invention. Detailed Implementation

[0033] The present invention will be further described below with reference to specific embodiments. It should be understood that the following embodiments are for illustrative purposes only and are not intended to limit the scope of the invention.

[0034] like Figure 1 As shown, the method for handling correlation alarms of multi-source heterogeneous audit data of satellite gateway stations according to the present invention includes the following steps:

[0035] Step S1: Initialization phase: Provide a server with a plugin framework, rule engine and alarm output adapter installed; preload all plugins using the plugin framework, load preset rules using the rule engine, and verify the validity of the plugins and preset rules;

[0036] like Figure 2 As shown, the server is equipped with a plugin framework, a rules engine, and an alarm output adapter. The plugins include at least one of an antenna feeder data acquisition plugin, a ground-based base station data acquisition plugin, and a baseband data acquisition plugin. The plugin `plugin_tsk` is used for auditing event logging of the antenna feeder device, and the plugin `plugin_jd` is used for auditing event logging of the baseband device. The event source system includes at least one of the following devices: an antenna feeder device, a ground-based base station, and a baseband device.

[0037] like Figure 3 As shown, the plugin framework is configured as follows: Each plugin's unique identifier (Plugin ID) is registered with the server's runtime environment. The server's framework performs plugin legitimacy and compatibility checks, then collects plugin information, checks the event source systems supported by the plugin, and identifies extractable fields. Subsequently, an event stream is opened, and audit event records are collected to extract standardized fields. The server is preferably a Webhook server. Webhook is an HTTP callback mechanism that allows event sources to actively push data to the receiver, avoiding polling overhead.

[0038] Each plugin corresponds to an audit event log format for a device in the event source system (or an audit event log format for a group of highly similar devices in the event source system), used to extract standardized fields. The plugins follow a unified API function interface to complete the mapping of standardized fields and timestamp normalization, outputting an intermediate structure conforming to a unified model. For example, it maps `log_level` (the original field) in device logs to `PerceivedSeverity` (the standardized field), and converts timestamps from different time zones to UTC format.

[0039] In this embodiment, the definition of the plugin is as follows: type Plugin interface {Info() *sdk.InfoInit(config string) errorOpen(params string) (Instance, error) Fields() []sdk.FieldEntryExtract(req sdk.ExtractRequest, evtsdk.EventReader)error}type Instance interface {NextBatch(pStatePluginState, evtsEventWriters)(int, error)}.

[0040] Among them, `Info()` returns plugin information (ID, name, description); `Init()` initializes the plugin's internal state; `Open()` starts an event listening service (such as an HTTP server) to receive remote push notifications; `Fields()` defines a list of standardized fields that the plugin can extract; `Extract()` extracts field values ​​from the raw events and populates them into a standard structure; and `NextBatch()` reads audit event records in batches and writes them to the processing queue.

[0041] In other words, the plugin includes functions such as returning plugin information, initializing the plugin's internal state, receiving remote push notifications, extracting standardized fields, and batch reading and writing audit event records into the processing queue.

[0042] In this embodiment, the plugin supports hot-swapping. The hot-swapping implementation includes: monitoring changes to the plugin directory, for example, using inotify (Linux) or kqueue (macOS) to monitor changes to the / plugins directory; dynamically loading the .so file containing the plugin, registering plugin information, and then seamlessly switching plugins. After the switch is complete, the old plugin is uninstalled. Seamless switching means that after the new plugin is successfully loaded, the old version can continue to process unfinished events and supports canary routing (such as traffic splitting by device ID). Thus, the plugin framework becomes an independent dynamic library, and plugins can be adjusted according to requirements.

[0043] Step S2: Event Reception Phase: The server receives audit event records pushed from various event source systems and forwards them to the plugin framework for event collection.

[0044] In step S2, the server retrieves audit event records pushed by various event source systems based on an HTTP callback mechanism. Specifically, the server listens on a port, and the event source system pushes audit event records in JSON format to the port and path the server is listening on via HTTP POST. The server receives the audit event records as a request, encapsulates them into an `ExtractRequest` object, and forwards it to the plugin framework. This allows external event source systems to proactively push audit logs, ensuring real-time performance and low latency.

[0045] In this embodiment, the system starts a Webhook service to listen on port 5045 and the listening path is ` / platform-audit`.

[0046] Table 1 is a comparison table of the non-functional requirements and implementation methods of the associated alarm processing system. This table is used to illustrate the key non-functional requirements (such as real-time performance and high availability) considered during the system design, as well as the corresponding technology selection and implementation strategies, reflecting the overall architectural advantages of the associated alarm processing system. As shown in Table 1, the associated alarm processing system achieves real-time performance through Webhook proactive push, asynchronous pipeline processing, timestamp normalization, and rule pre-compilation, and achieves high availability through distributed deployment + load balancing, message queue persistence, plugin sandbox isolation, multi-channel output, and automatic health checks.

[0047] Table 1: Comparison of Non-functional Requirements and Implementation Methods for the Server of the Corresponding Alarm Processing System

[0048]

[0049] Step S3: Event parsing phase: Using the plugin framework, determine the event source system based on the fields of the audit event record, and find the corresponding plugin;

[0050] The plugin framework automatically identifies the source system from which an audit event record originates by matching key fields (such as metadata fields "device_type", "source_system", "format", "vendor_id", "device_id", etc.) in the original audit event record (i.e., the original event) and constructing a matching key (such as source_system + format), or by matching the header feature fields (such as XML namespaces, JSON fixed fields) of the original audit event record using regular expressions.

[0051] In this embodiment, the plugin framework identifies the key fields `source_system="SystemA"` and `format="json_v2"` of the original audit event record, thereby determining the event source system from which it originates.

[0052] In this embodiment, the event source system is used to locate the corresponding registered plugin, which is the file plugin_systema.so. In other embodiments, the event source system is used to search for the corresponding plugin in the registered plugin mapping table to determine the plugin's unique identifier (Plugin ID); if the corresponding plugin is found, step S4 is executed; otherwise, the unknown log processing flow is entered.

[0053] Step S4: Rule matching stage: Using the corresponding plugin, extract standardized fields from the audit event records and pass them to the rule engine as a standardized intermediate structure;

[0054] In this embodiment, the standardized fields include: alarm number (i.e., the unique identifier of the alarm, AlarmIdentifier), specific problem description (i.e., SpecificProblem), event type (i.e., EventType), perceived severity level (i.e., PerceivedSeverity), fault location information (i.e., FaultLocation), extended text information (i.e., AdditionalText), other additional information (i.e., AdditionalInformation), and timestamp.

[0055] As mentioned above, each plugin corresponds to an audit event log format for a device in the event source system (or an audit event log format for a class of highly similar devices in the event source system), used to extract standardized fields as an intermediate structure. The plugin follows a unified API function interface to complete the mapping of standardized fields and output an intermediate structure conforming to a unified standardized field model. For example, it performs level mapping to convert the original field `log_level` in the device log to the perceived severity level (`PerceivedSeverity`), performs time normalization to convert timestamps from different time zones to UTC format, performs unified location naming to obtain `FaultLocation`, performs problem description cleaning to obtain the specific problem description (`SpecificProblem`), and performs additional information structuring to obtain other additional information (`AdditionalInformation`).

[0056] Event types can be communication, equipment, or environment; severity levels can be critical, major, minor, or warning; fault location information can be level 1; and other additional information can be module ID, thread number, etc.

[0057] Specifically, by calling the plugin's Extract() function to perform plugin parsing, the plugin maps the raw fields of the audit event records to standardized fields. For example, it maps the timestamp in the raw fields to timestamps in the same time format (i.e., `timestamp` maps to ISO8601 unified time format), and `log_level` maps to `PerceivedSeverity`. Thus, the plugin obtains a standardized intermediate structure, which is then passed to the rules engine.

[0058] Step S5: Rule matching stage: The rule engine traverses all alarm trigger condition expressions in the preset rules and determines whether the standardized intermediate structure meets the alarm trigger condition expression; if it does, the alarm is triggered and the alarm information is sent to the alarm terminal; otherwise, it is not triggered.

[0059] In other words, the rule engine uses trigger condition expressions to judge the standardized intermediate structure and determine whether to issue an alert.

[0060] In this embodiment, the preset rule includes, in addition to the trigger condition expression (i.e., the Condition field), a rule name (i.e., the Rule Name field), an event type (i.e., the EventType field), a rule description (i.e., the Description field), an alarm output content template (i.e., the Output field), and an alarm priority (i.e., the Priority field). Optionally, the preset rule may also include an auto-heal field (i.e., the auto_heal field), an impact field (i.e., the impact field), and a measures suggestion field (i.e., the measures field). The auto-heal field is used to call an automatic post-processing function (such as the reboot_module(3) function or the reset_link() function) to perform an automatic recovery action when an alarm is triggered. The automatic recovery action is submitted to a background coroutine or task queue to avoid blocking the main process; and the execution result of the automatic recovery action is recorded in the operation log. Each automatic recovery action needs to pass a permission check (e.g., whether automatic restart is allowed); dry-run mode is supported for testing.

[0061] When the automatic recovery logic corresponding to an event type is relatively simple and the event cause / problem is relatively singular, the `auto_heal` field will be preset for execution. For example, for cases of excessively high temperature or alarms indicating that the air conditioner / fan has stopped working, the corresponding response strategy is relatively simple (restarting the air conditioner / fan module), so the `auto_heal` field will be preset for these event types. If the event type or alarm type prevents automatic recovery or does not require automatic recovery, the corresponding preset rules do not need to set the `auto_heal` field.

[0062] The trigger condition expression (i.e., the Condition field) and alarm output content template (i.e., the Output field) in the preset rules are both referenced based on the names of standardized fields.

[0063] The default rule file could be, for example, `rules.json`. Alarm priorities could be, for example, emergency, alert, critical, error, warning, etc.

[0064] Example of a preset rule: {"Rule Name": "CriticalCommunicationFailure","Condition": "EventType == 'COMM_ALERT' &&PerceivedSeverity == 'Critical'","Description": "A critical communication link failure was detected","Priority": "critical","Output":"

Critical Alarm

[0065] In this embodiment, the types of alarm events include, but are not limited to: service quality anomalies, communication interruptions, equipment failures, and environmental limitations.

[0066] The conditional expressions use Sysdig-like filtering syntax, supporting Boolean operations, comparison operations, and regular expression matching. An example trigger conditional expression is: `python if event['EventType'] == 'COMM_ALERT' and event['PerceivedSeverity'] == 'Critical': trigger_alarm()`.

[0067] Alarm priorities include, for example, emergency, alert, critical, error, warning, etc.

[0068] The alarm output content template (i.e., the Output field) is a string template that supports variable interpolation and is used to generate a readable alarm message that is eventually sent to operations and maintenance personnel.

[0069] After the alarm trigger condition expression is met, the algorithm also includes: checking if there are duplicate alarms; if not, triggering an alarm; otherwise, not triggering an alarm. This implements the deduplication logic.

[0070] The system checks for duplicate alarms. If no duplicate alarms exist, an alarm is triggered; otherwise, no alarm is triggered. Specifically, it uses a cache to maintain historical alarm information (e.g., alarms from the last N hours). The alarm number (i.e., the unique identifier of the alarm, AlarmIdentifier) ​​and fault location information (i.e., FaultLocation) from a standardized field are used as the key for the alarm information. Duplicate alarms are determined by checking if an alarm with the same key already exists within a preset consistency period. If no duplicate alarm exists, an alarm is triggered and the cache is updated; otherwise, no new alarm is triggered. Thus, the same AlarmIdentifier + FaultLocation is considered the same alarm instance, avoiding duplicate notifications.

[0071] In step S5, the alarm information is sent to the alarm output adapter, the alarm output adapter renders the alarm information on the alarm output content template, and the rendering result is sent to the alarm terminal.

[0072] Since the alarm output content template (i.e., the Output field) is a string template that supports variable interpolation, it is implemented using Go's text / template or a custom interpolation engine. Therefore, the alarm output adapter replaces the names of the standardized fields referenced in the alarm output content template (i.e., ${field name}) with the standardized fields as alarm messages to render alarm information in the content template. This alarm information includes alarm number, alarm priority, fault location information, and explanation.

[0073] An example of an alarm output template is as follows:

${PerceivedSeverity}

[0074] The rendering result is: [Critical] 2025-04-05T06:23:10Z | Device EU-3 experienced COMM_ALERT: Upstream link timeout for 30s. The upstream link timeout exceeded 30 seconds.

[0075] Furthermore, the alarm output content template supports formatting functions, such as ${Timestamp:iso8601}, ${Timestamp:unix}, and ${Timestamp:relative}. Examples of formatting functions are: Timestamp:iso8601 → 2025-04-05T06:23:10Z; Timestamp:unix → 1743834190; Timestamp:relative → 3 minutes ago.

[0076] The rendered result serves as the main body of the alarm message. After secondary encapsulation according to different output channels, the alarm message is sent to the alarm terminal. Alarm terminals include email clients, IM tools, and monitoring dashboards. The alarm output adapter selects the channel to send the alarm message based on the type of alarm terminal. These channels include, for example, WeChat bots, email, SMS, and the Northbound Network Management System. The formats of each channel and the corresponding secondary encapsulated content are shown in Table 1. Secondary encapsulation operations include, for example, HTML escaping of special characters (applicable to email output); truncating excessively long fields to prevent overflow, etc.

[0077] Table 1: Alarm Message Channels and Content Formats

[0078] aisle Send content format WeChat for Business Markdown message, including title, time, device, issue, and solution. mail HTML emails with color coding, tables, and links. Short message Simplified text: [CRITICAL] EU-3: Upstream timeout Northbound system JSON over HTTP, passing structured fields

[0079] Step S6 (optional): The alarm terminal returns the response result of the alarm message to the server.

[0080] The response to the alarm message includes logs indicating whether the alarm processing was successful or not, which are recorded on the local server for later retrieval.

[0081] In addition, step S6 further includes: when the received response result is a fault recovery event (i.e., an event where PerceivedSeverity == "Cleared" is received), automatically clearing the key of the corresponding alarm information in the cache.

[0082] The multi-source heterogeneous audit data association alarm processing method of the present invention has the following functions:

[0083] 1. Normalization: The plugin extracts standardized fields (such as `Timestamp`, `Severity`) and converts them into standardized fields in a unified format; through the plugin design, only the corresponding plugin needs to be developed for new devices, without modifying the main program, thereby eliminating hard coding;

[0084] 2. Multi-Source Correlation: Each plugin outputs standardized fields, enabling all systems to provide a consistent intermediate structure input to the rule engine to form a unified model, thereby supporting cross-system correlation analysis. The "unified model" refers to all trigger condition expressions established based on the unified intermediate structure. Standardized fields (i.e., the unified intermediate structure) are used to abstract the common characteristics of multi-source heterogeneous audit events, including but not limited to: alarm number, perceived severity level, event type, fault location, timestamp, and problem description. This unified model acts as a contract between the plugins and the rule engine, ensuring that regardless of the device or protocol from which the original logs originate, they can ultimately be normalized into a comparable, correlateable, and analyzable unified format.

[0085] 3. Rule Engine: Supports complex conditional expressions (`if A and B then alert`); Based on the rule engine, dynamic condition judgment is implemented, and custom alarm levels and automatic recovery actions are supported to achieve flexible alarms;

[0086] 4. Deduplication Mechanism: This invention uses the alarm number AlarmIdentifier + fault location information FaultLocation as the key of the alarm information to determine whether there are duplicate alarms. If no duplicate alarms are found, an alarm is triggered, thus implementing a deduplication mechanism.

[0087] 5. Automatic recovery: The preset rules include an automatic reply field, which is used to call the automatic post-processing function to perform automatic recovery actions when an alarm is triggered.

[0088] 6. Alarm Output Content Template: The preset rules include an alarm output content template, which uses `${field}` to dynamically generate readable alarm content. Furthermore, alarms can be pushed via various protocols such as email, WeChat Work, SMS, and message queues, enabling diverse output.

[0089] 7. High scalability and maintainability: Plugins are deployed independently and are hot-swappable, facilitating system upgrades and fault isolation. New devices only require plugin development, without modifying the main logic. This invention, through a plug-in architecture, dynamic loading mechanism, and standard interface definitions, naturally supports hot-swapping, solving the pain point of traditional systems where "modifying code requires system downtime." It meets the operation and maintenance needs of multi-device, multi-protocol, and high real-time requirements in satellite communication systems and is suitable for integrated gateway station scenarios.

[0090] In summary, the method and system for handling correlation alarms of multi-source heterogeneous audit data of satellite gateway stations of the present invention, by introducing a plug-in architecture and a rule engine, realizes automatic identification, standardized extraction and intelligent alarm of heterogeneous audit data of audit events of various formats, achieves efficient, flexible and scalable processing, avoids hard coding, reduces access costs, and improves the flexibility and maintainability of the system. It is particularly suitable for large-scale, multi-vendor and high-reliability aerospace ground system operation and maintenance scenarios.

[0091] On the other hand, the present invention provides a correlation alarm processing system for multi-source heterogeneous audit data of satellite gateway stations, which includes a processor and a memory. The memory stores a computer program. When the computer program is executed by the processor, it implements the correlation alarm processing method for multi-source heterogeneous audit data of satellite gateway stations described above.

[0092] The processor uses Phytium's domestically produced processor, which supports kernel module customization, instruction set optimization, and Hardware Abstraction Layer (HAL) to improve system security and performance.

[0093] The above description is merely a preferred embodiment of the present invention and is not intended to limit the scope of the invention. Various variations can be made to the above embodiments of the present invention. All simple and equivalent changes and modifications made in accordance with the claims and description of this application fall within the protection scope of the claims of this patent. All aspects not described in detail in this invention are conventional technical content.

Claims

1. A method for handling correlated alarms based on multi-source heterogeneous audit data from satellite gateway stations, characterized in that, include: Step S1: Provide a server with the plugin framework, rule engine, and alarm output adapter installed; All plugins are preloaded using a plugin framework, preset rules are loaded using a rule engine, and the validity of the plugins and preset rules is verified. Step S2: Utilize the server to receive audit event records pushed from various event source systems and forward them to the plugin framework; Step S3: Using the plugin framework, determine the source system of the event based on the fields of the audit event record, and find the corresponding plugin; Step S4: Using the corresponding plugin, extract standardized fields from the audit event records and pass them to the rule engine as a standardized intermediate structure; Step S5: The rule engine traverses all alarm trigger condition expressions in the preset rules and determines whether the standardized intermediate structure satisfies the alarm trigger condition expression. If the conditions are met, an alarm is triggered and the alarm information is sent to the alarm terminal; otherwise, no alarm is triggered.

2. The method for handling correlated alarms of multi-source heterogeneous audit data of satellite gateway stations according to claim 1, characterized in that, Each plugin corresponds to an audit event record format for one or a group of devices in the event source system, used to extract standardized fields.

3. The method for handling correlation alarms of multi-source heterogeneous audit data of satellite gateway stations according to claim 1, characterized in that, The plugin is hot-swappable.

4. The method for handling correlation alarms of multi-source heterogeneous audit data of satellite gateway stations according to claim 1, characterized in that, In step S2, the server obtains audit event records pushed by each event source system based on the HTTP callback mechanism.

5. The method for handling correlation alarms of multi-source heterogeneous audit data of satellite gateway stations according to claim 1, characterized in that, In step S3, the plugin framework automatically identifies the event source system from which the audit event record originates by matching key fields in the original audit event record and constructing a matching key, or by matching the header feature fields of the original audit event record using regular expressions.

6. The method for handling correlated alarms of multi-source heterogeneous audit data of satellite gateway stations according to claim 1, characterized in that, The standardized fields include at least one of the following: alarm number, specific problem description, event type, perceived severity level, fault location information, extended text information, other additional information, and timestamp; The preset rules include at least one of the following: rule name, event type, rule description, alarm output content template, alarm priority, automatic response field, impact field, and measure suggestion field. The automatic response field is used to call the automatic post-processing function to perform automatic recovery actions when an alarm is triggered.

7. The method for handling correlated alarms of multi-source heterogeneous audit data of satellite gateway stations according to claim 1, characterized in that, After the alarm trigger condition expression is met, the following steps are also included: using the alarm number and fault location information of the standardized fields as the keys of the alarm information, it is determined whether there is a duplicate alarm. If there is no duplicate alarm, an alarm is triggered; otherwise, no alarm is triggered.

8. The method for handling correlated alarms of multi-source heterogeneous audit data of satellite gateway stations according to claim 1, characterized in that, The preset rules include an alarm output content template; in step S5, the alarm information is sent to the alarm output adapter, the alarm output adapter is used to render the alarm information on the alarm output content template, and the rendering result is sent to the alarm terminal to send the alarm information to the alarm terminal. The rendering result serves as the main body of the alarm message. After secondary encapsulation according to different output channels, the alarm message is sent to the alarm terminal.

9. The method for handling correlated alarms of multi-source heterogeneous audit data of satellite gateway stations according to claim 1, characterized in that, It also includes step S6: the alarm terminal returns the response result of the alarm message to the server.

10. A system for processing correlation alarms based on multi-source heterogeneous audit data from satellite gateway stations, characterized in that, It includes a processor and a memory, wherein the memory stores a computer program, and when the computer program is executed by the processor, it implements the method for handling the correlation alarm of multi-source heterogeneous audit data of satellite gateway stations as described in any one of claims 1-9.

Images