Alarm event processing method and device in server, computer equipment and medium

Abstract

The invention relates to an alarm event processing method and device in a server, computer equipment and a medium, and the method comprises the steps: responding to an alarm system configuration operation, and transmitting configuration dynamic data corresponding to the alarm system configuration operation to a jLogtail collector; acquiring an original log of a server collected by a jLogtail collector, converting the collected original log into a standard format event, and pushing the standard format event to a message queue; calling an MCP context manager to consume the standard format event from the message queue, supplementing context information by taking a core identifier corresponding to the standard format event as a clue, and generating complete context information; and based on the complete context information, in combination with a dynamic threshold algorithm and a weighted diagnosis result of the diagnosis agent cluster, judging whether a preset alarm triggering condition is met. The whole scheme can realize efficient and accurate alarm event processing.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, apparatus, computer equipment, storage medium, and computer program product for handling alarm events in a server. Background Technology

[0002] In the field of server operation and maintenance, alarm systems are a crucial element in ensuring stable server operation and are of great significance for timely detection and resolution of potential problems. Traditional server alarm systems mainly employ various technical solutions: open-source monitoring and alarm tools such as PrometheusAlertmanager trigger alarms when data reaches pre-defined threshold rules; commercial alarm management platforms such as PagerDuty offer features such as alarm grouping, scheduling, and escalation strategies; log analysis systems such as ELKStack trigger alarms based on keyword matching in logs; and data collector technologies such as Logstash and Fluentd use a plug-in architecture to process log data.

[0003] However, the aforementioned traditional technologies all have significant limitations in practical applications. On the one hand, due to differences in format and source, multi-source data cannot be uniformly described and effectively transmitted, leading to difficulties in data integration and making it difficult to form comprehensive and accurate information for alarm judgment. On the other hand, alarm rules are mostly static threshold configurations, lacking dynamic adjustment capabilities. They cannot adjust alarm strategies in a timely manner according to dynamic changes in the actual operating status of the server, and configuration updates often require manual operation or even service restart, resulting in low response efficiency.

[0004] More importantly, when faced with complex server alarm events, traditional technologies rely mainly on human experience for root cause localization, which not only consumes a lot of manpower and time, but also has a low accuracy rate, making it difficult to achieve efficient and accurate alarm event handling. Summary of the Invention

[0005] Therefore, it is necessary to provide an efficient and accurate method, apparatus, computer device, computer-readable storage medium, and computer program product for handling alarm events in a server, addressing the aforementioned technical problems.

[0006] Firstly, this application provides a method for handling alarm events in a server. The method includes:

[0007] In response to alarm system configuration operations, the corresponding dynamic configuration data is sent to the jLogtail collector.

[0008] The jLogtail collector acquires the raw logs from the server, converts the collected raw logs into standard format events, and pushes them to the message queue.

[0009] The MCP (Multi-Context Processing) context manager is invoked to consume standard format events from the message queue, and context information is supplemented using the core identifier corresponding to the standard format event as a clue to generate complete context information;

[0010] Based on the complete context information, and combined with the weighted diagnostic results of the dynamic threshold algorithm and the diagnostic agent cluster, it is determined whether the preset alarm triggering conditions are met.

[0011] In one embodiment, the response alarm system configuration operation, which involves sending the dynamic configuration data corresponding to the alarm system configuration operation to the jLogtail collector, includes:

[0012] Displays a visual web configuration interface;

[0013] In response to alarm system configuration operations on the visual web configuration interface, dynamic configuration data is obtained;

[0014] The configuration data is persistently stored in a MySQL database;

[0015] The configuration dynamic data is pushed to the jLogtail collector by calling the HTTP interface (HyperText Transfer Protocol Interface).

[0016] In one embodiment, obtaining the raw logs from the jLogtail collector server, converting the collected raw logs into standard format events, and pushing them to a message queue includes:

[0017] Obtain the raw logs collected by the jLogtail collector from the server;

[0018] The original log is preprocessed to obtain the preprocessed log;

[0019] The preprocessed logs are converted into standard format events, including time ID, timestamp, service name, error type, and core context information, using the MCP adapter.

[0020] Push the standard format event to the Kafka message queue.

[0021] In one embodiment, the step of calling the MCP context manager to consume standard format events from the message queue, supplementing context information with the core identifier corresponding to the standard format event as a clue, and generating complete context information includes:

[0022] The MCP context manager is invoked to consume standard format events from the message queue and extract the service name, error type, and core fields from the standard format events as the base context.

[0023] Using the core identifiers in the standard format events as clues, query and aggregate related data from logs, metrics, link tracing, and knowledge base systems to obtain aggregated data;

[0024] The basic context is enriched based on the aggregated data to generate complete context information that includes the basic context, enhanced context, and lifecycle information.

[0025] The complete context information is initialized and its state is updated through a preset MCP lifecycle hook function.

[0026] In one embodiment, determining whether the preset alarm triggering condition is met based on the complete context information, combined with the weighted diagnostic results of the dynamic threshold algorithm and the diagnostic agent cluster, includes:

[0027] Obtain real-time transaction data and historical business data from the server, and calculate real-time transaction loss and maximum allowable loss based on the real-time transaction data, the historical business data, and the complete context information;

[0028] The business impact coefficient is calculated based on the real-time transaction loss and the maximum allowable loss, and the dynamic alarm threshold is calculated based on the business impact coefficient.

[0029] The error type field is extracted from the complete context information, and the target event type of the current event is determined by matching it with the built-in event type library and by context-assisted verification.

[0030] Based on the target event type, multiple agents in the diagnostic agent cluster are invoked to perform collaborative diagnosis, and the diagnostic results of multiple agents are obtained.

[0031] The diagnostic results of the multiple intelligent agents are weighted and aggregated to obtain a comprehensive confidence level;

[0032] Based on the dynamic alarm threshold and the overall confidence level, determine whether the preset alarm triggering conditions are met.

[0033] In one embodiment, after determining whether the preset alarm triggering condition is met based on the complete context information, combined with the weighted diagnostic results of the dynamic threshold algorithm and the diagnostic agent cluster, the method further includes:

[0034] If the preset alarm triggering conditions are met, structured alarm information is generated based on the complete context information.

[0035] Push the structured alarm information and continuously monitor the alarm resolution status;

[0036] If the alarm is not resolved within the timeout period, an operation and maintenance work order will be created on the authorized work order platform based on the structured alarm information and pushed to the platform.

[0037] In one embodiment, after pushing the structured alarm information and continuously monitoring the alarm status, the method further includes:

[0038] If the alarm has been processed, collect the alarm event ID and associated information of the historical alarm events;

[0039] Using alarm event IDs as nodes, an initial association graph of different alarm events is constructed based on preset association dimensions; the preset association dimensions include link association, indicator association, error type association, and service association.

[0040] Based on the error type, root cause and remedial measures data corresponding to each node in the initial association graph, calculate the comprehensive similarity between each node;

[0041] Based on the comprehensive similarity, weights are assigned to the associated edges in the initial association graph, and associated edges with weights lower than a preset weight threshold are removed to obtain an updated association graph.

[0042] Secondly, this application also provides an alarm event handling device for a server. The device includes:

[0043] The configuration module is used to respond to alarm system configuration operations and send the dynamic configuration data corresponding to the alarm system configuration operations to the jLogtail collector.

[0044] The log collection module is used to obtain the raw logs from the jLogtail collector server, convert the collected raw logs into standard format events, and push them to the message queue.

[0045] The context supplementation module is used to call the MCP context manager to consume standard format events from the message queue, supplement context information with the core identifier corresponding to the standard format event as a clue, and generate complete context information.

[0046] The alarm judgment module is used to determine whether the preset alarm triggering conditions are met based on the complete context information, combined with the weighted diagnostic results of the dynamic threshold algorithm and the diagnostic agent cluster.

[0047] Thirdly, this application also provides a computer device. The computer device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to perform the following steps:

[0048] In response to alarm system configuration operations, the corresponding dynamic configuration data is sent to the jLogtail collector.

[0049] The jLogtail collector acquires the raw logs from the server, converts the collected raw logs into standard format events, and pushes them to the message queue.

[0050] The MCP context manager is invoked to consume standard format events from the message queue, and context information is supplemented using the core identifier corresponding to the standard format event as a clue to generate complete context information.

[0051] Based on the complete context information, and combined with the weighted diagnostic results of the dynamic threshold algorithm and the diagnostic agent cluster, it is determined whether the preset alarm triggering conditions are met.

[0052] Fourthly, this application also provides a computer-readable storage medium. The computer-readable storage medium stores a computer program thereon, which, when executed by a processor, performs the following steps:

[0053] In response to alarm system configuration operations, the corresponding dynamic configuration data is sent to the jLogtail collector.

[0054] The jLogtail collector acquires the raw logs from the server, converts the collected raw logs into standard format events, and pushes them to the message queue.

[0055] The MCP context manager is invoked to consume standard format events from the message queue, and context information is supplemented using the core identifier corresponding to the standard format event as a clue to generate complete context information.

[0056] Based on the complete context information, and combined with the weighted diagnostic results of the dynamic threshold algorithm and the diagnostic agent cluster, it is determined whether the preset alarm triggering conditions are met.

[0057] Fifthly, this application also provides a computer program product. The computer program product includes a computer program that, when executed by a processor, performs the following steps:

[0058] In response to alarm system configuration operations, the corresponding dynamic configuration data is sent to the jLogtail collector.

[0059] The jLogtail collector acquires the raw logs from the server, converts the collected raw logs into standard format events, and pushes them to the message queue.

[0060] The MCP context manager is invoked to consume standard format events from the message queue, and context information is supplemented using the core identifier corresponding to the standard format event as a clue to generate complete context information.

[0061] Based on the complete context information, and combined with the weighted diagnostic results of the dynamic threshold algorithm and the diagnostic agent cluster, it is determined whether the preset alarm triggering conditions are met.

[0062] The alarm event handling method, device, computer equipment, storage medium, and computer program products in the aforementioned server respond to alarm system configuration operations by sending the dynamic configuration data corresponding to the alarm system configuration operations to the jLogtail collector; acquiring the raw logs collected by the jLogtail collector from the server, converting the collected raw logs into standard format events, and pushing them to a message queue; calling the MCP context manager to consume standard format events from the message queue, supplementing context information with the core identifier corresponding to the standard format events as clues, and generating complete context information; based on the complete context information, combined with the dynamic threshold algorithm and the weighted diagnostic results of the diagnostic agent cluster, determining whether the preset alarm triggering conditions are met. Throughout this process, the alarm system configuration is dynamically sent to the jLogtail collector, quickly adapting to diverse alarm needs and improving configuration efficiency; the conversion of raw logs to a standard format and the supplementation of complete context information ensures the integrity and accuracy of event data; the dynamic threshold algorithm can flexibly adjust alarm thresholds based on real-time data; and the diagnostic agent cluster can provide professional diagnosis through multi-dimensional intelligence analysis. The combined judgment of these two approaches balances flexibility and professionalism, thereby achieving efficient and accurate alarm event handling. Attached Figure Description

[0063] Figure 1 This is an application environment diagram of an alarm event handling method in a server in one embodiment;

[0064] Figure 2 This is a flowchart illustrating an alarm event handling method in a server according to one embodiment;

[0065] Figure 3 This is a flowchart illustrating an alarm event handling method in a server, as shown in another embodiment.

[0066] Figure 4 This is a schematic diagram of a sub-process of S800 in one embodiment;

[0067] Figure 5 This is a structural block diagram of an alarm event handling device in a server in one embodiment;

[0068] Figure 6 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0069] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0070] The alarm event handling method in the server provided in this application embodiment can be applied to, for example, Figure 1 In the application environment shown, terminal 102 communicates with server 104 via a network. A data storage system can store the data that server 104 needs to process. The data storage system can be integrated on server 104 or placed on the cloud or other network servers. Terminal 102 sends an alarm event processing start request to server 104. Server 104 responds to the alarm system configuration operation corresponding to the request, sending the dynamic configuration data corresponding to the alarm system configuration operation to the jLogtail collector; it obtains the raw logs collected by the jLogtail collector from the server, converts the collected raw logs into standard format events, and pushes them to the message queue; it calls the MCP context manager to consume standard format events from the message queue, supplementing context information with the core identifier corresponding to the standard format events as clues to generate complete context information; based on the complete context information, combined with the dynamic threshold algorithm and the weighted diagnostic results of the diagnostic intelligent agent cluster, it determines whether the preset alarm triggering conditions are met. Terminal 102 can be, but is not limited to, various personal computers, laptops, smartphones, tablets, IoT devices, and portable wearable devices. IoT devices can be smart speakers, smart TVs, smart air conditioners, smart vehicle devices, etc. Portable wearable devices can include smartwatches, smart bracelets, head-mounted devices, etc. Server 104 can be implemented using a standalone server or a server cluster consisting of multiple servers.

[0071] In one embodiment, such as Figure 2 As shown, a method for handling alarm events in a server is provided, which can be applied to... Figure 1 Taking server 104 as an example, the following steps are included:

[0072] S200: Responds to alarm system configuration operations and sends the corresponding dynamic configuration data to the jLogtail collector.

[0073] Here, server 104 can have a built-in OnCall system, which relies on the server's built-in Pipeline configuration management module to achieve dynamic distribution and updates of configurations without requiring a server service restart. Specifically, system administrators, operations and maintenance personnel, or developers interact with the server's built-in OnCall system via REST API to initiate alarm system configuration operations (including adjusting collection rules and setting data filtering conditions). These operation commands are transmitted through the OnCall system to the Pipeline configuration management module within the same server. As the core carrier of the configurable data processing pipeline, the Pipeline configuration management module generates corresponding dynamic configuration data through the server's internal interface and then distributes it to the jLogtail collectors within the server cluster according to preset interaction logic, thereby achieving dynamic configuration updates for the jLogtail collectors.

[0074] S400: Obtain the raw logs from the jLogtail collector server, convert the raw logs into standard format events, and push them to the message queue.

[0075] The jLogtail collector within the server cluster operates strictly according to the dynamic configuration issued by S200, accurately collecting raw logs from each node within the cluster. After collection, it transmits the raw log events to the server's built-in OnCall system via Webhook and HTTP protocols, ensuring secure and real-time transmission of the raw log data. Upon receiving the raw logs, the OnCall system forwards them to the server's built-in MCP adapter (belonging to the MCP intelligent layer), which handles the format standardization conversion. The MCP adapter performs conversion operations on unstructured and heterogeneous raw logs according to preset standard specifications, generating a unified MCP standard format event. This event consistently includes a unique event ID, a timestamp accurate to milliseconds, the service name, error type, and core context information (including associated data such as metricID, traceID, user ID, and order ID), completely eliminating data differences between logs from different sources and providing a standardized data carrier for subsequent unified processing. After format conversion, the MCP adapter pushes the standard format event to a message queue (e.g., a Kafka message queue) deployed on the server cluster via a message queue protocol (e.g., Kafka).

[0076] S600: Calls the MCP context manager to consume standard format events from the message queue, supplements context information with the core identifier corresponding to the standard format event as a clue, and generates complete context information.

[0077] As the core hub of the system, the MCP context manager connects the alarm rule engine and the diagnostic intelligence cluster, responsible for the extraction, enrichment, and transmission of context. Specifically, the MCP context manager adopts a stateless design and can scale horizontally with the server cluster to handle high-concurrency alarm events. It can interact with the OnCall system within the same server via the gRPC protocol, calling its built-in intelligent context enhancement engine to consume standard-format events from the message queue. Using the core identifiers corresponding to standard-format events (such as the service ID associated with the log, node identifier, etc.) as clues, the MCP context manager, on the one hand, retrieves historical cases, solutions, and context relationship data from the server's built-in MCP knowledge base through a query interface; on the other hand, it collaborates with the MCP intelligent layer through internal server interfaces to supplement context information such as service dependencies and runtime status associated with the event, ultimately completing the extraction, enrichment, and aggregation of context information to generate complete context information. Here, the MCP context manager solves the problem of incomplete information from a single standard-format event by supplementing multi-dimensional context information, providing comprehensive data support for subsequent alarm judgment and root cause analysis. Simultaneously, relying on the stateless design and horizontal scalability of the MCP context manager, it ensures the efficiency and stability of context processing in high-concurrency scenarios.

[0078] S800: Based on complete context information, combined with the weighted diagnostic results of the dynamic threshold algorithm and the diagnostic agent cluster, it determines whether the preset alarm triggering conditions are met.

[0079] Based on the complete context information generated by the S600, the alarm threshold is first optimized and adjusted in real time using a dynamic threshold algorithm combined with historical data from the MCP knowledge base, avoiding false alarms and missed alarms caused by fixed thresholds. Simultaneously, the MCP context manager pushes the complete context information to the server's built-in diagnostic agent cluster. This cluster includes agents from multiple professional domains, such as database experts, network experts, and application logic experts. Each agent interacts with the MCP context manager through a standardized interface, performs root cause analysis based on the context information, outputs its own diagnostic results, and then generates a comprehensive weighted diagnostic result through preset weighted rules. The server can also have a built-in WheelTimer scheduler, which uses Netty's HashedWheelTimer to achieve millisecond-level precision scheduling and is tightly coupled with the alarm rule engine to ensure real-time response during the judgment process. Finally, combining the results of the dynamic threshold algorithm and the weighted diagnostic results, the alarm rule engine within the server determines whether the preset alarm triggering conditions are met. Here, by adapting to changes in business operation status through dynamic threshold algorithms and leveraging the multi-domain collaborative diagnostic capabilities of the diagnostic intelligence cluster, the risk level of events can be accurately identified. Furthermore, millisecond-level scheduling can be used to ensure the rapid output of judgment results, providing a reliable basis for subsequent alarm notifications and processing.

[0080] The alarm event handling method in the aforementioned server responds to alarm system configuration operations by sending the dynamic configuration data corresponding to the alarm system configuration operations to the jLogtail collector; it acquires the raw logs collected by the jLogtail collector from the server, converts the collected raw logs into standard format events, and pushes them to the message queue; it calls the MCP context manager to consume standard format events from the message queue, supplements context information using the core identifiers corresponding to the standard format events as clues, and generates complete context information; based on the complete context information, combined with the dynamic threshold algorithm and the weighted diagnostic results of the diagnostic agent cluster, it determines whether the preset alarm triggering conditions are met. Throughout this process, the alarm system configuration is dynamically sent to the jLogtail collector, quickly adapting to diverse alarm needs and improving configuration efficiency; the raw logs are converted to a standard format and supplemented with complete context information, ensuring the integrity and accuracy of the event data; the dynamic threshold algorithm can flexibly adjust the alarm threshold based on real-time data; and the diagnostic agent cluster can provide professional diagnosis through multi-dimensional intelligence analysis. The combined judgment of these two methods balances flexibility and professionalism, thereby achieving efficient and accurate alarm event handling.

[0081] In one embodiment, such as Figure 3 As shown, in response to alarm system configuration operations, the corresponding dynamic configuration data is sent to the jLogtail collector, including:

[0082] S220: Displays a visual web configuration interface.

[0083] The web configuration interface can include components such as a drop-down list for the project, a rule name input box, a pipeline drop-down list, a trigger threshold input box, a default severity level selection button, a query condition (DSL) input box, and a data output target drop-down option, each to adapt to different configuration requirements. The configuration results are simultaneously displayed on the "Alarm Rule List" interface, supporting subsequent editing and deletion operations.

[0084] S240: Responds to alarm system configuration operations on the visual web configuration interface and obtains dynamic configuration data.

[0085] The OnCall system responds in real time to user interactions on the web configuration interface, transforming manually entered and selected configuration items into structured dynamic configuration data. Specifically, this includes: selecting the business project from the project dropdown menu, specifying the identifier in the rule name input box, selecting the collection pipeline and trigger type from the pipeline and rule type dropdown menus, entering the evaluation period and trigger threshold values, configuring the default severity level and rule status, setting the field extraction logic (such as extracting metricID and traceID) through the DSL input box, selecting the Kafka `logs` topic and cluster address as the data output target, and aggregating all configuration items into a unified structured dynamic configuration data after the OnCall system verifies the format validity.

[0086] S260: Persistently store configuration dynamic data to a MySQL database.

[0087] After receiving dynamic configuration data from the OnCall system, the server's built-in Pipeline configuration management module automatically performs persistent storage operations, writing the data to a MySQL database. During storage, the Pipeline module categorizes and archives the dynamic configuration data according to a preset data structure, forming an associated index with existing configuration data to ensure data traceability. It also supports querying, updating, and deleting configuration data, ensuring consistency between the data in the "Alarm Rule List" interface and the database data.

[0088] S280: Call the HTTP interface to push dynamic configuration data to the jLogtail collector.

[0089] After completing data persistence, the Pipeline configuration management module pushes the dynamic configuration data to the jLogtail collector in the server cluster via an HTTP interface, enabling hot updates of the configuration without restarting the jLogtail collector or related server services.

[0090] Furthermore, in specific application examples, the server can also perform automatic configuration, which includes the following steps:

[0091] Step 1: Automatic Data Collection: The MCP adapter captures metadata (such as service name and indicator type) and historical operation data of the business system, eliminating the need for manual data entry.

[0092] Step 2, Intelligent Configuration Generation: The server's built-in dynamic rule optimization engine automatically generates configuration items that match the interface form based on the collected data (such as rule type matching the service's historical template, and thresholds calculated based on data fluctuations).

[0093] Step 3, Configuration Takes Effect: After the server automatically verifies the legality of the dynamic configuration data, it synchronizes it to the "Alarm Rule List" and sends it to the jLogtail collector. Subsequently, the alarm effect based on the MCP context manager will automatically fine-tune the parameters.

[0094] In one embodiment, obtaining the raw logs from the jLogtail collector server, converting the collected raw logs into standard format events, and pushing them to a message queue includes:

[0095] Step 1: Obtain the raw logs from the server collected by the jLogtail collector.

[0096] Based on the dynamic configuration (including log collection rules and target scope) issued by S200, the system monitors the running status of business application systems on each node of the server cluster in real time, focusing on capturing error logs. Once a newly generated error log is detected, the system automatically completes the collection.

[0097] Step 2: Preprocess the original logs to obtain preprocessed logs.

[0098] Standardized preprocessing is performed on the collected raw logs. This preprocessing involves three main steps: filtering invalid logs (removing log data with incorrect formatting or no business relevance), extracting key fields (accurately extracting core identifier fields such as metricID and traceID), and standardizing the data format (adjusting heterogeneous logs output by different business modules to a unified basic format). The preprocessed logs generate well-structured preprocessed logs. Here, by preprocessing the raw logs to remove redundant and invalid data and standardize the basic log format, a data foundation is laid for subsequent MCP adaptation and conversion, preventing heterogeneous data from interfering with the standardization conversion process and improving subsequent processing efficiency.

[0099] Step 3: Convert the preprocessed logs into standard format events that include time ID, timestamp, service name, error type, and core context information using the MCP adapter.

[0100] The server's built-in MCP adapter (belonging to the MCP intelligent layer) receives preprocessed logs and performs format conversion to generate MCP standard format events. The converted standard format events contain fixed core information: a unique event ID (e.g., ALM-20250601-001), an event occurrence timestamp accurate to milliseconds, the name of the service (e.g., order-service), the error type (e.g., DB_TIMEOUT), and core context information (including associated data such as metricID, traceID, user ID, and order ID), ensuring that the structure of logs from different sources is completely consistent after conversion.

[0101] Step 4: Push the standard format event to the Kafka message queue.

[0102] After the MCP adapter conversion is complete, standard format events are pushed to the Kafka message queue deployed on the server cluster via the Kafka protocol. Specifically, a cluster architecture with 3 broker nodes can be used to achieve high-availability data storage and transmission. The push process utilizes the server's 10Gbps intranet communication to ensure efficient and low-latency data transmission. At the same time, the Kafka queue implements asynchronous data buffering to avoid overloading subsequent processing modules.

[0103] In one embodiment, the MCP context manager is invoked to consume standard format events from the message queue, and context information is supplemented using the core identifier corresponding to the standard format event as a clue to generate complete context information, including:

[0104] Step 1: Call the MCP context manager to consume standard format events from the message queue, and extract the service name, error type, and core fields from the standard format events as the base context.

[0105] The MCP context manager consumes standard-format events from the Kafka message queue through a standardized interface. It extracts basic context information according to the pre-defined specifications of the MCP protocol, including the service name (e.g., order-service), error type (e.g., DB_TIMEOUT), and core fields (metricID, traceID, timestamp, etc., defined by the MCP protocol). The extraction process follows a manually / automatically configured field list, and a dynamic rule optimization engine performs format validation (e.g., service name is a string, timestamp is a millisecond-level timestamp). Fields that do not conform to the specifications are directly marked as abnormal. If key fields such as the service name are missing, default values ​​are automatically filled, an abnormal status is marked, and a low-priority alarm is pushed, ensuring the context structure is complete and does not affect the core process.

[0106] Step 2: Using the core identifiers in the standard format event as clues, query and aggregate related data from logs, metrics, link tracing, and knowledge base systems to obtain aggregated data.

[0107] The MCP context manager uses the metricID and traceID from the basic context as globally unique identifiers. It calls the log system, metric system, trace system, and MCP knowledge base through standardized MCP protocol interfaces. Data is extracted according to preset logic: the metric system returns the response time and error rate for the corresponding metricID, the trace system returns the service call chain, and the knowledge base returns historical solutions for similar traceIDs. Only real-time data within a specific timeframe (e.g., one hour) is extracted. The extracted heterogeneous data is normalized and converted to the MCP protocol standard format. Furthermore, a priority strategy of "real-time data source > trace system > log system > knowledge base" and timestamp rules can be used to handle data conflicts, eliminate duplicate and redundant data, and ultimately form an aggregated data set. If a data source is temporarily unavailable, the system caches requests and automatically retryes them after they are restored, ensuring data integrity.

[0108] Step 3: Enrich the basic context based on the aggregated data to generate complete context information that includes the basic context, enhanced context, and lifecycle information.

[0109] The MCP context manager merges aggregated data with the basic context through field mapping to generate a complete, structured context. The enhanced context includes four parts: metrics such as response time and error rate; service dependencies extracted from the tracing system (e.g., order service → DB service → cache service); historical similar cases with knowledge base matching solutions and processing times; and business impact scope including the number of affected users, order volume, and business level (e.g., "core business, affecting 1000+ users"). Simultaneously, lifecycle information is generated, including creation time, initial version number (v1), and a default validity period of 3600 seconds, forming a complete structure of "basic + enhanced + lifecycle".

[0110] Step 4: Initialize and update the complete context information and state using the preset MCP lifecycle hook function.

[0111] The MCP Context Manager achieves full lifecycle management of the context through preset MCP lifecycle hook functions. The `onContextCreated` hook is triggered to complete initialization, validate required fields, and enter initial lifecycle information. After data aggregation and fusion are completed, the `onContextUpdated` hook is triggered to update the last update time, increment the version number (e.g., v1→v2), and record field change logs. Real-time monitoring of data size is conducted; when the data exceeds the 10MB threshold, the `onContextOverflow` hook is triggered to clean up redundant data according to the priority rule for non-core fields. Subsequently, when alarm conditions are met or the context expires, the `onAlarmTriggered` (binding alarm information and freezing the version) and `onContextDestroy` (archiving core information to the knowledge base and releasing the cache) hooks are triggered respectively, forming a closed lifecycle loop.

[0112] In one embodiment, such as Figure 4 As shown, based on complete context information, combined with the weighted diagnostic results of the dynamic threshold algorithm and the diagnostic agent cluster, the determination of whether the preset alarm triggering conditions are met includes:

[0113] S810: Obtain real-time transaction data and historical business data from the server, and calculate real-time transaction loss and maximum allowable loss based on the real-time transaction data, historical business data, and complete context information.

[0114] The server's built-in dynamic rule optimization engine automatically collects real-time transaction data (including affected transaction amounts, user levels, and transaction types) and historical business data (preset maximum allowable loss thresholds and business priority configurations for similar businesses) through the MCP adapter. Based on real-time transaction data, historical business data, and complete context information, core parameters are calculated: real-time transaction losses are derived by summarizing the direct transaction losses caused by the current event in the context's `businessImpact` field (such as the total amount of failed orders); the maximum allowable loss is extracted from historical business data, using thresholds for similar businesses (generated from historical failure loss data and supporting automatic updates), ensuring that parameters accurately match the business scenario.

[0115] S820: Calculate the business impact coefficient based on real-time transaction losses and the maximum permissible loss, and calculate the dynamic alarm threshold based on the business impact coefficient.

[0116] The business impact coefficient and dynamic alarm threshold are calculated based on real-time transaction losses and the maximum permissible loss, according to a preset formula. Specifically, the formulas for the dynamic threshold and business impact coefficient are as follows:

[0117]

[0118] In the above formula, K is the business impact coefficient, used to reflect the degree of loss impact of the current abnormal event; L is the real-time transaction loss, used to characterize the direct loss amount / quantity caused by the current event; M is the maximum allowable loss, used to characterize the preset maximum acceptable loss threshold for similar businesses; T 动 The dynamic threshold is used to characterize the final alarm threshold after coefficient adjustment; T 基 The basic threshold is used to characterize the static alarm threshold of the initial system configuration; the business impact coefficient K = real-time transaction loss L ÷ maximum allowable loss M, and the value of K is limited to the range of 0.1-0.3 by the system's built-in constraint logic (calculated result < 0.1, take 0.1; > 0.3, take 0.3; fixed at 0.1 when there is no actual loss); the dynamic alarm threshold T 动 =Basic threshold T 基 *(1-K), where the base threshold is the static threshold initially configured by the system. The threshold is lowered when the business impact coefficient is high (e.g., the threshold is lowered by 30% when K=0.3) to improve alarm sensitivity. The system can recalculate the coefficient and update the threshold every 30 seconds based on the latest context data, and at the same time verify the rationality of the coefficient through the alarm rule engine to ensure consistency with the actual business impact.

[0119] S830: Extract the error type field from the complete context information, and determine the target event type of the current event by matching with the built-in event type library and context-assisted verification.

[0120] The MCP context manager extracts the `errorType` field (an error type field, which can be automatically labeled by the MCP adapter when converting logs) from the basic context level of the complete context and performs a precise match with the server's built-in standardized event type library (which can include 4 major categories and 20+ subcategories: database, network, application, and business). If the `errorType` field is ambiguous (e.g., "unknown error"), other context fields are used for verification: based on the metric type pointed to by `metricID`, the service call chain corresponding to `traceID`, and log keywords, the event type is determined (e.g., if `metricID` points to a database metric, it is classified as a database event), thus completing the event type correction and confirmation.

[0121] S840: Based on the target event type, call multiple agents in the diagnostic agent cluster to perform collaborative diagnosis and obtain diagnostic results from multiple agents.

[0122] Based on the target event type, the MCP context manager calls the corresponding domain-specific agents from the diagnostic agent cluster through a standardized interface (e.g., database events call the database expert agent, network events call the network expert agent). Each agent independently conducts root cause analysis based on complete context information and outputs diagnostic results including diagnostic conclusions and confidence levels (0-1 range).

[0123] S850: Weighted aggregation of diagnostic results from multiple agents to obtain a comprehensive confidence level.

[0124] The diagnostic results of each agent are aggregated and calculated according to a preset weighting rule, and the agent weight W is calculated. n Based on historical diagnostic accuracy settings (such as a database expert agent weight of 0.6 and a network expert agent weight of 0.4), the following formula is used for calculation.

[0125]

[0126] In the above formula, Z is the weighted confidence level, used to characterize the overall confidence level of the diagnostic results of multiple agents; C n For the diagnostic confidence of the nth agent, such as C1 = database expert confidence, C2 = network expert confidence; W n The weight of the nth agent is set based on the historical diagnostic accuracy; N is the total number of agents participating in the diagnosis, used to characterize the total number of agents participating in the current diagnostic task in the agent cluster.

[0127] S860: Determine whether the preset alarm triggering conditions are met based on the dynamic alarm threshold and the overall confidence level.

[0128] The entire alarm trigger determination process is implemented by the server's built-in alarm rule engine in conjunction with the WheelTimer scheduler (using Netty's HashedWheelTimer for millisecond-level scheduling, triggering evaluations every minute). The scheduler specifically combines two core metrics for judgment: if the overall confidence level is greater than or equal to a preset confidence threshold (e.g., 0.7), and the abnormal metric corresponding to the event exceeds the dynamic alarm threshold, then the alarm triggering conditions are met; if either metric fails to meet the criteria, no alarm is triggered, and an evaluation log is recorded for backtracking. The judgment result is synchronized to the MCP context manager, triggering the corresponding lifecycle hook function. Here, accurate alarm judgment is achieved through dual metric verification, ensuring both the timeliness of alarms (millisecond-level scheduling) and avoiding false alarms and missed alarms through the combination of confidence level and dynamic thresholds, providing a reliable basis for subsequent alarm notifications pushed by the OnCall system.

[0129] In this embodiment, the entire alarm triggering judgment stage includes the application of a dynamic threshold algorithm, weighted diagnosis by a cluster of diagnostic agents, and millisecond-level scheduling and coordination. All operations are implemented using server hardware resources and built-in modules. Based on the complete context information generated by the S600, the alarm threshold is first optimized and adjusted in real time using a dynamic threshold algorithm combined with historical data from the MCP knowledge base to avoid false alarms and missed alarms caused by fixed thresholds. Simultaneously, the MCP context manager pushes the complete context information to the server's built-in cluster of diagnostic agents. This cluster includes agents from multiple professional fields, such as database experts, network experts, and application logic experts. Each agent interacts with the MCP context manager through a standardized interface, performs root cause analysis based on the context information, outputs its own diagnostic results, and then generates a comprehensive weighted diagnostic result through preset weighted rules. Furthermore, the server's built-in WheelTimer scheduler uses Netty's HashedWheelTimer to achieve millisecond-level precision scheduling, tightly coupled with the alarm rule engine to ensure real-time response during the judgment process. Finally, combining the results of the dynamic threshold algorithm and the weighted diagnostic results, the alarm rule engine within the server determines whether the preset alarm triggering conditions are met.

[0130] In one embodiment, after determining whether a preset alarm triggering condition is met based on complete context information, combined with the weighted diagnostic results of the dynamic threshold algorithm and the diagnostic agent cluster, the method further includes:

[0131] Step 1: If the preset alarm triggering conditions are met, generate structured alarm information based on complete context information.

[0132] The server's built-in OnCall system automatically generates standardized, structured alarm information based on the complete context information generated by S600 and the diagnostic results of S800. The information fields are strictly configured according to preset specifications, and the core includes: a unique alarm ID, alarm title (e.g., order service database timeout exception), urgency level (e.g., HIGH, related to the S820 business impact coefficient determination), context reference address, diagnostic summary (extracting the intelligent agent cluster diagnostic conclusion, such as database connection pool exhaustion, current utilization rate 95%), and suggested actions (generated by combining historical cases from the MCP knowledge base, such as expanding the order master database connection pool to 200), ensuring information completeness and adaptability to efficient operation and maintenance needs.

[0133] Step 2: Push structured alarm information and continuously monitor the alarm resolution status.

[0134] The OnCall system pushes structured alarm information, with built-in diagnostic summaries and context reference links, allowing operations and maintenance personnel to quickly jump to view the complete context and diagnostic details. Simultaneously, the WheelTimer scheduler continuously monitors the recovery status of the corresponding abnormal indicators every minute, with the timeout period dynamically adjusted based on the business impact coefficient (the timeout threshold is shortened for high-business-impact scenarios, such as 30 minutes; set to 60 minutes for normal scenarios), and the context lifecycle status is updated synchronously.

[0135] Step 3: If the alarm timeout is not resolved, create an operation and maintenance work order on the authorized work order platform based on the structured alarm information and push it.

[0136] When monitoring detects that an alarm has timed out and remains unresolved, the OnCall system automatically triggers an escalation strategy, creating an operation and maintenance work order on the Jira authorized work order platform based on the structured alarm information. The work order automatically associates the alarm's unique ID, complete context reference address, diagnostic summary, and suggested actions, assigning it to the corresponding operation and maintenance personnel according to business module and problem type (e.g., assigning database problems to the database operation and maintenance group), and simultaneously sending a reminder to the work order manager.

[0137] In one embodiment, after pushing structured alarm information and continuously monitoring the alarm status, the method further includes:

[0138] Step 1: If the alarm has been processed, collect the alarm event ID and associated information of the historical alarm events.

[0139] The server's built-in OnCall system automatically collects all associated data of processed alarm events. The core data includes the unique alarm event ID (eventId), complete context information generated by S600, the root cause of the problem output by the diagnostic agent cluster, the remedial measures performed by maintenance personnel, the resolution time and the processing effect score. All data is archived in the MCP protocol standard format to ensure compatibility with the knowledge base data structure. At the same time, it is associated with the corresponding traceID, metricID and service name to form a standardized dataset.

[0140] Step 2: Using alarm event ID as a node, construct an initial association diagram for different alarm events based on preset association dimensions; preset association dimensions include link association, indicator association, error type association, and service association.

[0141] The MCP context manager uses the alarm event ID (eventId) as the core node and the correlation information collected in step 1 as node attributes (including error type, service name, root cause of the problem, etc.). Based on the standardized context schema of the MCP protocol, it automatically constructs an initial correlation graph according to four preset correlation dimensions. Among them, the link correlation corresponds to cross-service chain anomaly events with the same traceID, the metric correlation corresponds to similar anomaly events with the same metricID, the error type correlation corresponds to repeated events with the same errorType, and the service correlation corresponds to multiple types of fault events in the same service. A correlation edge is established when any dimension condition is met, and the correlation type is marked.

[0142] Step 3: Based on the error type, root cause and remedial measures data corresponding to each node in the initial relationship graph, calculate the comprehensive similarity between each node.

[0143] The MCP intelligent layer extracts the core feature data of each node through internal interfaces and calculates the comprehensive similarity by comparing multiple dimensions: the error type dimension verifies whether they are the same errorType and subdivided scenario, the root cause dimension compares whether they point to the same core fault point (such as both being database connection pool configuration issues), and the remediation measures dimension judges the consistency of the solutions (such as both being expansion operations). The comprehensive similarity value in the range of 0-1 is obtained by weighted summation of the similarity of each dimension. The weight allocation is linked to the historical accuracy of the diagnostic intelligent agent cluster.

[0144] Step 4: Assign weights to the edges in the initial association graph based on the comprehensive similarity, and remove the edges with weights lower than the preset weight threshold to obtain the updated association graph.

[0145] The overall similarity is directly mapped to the weight of the associated edges (the higher the similarity, the greater the weight). Simultaneously, relationship graph optimization is performed: a preset weight threshold of 0.3 is used to automatically remove invalid associated edges with weights below this threshold, retaining high-value associations (weight ≥ 0.3); high-value associated edges with weights ≥ 0.8 are marked as core associations to uncover potential common root causes. The optimized and updated relationship graph is synchronized to the MCP knowledge base, iteratively updated based on a preset update cycle (e.g., every 24 hours) and combined with newly added alarm processing data to ensure the timeliness and accuracy of the relationships.

[0146] It should be understood that although the steps in the flowcharts of the above embodiments are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the above embodiments may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0147] Based on the same inventive concept, this application also provides a server alarm event handling apparatus for implementing the above-described server alarm event handling method. The solution provided by this apparatus is similar to the implementation described in the above method; therefore, the specific limitations in one or more server alarm event handling apparatus embodiments provided below can be found in the limitations of the server alarm event handling method described above, and will not be repeated here.

[0148] like Figure 5 As shown, this application also provides an alarm event handling device for a server. The device includes:

[0149] The configuration module 200 is used to respond to alarm system configuration operations and send the dynamic configuration data corresponding to the alarm system configuration operations to the jLogtail collector.

[0150] The log collection module 400 is used to obtain the raw logs from the jLogtail collector server, convert the collected raw logs into standard format events, and push them to the message queue.

[0151] The context supplementation module 600 is used to call the MCP context manager to consume standard format events from the message queue, supplement context information with the core identifier corresponding to the standard format event as a clue, and generate complete context information;

[0152] The alarm judgment module 800 is used to determine whether the preset alarm triggering conditions are met based on complete context information, combined with the weighted diagnostic results of the dynamic threshold algorithm and the diagnostic agent cluster.

[0153] In one embodiment, the configuration module 200 is also used to display a visual web configuration interface; respond to alarm system configuration operations on the visual web configuration interface to obtain dynamic configuration data; persistently store the dynamic configuration data in a MySQL database; and call an HTTP interface to push the dynamic configuration data to the jLogtail collector.

[0154] In one embodiment, the log collection module 400 is further configured to acquire the raw logs of the jLogtail collector collection server; preprocess the raw logs to obtain preprocessed logs; convert the preprocessed logs into standard format events including time ID, timestamp, service name, error type and core context information through the MCP adapter; and push the standard format events to the Kafka message queue.

[0155] In one embodiment, the context supplementation module 600 is further configured to call the MCP context manager to consume standard format events from the message queue, and extract the service name, error type, and core fields from the standard format events as the basic context; using the core identifier in the standard format events as clues, query and aggregate related data from logs, metrics, trace links, and knowledge base systems to obtain aggregated data; enrich the basic context based on the aggregated data to generate complete context information containing the basic context, enhanced context, and lifecycle information; and initialize and update the complete context information through a preset MCP lifecycle hook function.

[0156] In one embodiment, the alarm judgment module 800 is further configured to acquire real-time transaction data and historical business data from the server; calculate real-time transaction loss and maximum permissible loss based on the real-time transaction data, historical business data, and complete context information; calculate the business impact coefficient based on the real-time transaction loss and maximum permissible loss, and calculate the dynamic alarm threshold based on the business impact coefficient; extract the error type field from the complete context information, and determine the target event type of the current event by matching it with the built-in event type library and using context-assisted verification; call multiple agents in the diagnostic agent cluster to perform collaborative diagnosis based on the target event type, and obtain the diagnosis results of multiple agents; perform weighted aggregation on the diagnosis results of multiple agents to obtain a comprehensive confidence level; and determine whether the preset alarm triggering conditions are met based on the dynamic alarm threshold and the comprehensive confidence level.

[0157] In one embodiment, the alarm event processing device in the server further includes an alarm event tracking module, which is used to generate structured alarm information based on complete context information if the preset alarm triggering conditions are met; push the structured alarm information and continuously monitor the alarm resolution status; if the alarm is not resolved after timeout, create an operation and maintenance work order on the authorized work order platform based on the structured alarm information and push it.

[0158] In one embodiment, the alarm event tracking module is further configured to collect the alarm event IDs and associated information of historical alarm events if the alarm has been processed; construct an initial association graph of different alarm events based on the alarm event IDs as nodes and according to preset association dimensions; the preset association dimensions include link association, indicator association, error type association, and service association; calculate the comprehensive similarity between nodes based on the error type, root cause, and remediation measures data corresponding to each node in the initial association graph; assign weights to the associated edges in the initial association graph based on the comprehensive similarity, and remove associated edges with weights lower than a preset weight threshold to obtain an updated association graph.

[0159] The various modules in the alarm event handling device of the aforementioned server can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of the computer device in hardware form or independent of it, or stored in the memory of the computer device in software form, so that the processor can call and execute the corresponding operations of each module.

[0160] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 6 As shown, the computer device includes a processor, memory, and a network interface connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores preset data. The network interface communicates with external terminals via a network connection. When executed by the processor, the computer program implements an alarm event handling method in a server.

[0161] Those skilled in the art will understand that Figure 6 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0162] In one embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the alarm event handling method in the server described above.

[0163] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the alarm event handling method in the server described above.

[0164] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the alarm event handling method in the server described above.

[0165] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0166] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0167] The above embodiments are merely illustrative of several implementation methods of this application, and their descriptions are relatively specific and detailed. However, they should not be construed as limiting the scope of this application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A method for handling alarm events in a server, characterized in that, The method includes: In response to alarm system configuration operations, the corresponding dynamic configuration data is sent to the jLogtail collector. The jLogtail collector acquires the raw logs from the server, converts the collected raw logs into standard format events, and pushes them to the message queue. The MCP context manager is invoked to consume standard format events from the message queue, and context information is supplemented using the core identifier corresponding to the standard format event as a clue to generate complete context information. Based on the complete context information, and combined with the weighted diagnostic results of the dynamic threshold algorithm and the diagnostic agent cluster, it is determined whether the preset alarm triggering conditions are met.

2. The method according to claim 1, characterized in that, The alarm system configuration operation, which involves sending the corresponding dynamic configuration data to the jLogtail collector, includes: Displays a visual web configuration interface; In response to alarm system configuration operations on the visual web configuration interface, dynamic configuration data is obtained; The configuration dynamic data is persistently stored in a MySQL database; The HTTP interface is called to push the dynamic configuration data to the jLogtail collector.

3. The method according to claim 1, characterized in that, The process of obtaining the raw logs from the jLogtail collector server, converting the collected raw logs into standard format events, and pushing them to the message queue includes: Obtain the raw logs collected by the jLogtail collector from the server; The original log is preprocessed to obtain the preprocessed log; The preprocessed logs are converted into standard format events, including time ID, timestamp, service name, error type, and core context information, using the MCP adapter. Push the standard format event to the Kafka message queue.

4. The method according to claim 1, characterized in that, The process of calling the MCP context manager to consume standard format events from the message queue, supplementing context information using the core identifier corresponding to the standard format event as a clue, and generating complete context information includes: The MCP context manager is invoked to consume standard format events from the message queue and extract the service name, error type, and core fields from the standard format events as the base context. Using the core identifiers in the standard format events as clues, query and aggregate related data from logs, metrics, link tracing, and knowledge base systems to obtain aggregated data; The basic context is enriched based on the aggregated data to generate complete context information that includes the basic context, enhanced context, and lifecycle information. The complete context information is initialized and its state is updated through a preset MCP lifecycle hook function.

5. The method according to claim 1, characterized in that, The step of determining whether the preset alarm triggering conditions are met based on the complete context information, combined with the weighted diagnostic results of the dynamic threshold algorithm and the diagnostic agent cluster, includes: Obtain real-time transaction data and historical business data from the server, and calculate real-time transaction loss and maximum allowable loss based on the real-time transaction data, the historical business data, and the complete context information; The business impact coefficient is calculated based on the real-time transaction loss and the maximum allowable loss, and the dynamic alarm threshold is calculated based on the business impact coefficient. The error type field is extracted from the complete context information, and the target event type of the current event is determined by matching it with the built-in event type library and by context-assisted verification. Based on the target event type, multiple agents in the diagnostic agent cluster are invoked to perform collaborative diagnosis, and the diagnostic results of multiple agents are obtained. The diagnostic results of the multiple intelligent agents are weighted and aggregated to obtain a comprehensive confidence level; Based on the dynamic alarm threshold and the overall confidence level, determine whether the preset alarm triggering conditions are met.

6. The method according to claim 1, characterized in that, After determining whether the preset alarm triggering conditions are met based on the complete context information, combined with the weighted diagnostic results of the dynamic threshold algorithm and the diagnostic agent cluster, the process further includes: If the preset alarm triggering conditions are met, structured alarm information is generated based on the complete context information. The structured alarm information is pushed out, and the alarm resolution status is continuously monitored; If the alarm is not resolved within the timeout period, an operation and maintenance work order will be created on the authorized work order platform based on the structured alarm information and pushed to the platform.

7. The method according to claim 6, characterized in that, After pushing the structured alarm information and continuously monitoring the alarm status, the method further includes: If the alarm has been processed, collect the alarm event ID and associated information of the historical alarm events; Using alarm event IDs as nodes, an initial association graph of different alarm events is constructed based on preset association dimensions; the preset association dimensions include link association, indicator association, error type association, and service association. Based on the error type, root cause and remedial measures data corresponding to each node in the initial association graph, calculate the comprehensive similarity between each node; Based on the comprehensive similarity, weights are assigned to the associated edges in the initial association graph, and associated edges with weights lower than a preset weight threshold are removed to obtain an updated association graph.

8. An alarm event handling device for a server, characterized in that, The device includes: The configuration module is used to respond to alarm system configuration operations and send the dynamic configuration data corresponding to the alarm system configuration operations to the jLogtail collector. The log collection module is used to obtain the raw logs from the jLogtail collector server, convert the collected raw logs into standard format events, and push them to the message queue. The context supplementation module is used to call the MCP context manager to consume standard format events from the message queue, supplement context information with the core identifier corresponding to the standard format event as a clue, and generate complete context information. The alarm judgment module is used to determine whether the preset alarm triggering conditions are met based on the complete context information, combined with the weighted diagnostic results of the dynamic threshold algorithm and the diagnostic agent cluster.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

Images