An alarm method based on multi-dimensional health check and electronic device

Abstract

The application discloses a kind of based on multi-dimension health check alarm method and electronic equipment, method includes: by obtaining system state check request;At least two checks in HTTP health check, database health check, cache health check, TCP health check, command health check and custom health check are carried out, obtain multiple check results;Multiple check results are aggregated, and aggregation result is obtained;Alarm decision is executed based on aggregation result.This application is aggregated by multi-dimension health check result, and according to the historical health check result of each dimension, to obtain the abnormal event of each dimension, different types of services can be comprehensively monitored to improve the accuracy of system health state evaluation, alarm decision is executed based on aggregation result to send alarm notice, and the alarm and response action of abnormal event are triggered automatically and automatically and differentially.

Description

Technical Field

[0001] This invention relates to the field of computer system monitoring technology, and in particular to an alarm method and electronic device based on multi-dimensional health checks. Background Technology

[0002] With the widespread adoption of microservice architectures and distributed systems, monitoring system health has become increasingly complex. Traditional health check methods typically only perform simple checks on a single type of service, failing to comprehensively assess the overall health of the system and resulting in poor accuracy. Summary of the Invention

[0003] The technical problem to be solved by the present invention is to provide an alarm method and electronic device based on multi-dimensional health checks, which enables comprehensive health status monitoring of different types of services to improve the accuracy of system health status assessment.

[0004] To solve the above-mentioned technical problems, the present invention adopts the following technical solution: An alarm method based on multi-dimensional health checks, applied to electronic devices, the method comprising: Get a system status check request; Perform at least two of the following health checks: HTTP health check, database health check, cache health check, TCP health check, command health check, and custom health check, and obtain multiple check results; The multiple inspection results are aggregated to obtain an aggregated result; Alarm decisions are made based on the aggregation results.

[0005] To solve the above-mentioned technical problems, another technical solution adopted by the present invention is as follows: An electronic device includes a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the processor executes the computer program to implement the steps of the above-described alarm method based on a multi-dimensional health check.

[0006] The beneficial effects of this invention are as follows: By obtaining system status check requests; performing at least two of the following checks—HTTP health check, database health check, cache health check, TCP health check, command health check, and custom health check—multiple check results are obtained; these multiple check results are aggregated to obtain an aggregated result; and alarm decisions are executed based on the aggregated result. This application achieves comprehensive health status monitoring for different types of services by aggregating multi-dimensional health check results and obtaining abnormal events for each dimension based on historical health check results for each dimension. This improves the accuracy of system health status assessment, executes alarm decisions based on the aggregated result to send alarm notifications, and optimizes alarm decisions through feedback on alarm notification handling, thereby improving the accuracy and timeliness of abnormal monitoring of system services. Attached Figure Description

[0007] Figure 1 A flowchart illustrating the steps of an alarm method for a multi-dimensional health check provided in an embodiment of the present invention; Figure 2 The overall flow of an alarm method for a multi-dimensional health check provided in an embodiment of the present invention; Figure 3 A system architecture diagram of an alarm method for multi-dimensional health checks provided in an embodiment of the present invention; Figure 4 A smart alarm status diagram of an alarm device for multi-dimensional health checks provided in an embodiment of the present invention; Figure 5 A multi-channel notification sequence diagram for an alarm method for multi-dimensional health checks provided in an embodiment of the present invention; Figure 6 A data analysis data flow diagram of an alarm device for multi-dimensional health checks provided in an embodiment of the present invention; Figure 7 A root cause analysis flowchart of an alarm device for multi-dimensional health checks provided in an embodiment of the present invention; Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0008] To make the technical problems, technical solutions, and beneficial effects to be solved by 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 are not intended to limit the scope of this application.

[0009] In related technologies, the health status is typically determined by periodically requesting the target system or server endpoint and analyzing the returned HTTP status codes. While this method provides basic monitoring of service availability, it suffers from the following problems in practical applications: (1) The health check has only one dimension and mainly relies on HTTP status codes, which cannot fully reflect the system status; (2) The lack of an intelligent alarm mechanism makes it easy for false alarms or missed alarms to occur; (3) The monitoring data lacks correlation analysis, making it difficult to conduct root cause analysis; (4) The alarm notification channels are limited and cannot meet the notification needs of different scenarios.

[0010] To address the aforementioned problems, this application provides an alarm method and electronic device based on multi-dimensional health checks. The following details the alarm method and electronic device based on multi-dimensional health checks proposed in this application.

[0011] The alarm method and electronic device method based on multi-dimensional health checks in this application can be used in various applications. The electronic device in this application can be a mobile terminal, computer, IoT device, or embedded system, such as a mobile phone, tablet computer, laptop computer, or smartwatch.

[0012] The following details the alarm method and electronic device method based on multi-dimensional health checks in this invention, with reference to the appendix. Figure 1 This includes steps S110-S140.

[0013] S110. Obtain a system status check request. Specifically, in response to system monitoring task scheduling or external triggering, obtain a status check request for the target system. The request must at least include the target service identifier to be checked and the check type configuration.

[0014] S120. Perform at least two of the following health checks: HTTP health check, database health check, cache health check, TCP health check, command health check, and custom health check, and obtain multiple check results. (See appendix) Figure 2 and attached Figure 3Upon receiving a request, the system retrieves its check configuration, which may include HTTP health checks, database health checks, and cache health checks. It initializes the check items in each health check, for example, setting the initial value for HTTP response time to 0. HTTP health checks examine the accessibility, functionality, and performance of API endpoints or web applications providing services via HTTP or HTTPS protocols, obtaining results for the application service. Database health checks examine the connectivity, query execution capabilities, data consistency, and performance status of relational databases (such as MySQL, PostgreSQL, Oracle, etc.) or non-relational databases, obtaining results for the database service. Cache health checks examine the connectivity, basic data operation functions, service resource status, and operational performance of caching services (such as Redis, Memcached, etc.), obtaining results for the caching service. TCP health checks are used to inspect the transport layer connectivity and port reachability of a target network service. They verify whether the service is accessible on a specified network port by establishing a TCP connection. This method is applicable to various TCP-based network services, including but not limited to database services, caching services, message queues, and custom TCP services. Executing a TCP health check yields the results for the TCP service. Command health checks are used to check the runtime state, resource availability, business logic correctness, or any system attributes verifiable via a command-line interface by executing specific operating system commands or custom scripts. Executing a command health check yields the results for the command-line service. Custom health checks are used to verify the specific health status of a system, application, or service through user-defined check logic, scripts, or integration schemes. They cover personalized, complex, or business-specific health verification needs that standard check protocols cannot meet. Executing a custom health check yields the results for the custom service. Specifically, depending on the check type configuration, at least two check modules in the multi-dimensional health check engine are invoked to execute the corresponding health check operations in parallel or serially. Each module generates independent monitoring data, and the historical monitoring data for each batch of checks is stored in the monitoring database. For example, if the check configuration includes HTTP health checks and database health checks, then the HTTP health check module and the database health check module in the multi-dimensional health check engine are called respectively to obtain the HTTP health check results and the database health check results.

[0015] S130. Aggregate multiple check results to obtain an aggregated result. Specifically, the aggregated result includes HTTP health check results, database health check results, cache health check results, TCP health check results, command health check results, and custom health check results. All health checks must pass for the system health check to be successful, and the aggregated result will be considered successful. If any health check fails, the system health check is considered failed, and the aggregated result will be considered failed. Update the monitoring status based on the aggregated result. The monitoring status includes a normal status and an abnormal status. If the monitoring status is normal, continue monitoring the system; if the monitoring status is abnormal, obtain abnormal events.

[0016] S140. Execute alarm decisions based on aggregation results. Specifically, when the system analyzes the aggregation results as failures, it extracts the abnormal events from the aggregation results, determines the category of the abnormal events (e.g., low-risk, medium-risk, or high-risk abnormalities), and executes alarm decisions based on the category of the abnormal events.

[0017] In this way, by obtaining system status check requests, at least two of the following checks are performed: HTTP health check, database health check, cache health check, TCP health check, command health check, and custom health check. Multiple check results are obtained, and by aggregating these multi-dimensional health check results, comprehensive health status monitoring of different types of services is achieved. By aggregating multiple check results, an aggregated result is obtained. Based on historical health check results for each dimension and the calculation of dynamic thresholds for performance indicators, abnormal events for each dimension are identified, and the normality of performance indicators is determined based on the dynamic thresholds. This aggregated result improves the accuracy of system health status assessment. Alarm decisions are executed based on the aggregated result. According to the classification of abnormal events in the aggregated result, alarm decisions are automatically executed to send alarm notifications. Subsequent feedback on the handling of alarm notifications optimizes alarm decisions, improving the accuracy and timeliness of anomaly monitoring of system services.

[0018] In one embodiment of this application, performing an HTTP health check in step S120 includes S121.

[0019] S121. Send a request using a specified HTTP method to the target URL of the target API endpoint or Web service. The HTTP method includes at least one of GET, POST, PUT, or DELETE. Wait and receive a response within a preset timeout threshold to obtain response information containing the HTTP response status code, response body content, and response time. Verify that the HTTP response status code in the response information matches the preset expected status code. For example, if the expected status code is configured as 200, verify that the actual returned response status code is 200. Perform content verification on the response body content based on preset expected content fragments or keywords. If the response body content contains one or more expected content fragments or keywords, the response body content verification passes; otherwise, the verification fails. Determine the HTTP response time in the response information based on the time elapsed from sending the request to receiving the complete response information, and compare the response time with a preset maximum response time threshold to verify that the response time meets the requirement of being less than or equal to the maximum response time threshold. An HTTP health check is considered successful if all three of the following conditions are met: the response status code matches the expected status code, the response body content passes content validation, and the response time is within the maximum response time threshold. If any one of these conditions is not met, the HTTP health check is considered a failure, and the specific reason for the failure is recorded.

[0020] In one embodiment of this application, the database health check in step S120 includes S122.

[0021] S122. Establish a network connection with the target relational database via a database connection protocol. The relational database includes at least one of MySQL, PostgreSQL, or Oracle databases. Also check the connection pool status associated with the database to assess the availability of connection resources. Through the established connection, execute a predefined query statement to test the operability of the database service and obtain the query results. According to preset validation rules, execute one or more validation queries targeting key business data tables. Validation queries are used to check the integrity, logical consistency, or normality of data, such as verifying the non-nullability of important fields in specific business tables, the validity of enumerated values, or the integrity of data references between related tables. Record the time elapsed from sending the query statement to receiving the complete query results as the database query time. The database health check is considered passed if all of the following conditions are met: a network connection to the relational database is successfully established; the query statement is executed normally and returns the expected result; the key data tables are verified to confirm data consistency; and the database query time is within the preset acceptable time threshold. If any condition is not met, such as failure to establish a connection, query execution error, data consistency check failure, or database query time exceeding the acceptable time threshold, the database health check is considered a failure, and the specific reason for the failure is recorded.

[0022] In one embodiment of this application, the cache health check in step S120 includes S123.

[0023] S123. Establish a network connection with the target caching service, wherein the caching service includes at least one of Redis or Memcached services. Establishing the connection includes initiating a connection request to the host address and port of the caching service instance, and completing the connection establishment within a preset connection timeout period. Through the established connection, sequentially execute a set of predefined basic read and write operations on the target caching service to verify its core functionality. The read and write operations include: using the SET command to write a test key-value pair with a unique identifier to the cache; and then using the GET command to read the value corresponding to the test key. Obtain the runtime status information of the target caching service, which includes at least the current memory usage and cache hit rate statistics. Determine whether the target cache exceeds a preset alarm threshold based on the memory usage, and evaluate the performance of the target caching service based on the cache hit rate. Record the time taken from sending the SET command to receiving the response for the GET command, as the write operation response time and the read operation response time. The cache health check is considered passed if and only if all of the following conditions are met: a network connection to the target cache service is successfully established; both the SET and GET commands are executed normally, and the read values ​​are consistent with the written values; the response time for both write and read operations is within the preset acceptable time range; and the target cache service is running normally based on runtime status information. If any condition is not met, the cache health check is considered to have failed.

[0024] In one embodiment of this application, performing a TCP health check in step S120 includes step S124.

[0025] S124. Initiate a Transmission Control Protocol (TCP) connection request to the specified host address and port number of the target network service to attempt to establish a TCP connection with the target port on the target host. The target network service includes at least one of a database service, a caching service, or a message queue service. Configure a connection timeout threshold for the TCP connection request. If the connection is not established within the timeout threshold, the connection attempt is considered a failure. If the TCP three-way handshake is successfully completed within the connection timeout threshold, the TCP connection is considered successfully established, and the established TCP connection is then actively closed. Record the time elapsed from initiating the TCP connection request to successfully establishing the connection as the TCP connection establishment time. The TCP health check is considered successful if all of the following conditions are met: a TCP connection is successfully established within the connection timeout threshold; the connection establishment time does not exceed the preset acceptable time range; and the target port is verified to be in a listening state and accessible. Successfully establishing a TCP connection serves as direct proof of the target port's reachability. If a TCP connection is not successfully established within the connection timeout threshold, or if it is successfully established but the connection establishment time exceeds the acceptable time range, the TCP health check is considered a failure, and the corresponding reason for failure is recorded.

[0026] In one embodiment of this application, the command health check in step S120 includes S125.

[0027] S125. Execute the specified Shell command or predefined script on the target system, where the target system is a local system or a remote system accessible via a network. Set a timeout for this execution to prevent the process from hanging for an extended period. Capture the standard output stream and error output stream during command or script execution. Based on preset verification rules, check whether the standard output stream contains one or more expected success flag strings, and check whether the error output stream does not contain specific error keywords or exception patterns. After command execution, obtain the process's exit code and compare it with the preset expected exit codes. For example, an exit code of 0 indicates successful execution. Record the duration from command execution to complete process termination as the command execution time. The health check result of this command is determined to be passed if and only if all of the following conditions are met: the exit code of the command matches the expected exit code, the execution time of the command is within the preset reasonable time range, and the output stream content verification meets the expectations, that is, the standard output stream content contains the expected content and the error output stream content does not contain the error keywords; if the exit code does not match, the execution time times out, or the output content verification fails, the health check result of this command is determined to be failed.

[0028] In one embodiment of this application, the custom health check in step S120 includes S126.

[0029] S126. The system receives and parses the custom health check configuration submitted by the user through a preset interface. The configuration is defined in a structured data format, such as JSON, and includes at least the following configurable items: check type identifier, check target address, timeout parameter, and one or more success criteria. For example, the user can embed a `health_checks` array containing multiple custom check items in the application deployment configuration via the release management API. For custom checks with a check type identifier of command or script, the system creates an asynchronous execution subprocess on the target server according to the script path or command content specified in the self-configuration. The system provides a controlled environment for the execution of the subprocess, including but not limited to setting an execution timeout control mechanism to prevent the script from executing indefinitely. The system performs the corresponding health check operation according to the parsed configuration. For example, for HTTP type checks, the system sends a request according to the configured HTTP method, URL, and timeout parameter, and captures the response status code, response content, and response time; for TCP type checks, the system attempts to establish a TCP connection with the host and port specified in the configuration and measures the connection establishment time; for command or script type checks, the system executes the configured command or script and synchronously captures its standard output, error output, and final exit code. The system compares the captured check results with the expected criteria defined in the user configuration. Criteria include, but are not limited to: expected HTTP status codes, keywords required in the response content, maximum allowed response time, expected exit codes for commands or scripts, and output content verification. A custom health check is considered successful only if all configured criteria are met. The system manages user-submitted custom health check configurations and the system's default check configurations uniformly. When applying configurations, a clear priority rule is followed: user-provided custom health check configurations for a specific release or service have the highest priority and will completely override the system's default health check configurations of the same type; if the user does not provide a custom configuration for a certain type of check, the system's default health check configuration corresponding to that operating environment (such as production or testing environments) will be automatically applied. All effective health check configurations are persistently stored and associated with specific release records or service identifiers.

[0030] In one embodiment of this application, step S130 includes steps S131 to S135.

[0031] S131. Collect historical check data of preset performance indicators from historical data of multiple check results to form time series data. Specifically, after each multi-dimensional health check, the system not only records the status (e.g., pass or fail) of each health check item (such as HTTP response time, database query time, cache write operation response time, read operation response time, command execution time), but also synchronously records the success rate used to calculate the overall system health, as well as various quantifiable performance observations. The success rate is equal to the number of passed checks divided by the total number of checks. The health check items, success rate, and performance observations are used as performance indicators, such as the specific response time in milliseconds for each HTTP health check and the success rate calculated for each batch of health checks. The historical data of the performance indicators and their corresponding timestamps are stored together. An independent time series table is built for each performance indicator to store the time series data, and the time series data of each performance indicator is stored in a time series database.

[0032] S132. Based on time series data, calculate the exponentially weighted moving average of the performance index at the current time using the exponentially weighted moving average algorithm. The formula for calculating the exponentially weighted moving average is: EWMA(t) = ɑ × x(t) + (1 - ɑ) × EWMA(t-1); where EWMA(t) is the exponentially weighted moving average of the performance index at the current time t, ɑ is a smoothing factor used to control the sensitivity to new data, and the smoothing factor ranges from 0 to 1 (e.g., between 0.1 and 0.3), x(t) is the actual observed value of the performance index at the current time t, and EWMA(t-1) is the exponentially weighted moving average of the performance index at the previous time t-1. For example, the system adjusts the dynamic threshold for the performance metric "success rate." Based on the time-series data of the success rate, if the initial value of the success rate is set to 100% and the smoothing factor α is configured to 0.2, after completing the previous health check, the system calculates that the success rate of the previous (t-1) health check was 98%. Using the exponentially weighted moving average formula: 0.2 × 98% + 0.8 × 100%, the exponentially weighted moving average of the success rate in the previous health check is calculated to be 99.6%, and the time-series data of the success rate is updated. After performing the current health check, the system calculates that the success rate of this check is 95%. The system uses the previous exponentially weighted moving average of 99.6% for iterative calculation, substituting it into the formula: 0.2 × 95% + 0.8 × 99.6%, to calculate the success rate of this health check to be 98.68%, and the time-series data of the success rate is updated.

[0033] S133. Based on time series data, calculate the standard deviation of historical data for performance indicators. Specifically, the system selects historical observations of each performance indicator within a preset statistical period. For example, based on the time series data of success rate, it extracts all success rate values ​​from the past 24 hours and calculates the statistical standard deviation σ of all success rate values. The standard deviation σ quantifies the natural fluctuation range of the performance indicator under normal operating conditions. For example, for the success rate indicator, σ reflects its stability; for indicators such as response time, σ reflects the volatility of its response delay.

[0034] S134. Based on the exponentially weighted moving average and standard deviation, calculate the dynamic threshold of the performance indicator according to a preset algorithm. Specifically, the system synthesizes the exponentially weighted moving average obtained in S132 at the current time with the standard deviation σ of the historical data obtained in S133 to generate an adaptive, non-fixed dynamic threshold. The formula for calculating the dynamic threshold is: Dynamic Threshold = EWMA + k × σ, where EWMA is the exponentially weighted moving average at the current time, σ is the standard deviation at the current time, and k is the confidence factor. The confidence factor is a configurable parameter (e.g., 2 or 3) used to control the sensitivity of alarms. For example, for the success rate indicator, an alarm can be triggered when the success rate is lower than a dynamic threshold; for the response time indicator, an alarm can be triggered when the response time exceeds a dynamic threshold. In this way, the threshold can dynamically fluctuate according to the actual performance of the system.

[0035] S135. Based on the judgment results of whether the actual observed values ​​of performance indicators meet the preset dynamic thresholds, the judgment results of the dynamic thresholds and multiple check results are aggregated to obtain an aggregated result. Specifically, after each health check operation is completed, the system summarizes the health check results of all dimensions, counts the total number of checks, the number of passes, and the number of failures, and calculates the current overall success rate, storing the success rate value in a time series table. The system compares the calculated current overall success rate and the actual observed values ​​of each key performance indicator with the latest dynamic threshold calculated in step 134. For example, if the current success rate of 90% is lower than its dynamic threshold of 95%, a "success rate" abnormal event is triggered and an alarm is issued; when the HTTP response time of 2000 milliseconds exceeds its dynamic threshold of 1500 milliseconds, an "HTTP response time" abnormal event is triggered and an alarm is issued. The system automatically aggregates the judgment results of the dynamic thresholds of each performance indicator and the health check results of each dimension to obtain an aggregated result. For example, the aggregated result includes the judgment results of the dynamic thresholds of the performance indicator "success rate", the judgment results of the dynamic thresholds of the performance indicator "HTTP response time", the HTTP health check results, and cache health checks, etc.

[0036] In this way, historical inspection data of preset performance indicators are collected from historical data of multiple inspection results to form time-series data. The system continuously collects and stores historical performance indicator observations from different health check modules (such as HTTP response time, database query time, etc.) to construct a time-series dataset that reflects the changing patterns of performance indicators over time. Based on the time-series data, an exponentially weighted moving average algorithm is used to calculate the exponentially weighted moving average of the performance indicators at the current moment. By applying the exponentially weighted moving average algorithm, the calculation results can more sensitively reflect the latest trends in system performance changes, while still retaining some of the long-term influence of historical data. Based on the time-series data, the standard deviation of the historical data of performance indicators is calculated. The standard deviation represents the dispersion and stability of the performance indicators over historical periods. A larger standard deviation indicates that the indicator fluctuates drastically, while a smaller standard deviation indicates that the indicator is relatively stable. Based on the exponentially weighted moving average and standard deviation, a dynamic threshold for performance indicators is calculated according to a preset algorithm. This threshold is not a fixed value but dynamically changes with the historical performance and recent trends of the performance indicators. This allows the alarm system to intelligently distinguish between normal fluctuations and genuine anomalies, significantly reducing false alarms and missed alarms. Based on whether the actual observed values ​​of the performance indicators meet the preset dynamic threshold, the judgment results of the dynamic threshold and multiple inspection results are aggregated to obtain an aggregated result. By integrating the intelligent threshold judgment results with inspection results from other dimensions, a comprehensive health status assessment is formed, resulting in a more comprehensive and accurate aggregated conclusion on the system's health status, providing precise input for subsequent alarm decisions.

[0037] In one embodiment of this application, step S135 includes steps S1351 to S1353.

[0038] S1351. If any one of the multiple check results is failed, the aggregated result is failed. For example, if the multiple check results include HTTP health check results, database health check results, cache health check results, TCP health check results, command health check results, and custom health check results, and the HTTP health check result, database health check result, cache health check result, TCP health check result, and custom health check result are all passed, but the command health check result is failed, the aggregated result is failed.

[0039] S1352. When the actual observed value of any performance metric does not meet the preset dynamic threshold condition, the aggregation result is "fail". For example, the performance metrics include "success rate" and "HTTP response time". When the "success rate" is lower than the dynamic threshold of success rate and the "HTTP response time" does not exceed the dynamic threshold of response time, that is, when the "success rate" does not meet the preset dynamic threshold condition and the "HTTP response time" meets the preset dynamic threshold condition, the aggregation result is "fail".

[0040] S1353. When all check results in multiple checks pass and the actual observed values ​​of all performance metrics meet the preset dynamic threshold conditions, the aggregated result is considered passed. For example, when the HTTP health check result, database health check result, cache health check result, TCP health check result, command health check result, and custom health check result all pass, and the "success rate" and "HTTP response time" each meet the preset dynamic threshold conditions, the aggregated result is considered passed.

[0041] In this way, if any one of the multiple check results fails, the aggregated result is also considered "failed." This ensures comprehensive capture of service functionality anomalies and allows for the immediate detection of any explicit faults causing service failure. Similarly, if any observed performance metric fails to meet a preset dynamic threshold, the aggregated result is also considered "failed." Even if all health checks pass, if the observed value of any key performance metric (such as "success rate" or "response time") deviates from its historical dynamic normal range, the aggregated result is still considered "failed," resolving the issue of missed detections in traditional monitoring scenarios such as "response but slow speed." Finally, if all check results pass and all observed performance metrics meet the preset dynamic threshold, the aggregated result is considered "passed," enabling multi-dimensional system evaluation and making health assessments more comprehensive and accurate.

[0042] In one embodiment of this application, reference is made to the appendix. Figure 4 Step S140 includes steps S141 to S145.

[0043] S141. When the aggregation result is unsuccessful, retrieve the exception events from the aggregation result. For example, when the aggregation result includes multiple check results such as HTTP health check results, database health check results, cache health check results, TCP health check results, command health check results, custom health check results, the judgment result of the dynamic threshold of "success rate", and the judgment result of the dynamic threshold of "HTTP response time", and among them, if the HTTP health check result is unsuccessful, the "success rate" is lower than the dynamic threshold of success rate, and the "HTTP response time" exceeds the dynamic threshold of response time, then the aggregation result is unsuccessful, and the exception events retrieved from the aggregation result include HTTP health check exception, "success rate" exception, and "HTTP response time" exception.

[0044] S142. Alarms are categorized based on the severity of the anomaly. Specifically, anomalies are classified into low-risk, medium-risk, or high-risk anomalies based on their impact. Low-risk anomalies are typically isolated issues with limited impact, non-core, and without a tendency to spread. Medium-risk anomalies are typically performance degradation of core services or widespread failures of non-core services. High-risk anomalies are typically complete interruptions of core services, rapid propagation of faults, or large-scale concurrent service failures.

[0045] S143. Execute preset alarm decisions based on the category of the abnormal event. Specifically, the intelligent alarm decision system classifies abnormal events into alarm levels, such as low-risk, medium-risk, and high-risk anomalies. For low-risk anomalies, the alarm decision may be to only log the event. For medium-risk anomalies, the alarm decision is to notify relevant maintenance personnel for timely handling. For high-risk anomalies, the alarm decision is to immediately trigger high-priority alarms such as phone calls and SMS messages.

[0046] S144. Select an alarm notification channel based on the category of the abnormal event and send an alarm notification including alarm decision. Specifically, the intelligent multi-channel notification system selects an alarm notification channel based on the category of the abnormal event and sends the alarm notification information via email, instant messaging, and SMS. When the user receives the alarm information, they handle the abnormal event according to the alarm information. If the abnormal event has been handled, normal monitoring is restored. If the user does not select to receive alarm information or does not handle the abnormal event, and the preset handling time (e.g., handling within 1 day) is exceeded, the alarm level of the abnormal event is upgraded (e.g., a medium-risk abnormal event is upgraded to a high-risk abnormal event), and the alarm notification is resent.

[0047] S145. Collect feedback on alarm notification handling to optimize alarm decisions. Specifically, this involves acquiring user (e.g., operations and maintenance personnel) response times, handling actions (e.g., confirming receipt of alarm notification, reporting alarm notification as a false alarm, confirming alarm repair, and escalating the alarm level for the corresponding abnormal event), and qualitative evaluations. For alarms frequently marked as "false alarms," ​​the system can automatically analyze their triggering conditions (e.g., dynamic thresholds and aggregation rules) and suggest or automatically adjust relevant parameters (e.g., increasing the confidence factor k or extending the aggregation time window). Based on the deviation between the actual handling of alarms and the system's automatic alarm level classification, the weight coefficients of each dimension (service importance, dependency, etc.) in the impact of abnormal events are adjusted in reverse. The "confirmation response time" of alarms from different channels is analyzed to optimize channel selection strategies. For abnormal events that have been successfully handled and have clear root causes, the alarm event data is added to the alarm history database for subsequent abnormal pattern identification and root cause analysis.

[0048] In this way, when the aggregation result is unsuccessful, abnormal events are extracted from the aggregation result, enabling precise extraction of specific and actionable abnormal event items (such as "Service A HTTP 500 error" or "Database B response timeout") from the aggregated health check status conclusions. Abnormal events are categorized based on their impact, achieving intelligent grading. Pre-defined alarm decisions are executed based on the category of the abnormal event, implementing predefined, differentiated response strategies based on the classification results. Alarm notification channels are selected and alarm notifications, including alarm decisions, are sent according to the category of the abnormal event, ensuring that alarm notifications for urgent events are delivered while avoiding interference from non-urgent events. Feedback on the handling of alarm notifications is collected to optimize alarm decisions, enabling timely identification of shortcomings in the alarm strategy (such as high false alarm rates or slow response times), and automatic or assisted adjustment of relevant parameters and rules. Through this classification, the system can automatically and differentiately trigger different levels of alarms and response actions based on the quantitative assessment results of the impact level, thereby achieving accurate alarm classification and intelligent routing.

[0049] In one embodiment of this application, step S142 includes steps S1421 to S1425.

[0050] S1421. Obtain the target health check to which the abnormal event belongs, and assess the importance of the target health check in the business process to obtain service importance. Specifically, based on a predefined service classification strategy, determine the criticality level of the service (or component) corresponding to the target health check; assess the user impact range based on the user scope affected by the service (or component); assess its revenue correlation based on the correlation between the service (or component) and business revenue; and perform a weighted summation of the business criticality level, user impact range, and revenue correlation according to preset weights, and use the weighted summation value as the service importance score.

[0051] S1422. Calculate the dependency value of the target health check using the dependency graph among all health checks. Specifically, obtain all services corresponding to all health checks (e.g., HTTP health check corresponds to HTTP service, database health check corresponds to database service). In the preset service dependency graph, starting from the service node corresponding to the target health check, analyze the downstream dependency path of the service node; count the number of potentially affected direct and indirect downstream health checks as the breadth of fault propagation; determine the maximum number of dependency levels traversed from the starting point to the farthest affected node as the depth of fault propagation; and calculate the dependency value based on the breadth and depth according to the preset algorithm.

[0052] S1423. Calculate the propagation speed of abnormal events in the system, count the concurrent number of abnormal events occurring within the same time period, and calculate the duration of abnormal events. Specifically, monitor the number of related abnormal events triggered by abnormal events or newly generated through the service dependency graph within a unit of time; divide the number of related abnormal events by the unit of time to obtain the propagation speed. For example, if an abnormality occurs in the "cache health check," and the system detects 5 new downstream service abnormalities that depend on the cache service within the next minute, its propagation speed can be quantified as 5 per minute. Count the total number of all abnormal events that have not recovered within the system within the same statistical time window (e.g., the last 5 minutes) as the concurrency. Calculate the time elapsed from the first detection of an abnormal event to the current evaluation time as the duration. The longer the duration, the longer the system has been in an unhealthy state, and the greater its cumulative impact.

[0053] S1424. Take a weighted sum of at least two of the following: service importance, dependency value, propagation speed, concurrency, and duration. Use this weighted sum as the degree of influence. Specifically, normalize the values ​​of service importance, dependency value, propagation speed, concurrency, and duration before weighting and summing them. The weighted summation formula can be: Influence = w1 × Service Importance + w2 × Dependency Value + w3 × Propagation Speed ​​+ w4 × Concurrent Failures + w5 × Duration, where w1, w2, w3, w4, and w5 are configurable weight coefficients, and the sum of w1, w2, w3, w4, and w5 is 1. For example, if the abnormal event is "HTTP response time", after normalization, the HTTP service importance score is 80, the HTTP service dependency score is 75, the propagation speed score is 30 (the faster the propagation, the higher the score), the number of concurrent failures score is 90 (the larger the number of failures, the higher the score), and the duration score is 60 (the longer the duration, the higher the score). The values ​​of w1, w2, w3, w4, and w5 are 0.25, 0.20, 0.20, 0.20, and 0.15, respectively. According to the weighted summation formula, the impact value of "HTTP response time" is 68.

[0054] S1425. Based on the degree of impact, abnormal events are categorized into low-risk, medium-risk, or high-risk anomalies. Specifically, a first threshold and a second threshold are set, where the first threshold is less than the second threshold. If the impact value is lower than the first threshold, the abnormal event is classified as low-risk. If the impact value is not lower than the first threshold and is lower than the second threshold, the abnormal event is classified as medium-risk. If the combined impact value is not lower than the second threshold, the abnormal event is classified as high-risk. For example, if the impact value is 68, the first threshold is 40, and the second threshold is 70, the "HTTP response time" abnormal event is classified as medium-risk.

[0055] In this way, by identifying the target health check to which the anomaly belongs, the importance of the target health check in the business process is assessed to obtain service importance. Through multi-dimensional business value assessment of the services associated with the health check, technical anomalies are directly linked to business impact. The dependency value of the target health check is calculated using a dependency graph among all health checks. By analyzing the service dependency graph, the "breadth" (scope of impact) and "depth" (length of the impact chain) of the anomaly propagation are calculated, allowing the system to predict the chain reaction that an isolated technical failure may trigger. The propagation speed of the anomaly in the system, the number of concurrent anomalies occurring within the same time period, and the duration of the anomaly are calculated to capture the real-time evolution trend of the anomaly. At least two of the service importance, dependency value, propagation speed, concurrency, and duration are weighted and summed, and the weighted sum is used as the degree of impact. This enables the dynamic calculation of the quantitative value of the degree of impact based on dynamic indicators such as "propagation speed" and "duration," and categorizes anomalies into low-risk, medium-risk, or high-risk anomalies based on the degree of impact, achieving automated classification of anomalies.

[0056] In one embodiment of this application, step S143 includes steps S1431 to S1433.

[0057] S1431. When an abnormal event is a low-risk anomaly, the alarm decision to be executed is to record the abnormal event. For example, when a low-risk anomaly is detected, the abnormal event is only recorded in the system log without sending an alarm notification, and low-risk anomalies are continuously monitored.

[0058] S1432. When an abnormal event is classified as a medium-risk abnormality, the alarm decision is to aggregate the abnormal event according to a preset alarm merging mechanism and execute alarm operations based on the aggregation results. Specifically, when a medium-risk abnormality is detected, the system initiates the alarm aggregation process instead of immediately triggering an alarm notification for each abnormal event. The system merges and deduplicates eligible abnormal events according to the preset alarm merging mechanism, and finally executes subsequent alarm notification operations based on the aggregated abnormal events. For example, when a medium-risk abnormality is detected, the system checks whether the abnormal event is a duplicate alarm according to the preset alarm merging mechanism; for abnormal events that meet the alarm merging mechanism, an alarm notification is issued after merging; for non-duplicate alarm events, an alarm notification is sent directly; and for non-urgent alarms that are automatically suppressed within the predetermined maintenance time, and when downstream services have already issued alarms, related alarms from upstream services are suppressed.

[0059] S1433. When an abnormal event is classified as a high-risk anomaly, the alarm decision to be executed is to immediately perform the alarm operation. For example, when the system detects an abnormal event as a high-risk anomaly, it immediately sends an alarm notification through strong notification channels such as telephone, SMS, and regular notification channels such as WeChat Work, DingTalk work groups, or email to ensure that the alarm notification reaches its intended recipients.

[0060] In this way, when an anomaly is low-risk, the alerting decision is to record the anomaly. Minor anomalies that do not affect business continuity, have no risk of spreading, and can be self-healed or planned for handling (such as occasional single timeouts or momentary jitter in non-core services) are removed from the proactive notification stream, thus automatically filtering out anomalies that do not require user attention. When an anomaly is medium-risk, the alerting decision is to aggregate the anomaly according to a preset alert merging mechanism and execute alerting operations based on the aggregation results. Medium-risk anomalies are usually the first or ongoing manifestation of substantial problems requiring manual intervention. Through the "alert aggregation" mechanism, multiple alert events caused by the same root cause or with high similarity are merged into a single comprehensive alert within a short period of time, avoiding an "alert storm" caused by the same or similar types of anomalies. For example, a slow database query may cause dozens of APIs that depend on it to simultaneously alert, resulting in an "alert storm" of information bombardment. Furthermore, within a preset window, alerts for the same problem are only retained or notified once to avoid interference. When an abnormal event is classified as a high-risk anomaly, the alarm decision to be executed is to immediately perform the alarm operation. For high-risk anomalies that may cause business interruption, revenue loss, or serious user experience degradation, with the user's consent, high-intensity reminder channels such as telephone and SMS will be triggered in parallel, combined with regular channels, to ensure that alarm notifications for high-risk anomalies are effectively and timely delivered.

[0061] In one embodiment of this application, step S1432 includes steps S14321 to S14323.

[0062] S14321. Aggregate alarms generated consecutively within a preset time window for abnormal events belonging to the same health check. For example, aggregate alarms when the same health check task (such as an HTTP health check) reports consecutive failures within a short period of time. The system maintains a time window (e.g., 5 minutes) and uses the alarm's unique identifier (e.g., "Check ID: Service Name") as the aggregation key. When the check triggers an abnormal alarm for the first time, the system creates a record to be aggregated in the cache based on the unique identifier. Within the preset time window, if the same check (such as an HTTP health check) reports an abnormality again, the system will not generate a new independent alarm notification, but will update the statistical information of the aggregated record in the cache, such as adding the alarm occurrence count, recording the most recent occurrence time, and appending specific error details to the corresponding aggregated record in the cache. When a subsequent alarm notification is triggered (e.g., when the time window ends or the number of aggregates reaches a threshold), the system sends a comprehensive alarm containing the total number of alarms, the time range, and a list of error details based on the alarm's unique identifier.

[0063] S14322. Alarm aggregation is performed on alarms that affect or are associated with the same health check. Based on a predefined service dependency graph, the system identifies abnormal events arising from multiple different health checks belonging to the same service component or associated due to dependencies. For example, if a TCP health check fails due to the system's failure to establish a TCP connection with a target port on a target host, and subsequently, the "database health check" and "cache health check" that depend on this TCP connection also fail, these abnormal events are considered alarm-related events. According to preset aggregation rules (e.g., based on the service dependency graph), the system associates alarm events with a first aggregation group and generates a unique alarm identifier. The first aggregation group and the corresponding unique alarm identifier are pre-stored in a cache. The system merges all abnormal events within the first aggregation group in the cache into a single root cause-related alarm (e.g., the root cause of a "TCP health check" failure is a "TCP connection failure"). The root cause-related alarm not only lists all affected associated health check items (such as "database health check" and "cache health check"), but also indicates the dependencies between each health check item. When a subsequent alarm notification is triggered (such as when the number of aggregated alarms reaches a threshold), the system sends a root cause alarm based on the unique alarm identifier to help operations and maintenance personnel quickly locate the core problem.

[0064] S14323. Aggregate alarms for abnormal events with the same error mode or error code. For example, aggregate all alarms reporting "HTTP status code 503 (Service unavailable)". The system generates an aggregation key (e.g., "Error code: 503") for abnormal events with the same error mode or error code as a unique alarm identifier. Within the same statistical period (such as within a preset aggregation time window), all abnormal events matching the aggregation key will be grouped into a second aggregation group, and the second aggregation group and the corresponding unique alarm identifier will be stored in the cache. The system performs statistical summary on abnormal events belonging to the same aggregation group, generating an error summary alarm. The error summary alarm includes the total number of occurrences of the error mode (or error code), the first and last occurrence times, and all services that exhibit this error mode (or error code). When a subsequent alarm notification is triggered (such as when the number of aggregations reaches a threshold), the system sends an error summary alarm based on the unique alarm identifier, enabling operations and maintenance personnel to quickly identify a specific type of problem that is widespread throughout the system, facilitating batch processing or root cause investigation.

[0065] In this way, alarms generated consecutively within a preset time window by abnormal events belonging to the same health check are aggregated, alarms affecting or related to abnormal events of the same health check are aggregated, and alarms of abnormal events with the same error mode or error code are aggregated. Through alarm aggregation, "alarm storms" are effectively avoided.

[0066] In one embodiment of this application, reference is made to the appendix. Figure 5 Step S144 includes steps S1441 to S1443.

[0067] S1441. Alarm notification channels include email notifications, instant messaging, webhook notifications, and SMS notifications. Specifically, when an abnormal event is detected, the alarm system automatically sends the corresponding alarm notification to at least two of the following modules: email notification module, instant messaging module, webhook module, and SMS notification module. The email notification module automatically generates an alarm notification email and sends it to the mail server. The instant messaging module calls the API interface of an instant messaging tool (such as DingTalk robot or WeChat Work application) to send the formatted alarm notification to DingTalk robot or WeChat Work. The webhook module sends the alarm notification to the webhook endpoint via an HTTP POST request according to a pre-defined format (such as JSON). The SMS notification module calls the SMS gateway service to send the alarm notification to the SMS gateway.

[0068] S1442. When an abnormal event is classified as a medium-risk anomaly, at least two alarm notification channels should be selected to send alarm notifications. Specifically, when a medium-risk anomaly is detected, the system should issue a regular alarm, send an email notification, and send a Webhook notification.

[0069] S1443. When an abnormal event is classified as a high-risk anomaly, an alarm notification is sent through all alarm channels. Specifically, when a high-risk anomaly is detected, the system executes an emergency alarm policy and simultaneously sends email notifications, instant messaging notifications, Webhook notifications, and SMS notifications.

[0070] In this way, alert notifications are sent through various channels, including email, instant messaging, webhook, and SMS. When an event is classified as medium-risk, at least two channels are selected to send an alert notification; when an event is classified as high-risk, all channels are used to send an alert notification. By implementing different alert notification strategies based on the type of event, binding medium-risk events to selective notification channels and high-risk events to full-channel broadcasting, a strict positive correlation between communication intensity and event severity is ensured. By limiting the notification channels for medium-risk events, the frequency and level of interference of alerts are effectively controlled, reducing alert fatigue.

[0071] In one embodiment of this application, an alarm method based on multi-dimensional health checks is described, with reference to the appendix. Figure 6 It also includes steps H110 to H140: H110. Perform correlation analysis on each time series data obtained from step S131, calculate the correlation between different performance indicators, and obtain the correlation analysis results for each performance indicator. Specifically, analyze each time series data by calculating quantitative methods such as Pearson correlation coefficient or Spearman rank correlation coefficient to measure the strength of linear or monotonic relationships between different performance indicators, thereby identifying the first group of performance indicators that are numerically covariant. Analyze the change patterns of the time series data of each performance indicator on the time axis to identify the second group of performance indicators with leading and lagging relationships, for example, whether an abnormal rise in one performance indicator always leads a fall in another performance indicator. Based on a preset service dependency graph (such as a topology graph), combined with the above first and second performance indicator groups, simulate and analyze the potential propagation chain of the abnormal event along the path in the service dependency graph within the system, thereby helping to locate the original outbreak point of the abnormal event.

[0072] H120. The system utilizes pre-defined statistical methods or machine learning algorithms to identify abnormal monitoring data in each time series data set, obtaining abnormal pattern recognition results for each performance indicator. Specifically, it employs classic statistical anomaly detection methods, such as the "3σ rule" (e.g., considering data points deviating more than three standard deviations from the mean as anomalies) or "box plot method" (e.g., identifying outliers based on interquartile range). These methods identify statistically significant outliers based on the data distribution characteristics, thus identifying outliers in each time series data set. Machine learning anomaly detection algorithms are employed, such as "Isolation Forest" or "Support Vector Machine," unsupervised learning methods. These machine learning algorithms can learn the feature distribution of normal data, thereby identifying abnormal performance characteristics and anomaly patterns that do not conform to the distribution of each time series data set, without the need for pre-labeling of abnormal samples. The system maintains an alarm history database containing the abnormal performance characteristics of each performance indicator when historical anomaly events occur. When a current anomaly event is detected, the system compares its abnormal performance characteristics with the anomaly event records in the alarm history database. If a match is found, it can be quickly identified as a known type of anomaly event, accelerating root cause localization.

[0073] H130. Based on the correlation analysis results and anomaly pattern recognition results of each performance indicator, analyze the causal relationship between anomalous events using a pre-defined causal inference model. The causal inference model is at least one of the Granger causality test method or a Bayesian network model, or a custom causal inference model can be defined. Specifically, the Granger causality test method is applied to examine the causal relationship between two time series to determine whether the change in one time series has predictive power for the other. The Granger causality test is a prediction-based time series analysis method that infers whether the past value of one time series helps predict the future value of another time series by examining whether the former (e.g., anomalous event A) is a "Granger cause" of the latter (anomalous event B), i.e., inferring the causal relationship between the former and the latter, for example, anomalous event A is a Granger cause of anomalous event B. A Bayesian network model is constructed to calculate the conditional probabilities between different anomalous events based on historical monitoring data, and to infer the most likely root cause event. The Bayesian network model is a probabilistic graphical model that can learn the conditional probabilistic dependencies between different events (variables) based on historical data. When an anomalous event occurs, the system can use the Bayesian network model to calculate the posterior probability of each anomalous event as the root cause, given a series of anomalies observed in each time series data, thereby identifying the most likely root cause. Furthermore, a custom causal graphical model can be built to identify causal relationships and root causes between anomalous events through intervention analysis (e.g., simulating forced changes to the value of a certain data point) and counterfactual reasoning (e.g., exploring "what would have happened if a certain event had not occurred").

[0074] H140. Based on the correlation analysis results, anomaly pattern recognition results, and causal relationships, calculate the root cause probability, determine and output a report of the root causes of all anomaly events. (See appendix) Figure 7 Specifically, the system assigns an initial base probability value (e.g., 0.0) to each identified candidate root cause that may lead to all current anomalous events. If the performance metric corresponding to a candidate root cause shows a very high statistical correlation with the performance metrics corresponding to multiple other anomalous events (e.g., Pearson correlation coefficient > 0.8), the base probability value of the candidate root cause is increased to the first probability value. If a causal inference model (e.g., Granger causality test or Bayesian network) provides strong causal support for the candidate root cause (e.g., anomalous event A statistically significantly “Granger-induced” a series of subsequent key metric anomalies), the base probability value of the candidate root cause is increased to the second probability value. If the currently observed anomalous pattern highly matches the pattern of a known root cause in the historical fault database, the base probability value of the candidate root cause is increased to the third probability value based on the frequency of that known root cause or successful diagnosis records. Combined with the service dependency graph, candidate root causes at the source of the dependency chain and with a wide impact range have a higher probability value than downstream nodes. The system uses a preset weighted synthesis algorithm to comprehensively calculate the first, second, and third probability values ​​of each candidate root cause, obtaining the final probability value for each candidate root cause. Finally, it generates a normalized root cause probability (e.g., a value between 0 and 1, or expressed as a percentage) for each candidate root cause. Based on the root cause probabilities, the system selects root causes exceeding a preset probability threshold to generate a root cause report.

[0075] In this manner, correlation analysis is performed on each time-series data obtained from step S131 to calculate the correlation between different performance indicators, obtain the correlation analysis results for each performance indicator, calculate the correlation between different monitoring indicators using statistical methods such as Pearson correlation coefficient and Spearman rank correlation, analyze the time-series patterns of indicator changes, identify leading and lagging indicators to construct a service dependency graph between services (or components), and analyze the propagation path of abnormal events to obtain the static relationships between abnormal events. Pre-set statistical methods or machine learning algorithms are used to identify abnormal monitoring data for each time-series data, obtain the abnormal pattern identification results for each performance indicator, identify statistically significant outliers using methods such as the 3σ principle and box plots, apply unsupervised learning algorithms such as Isolation Forest and One-Class SVM to detect abnormal patterns, and match the current abnormal pattern with the alarm history database to discover dynamic deviations of abnormal events. Based on the correlation analysis and anomaly pattern recognition results of each performance indicator, a pre-defined causal inference model is used to analyze the causal relationships between abnormal events, examine the causal relationships between time series, determine whether one time series has predictive power for another, construct a Bayesian network model to calculate the conditional probabilities between different failure events, and use a causal graph to represent the causal relationships between variables. Root causes are identified through intervention and counterfactual reasoning to clarify the propagation direction of abnormal events. Based on the correlation analysis results, anomaly pattern recognition results, and causal relationships, root cause probabilities are calculated, and a report on the root cause of all abnormal events is determined and output. This achieves the ability to accurately locate the initial source node (i.e., the root cause) in a complex network of abnormal event relationships by comprehensively integrating correlation analysis, anomaly pattern recognition, and causal inference.

[0076] In one embodiment of this application, before step H110, the method further includes: obtaining alarm event data, historical monitoring data, and real-time monitoring data from the alarm history database, monitoring database, and time series database, respectively; and preprocessing the alarm event data, historical monitoring data, and real-time monitoring data using a preset data cleaning method, such as supplementing null values ​​in the data, deleting duplicate data records, and normalizing the data.

[0077] In this way, by cleaning alarm event data, historical monitoring data, and real-time monitoring data, defects in the original data (such as missing data and obvious outliers) are repaired to generate a standardized data stream, thereby improving the accuracy of subsequent root cause analysis.

[0078] Please refer to Figure 8The present invention also provides an electronic device 300, including a memory 301 and a processor 302, and a computer program stored on the memory 301 and running on the processor 302. When the processor 302 executes the computer program, it implements the various steps of the alarm method based on multi-dimensional health check as described above.

[0079] The beneficial effects of the electronic device of the present invention are the same as those of the method described above, and will not be repeated here.

[0080] In summary, this application performs HTTP health checks, database health checks, cache health checks, TCP health checks, command health checks, and custom health checks. By aggregating multi-dimensional health check results and calculating dynamic thresholds for performance indicators based on historical health check results for each dimension, it obtains abnormal events for each dimension and determines whether performance indicators are normal based on dynamic thresholds. This enables comprehensive health status monitoring of different types of services, improving the accuracy of system health status assessment. Based on the classification of abnormal events in the aggregated results, it automatically executes alarm decisions to send alarm notifications and optimizes alarm decisions through feedback on alarm notification handling, thereby improving the accuracy and timeliness of abnormal monitoring of system services.

[0081] The above are merely embodiments of the present invention and do not limit the patent scope of the present invention. Any equivalent modifications made based on the content of the present invention's specification and drawings, or direct or indirect applications in related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. An alarm method based on multi-dimensional health checks, characterized in that, Applied to the server side, the method includes: Get a system status check request; Perform at least two of the following health checks: HTTP health check, database health check, cache health check, TCP health check, command health check, and custom health check, and obtain multiple check results; The multiple inspection results are aggregated to obtain an aggregated result; Alarm decisions are made based on the aggregation results.

2. The alarm method based on multi-dimensional health check according to claim 1, characterized in that, The aggregated results from the multiple inspections result include: Historical inspection data of preset performance indicators are collected from the historical data of the multiple inspection results to form time series data; Based on the time series data, the exponentially weighted moving average of the performance index at the current moment is calculated using the exponentially weighted moving average algorithm. Based on the time series data, calculate the standard deviation of the historical data for the performance indicator; Based on the exponentially weighted moving average and the standard deviation, the dynamic threshold of the performance index is calculated according to a preset algorithm; Based on the judgment result of whether the actual observed value of the performance index meets the preset dynamic threshold, the judgment result of the dynamic threshold and multiple inspection results are aggregated to obtain an aggregated result.

3. The alarm method based on multi-dimensional health check according to claim 2, characterized in that, The step of calculating the exponentially weighted moving average of the performance indicator at the current moment using the exponentially weighted moving average algorithm based on the time series data includes: EWMA(t) = α× x(t) + (1 - α) × EWMA(t-1); Wherein, EWMA(t) is the exponentially weighted moving average of the performance index at the current time t, α is the smoothing factor, x(t) is the actual observed value of the performance index at the current time t, and EWMA(t-1) is the exponentially weighted moving average of the performance index at the previous time t-1.

4. The alarm method based on multi-dimensional health check according to claim 2, characterized in that, The aggregated result obtained by aggregating the judgment result of the dynamic threshold and multiple inspection results includes: If any one of the multiple check results is "fail", the aggregated result is "fail". If the actual observed value of any of the performance indicators does not meet the preset dynamic threshold condition, the aggregation result is "not passed". When all the inspection results in the plurality of inspection results pass and the actual observed values ​​of all the performance indicators meet the preset dynamic threshold conditions, the aggregate result is passed.

5. The alarm method based on multi-dimensional health check according to claim 1, characterized in that, Executing alarm decisions based on the aggregation results includes: When the aggregation result is unsuccessful, an exception event is obtained from the aggregation result; The alarm classification is performed based on the degree of impact of the abnormal event to obtain the category of the abnormal event; Execute a preset alarm decision based on the category of the abnormal event; Select an alarm notification channel based on the category of the abnormal event and send an alarm notification that includes the alarm decision; Collect feedback on the handling of the alarm notifications and optimize the alarm decision-making.

6. The alarm method based on multi-dimensional health check according to claim 5, characterized in that, The alarm classification based on the impact of the abnormal event yields the following categories: Obtain the target health check to which the abnormal event belongs, and assess the importance of the target health check in the business process to obtain service importance; The dependency value of the target health examination is calculated using a dependency graph among all health examinations. Calculate the propagation speed of the abnormal event in the system, count the concurrent number of the abnormal events occurring within the same time period, and calculate the duration of the abnormal event; The influence level is determined by weighted summation of at least two of the following factors: service importance, dependency value, propagation speed, concurrency, and duration. The abnormal events are classified into low-risk, medium-risk, or high-risk anomalies based on the degree of impact.

7. The alarm method based on multi-dimensional health check according to claim 5, characterized in that, Executing preset alarm decisions based on the category of the abnormal event includes: When the abnormal event is a low-risk abnormality, the alarm decision to be executed is to record the abnormal event; When the abnormal event is a medium-risk abnormality, the alarm decision to be executed is to aggregate the alarms of the abnormal event according to the preset alarm merging mechanism, and to execute the alarm operation according to the alarm aggregation result. When the abnormal event is a high-risk abnormality, the alarm decision to be executed is to immediately execute the alarm operation.

8. The alarm method based on multi-dimensional health check according to claim 7, characterized in that, The alarm aggregation of the abnormal events according to the preset alarm merging mechanism includes: Alarms generated consecutively within a preset time window for abnormal events belonging to the same health check are aggregated. Alarms for abnormal events that affect or are related to the same health check will be aggregated. Alarms for the exception events that have the same error mode or error code are aggregated.

9. The alarm method based on multi-dimensional health check according to claim 5, characterized in that, Selecting an alarm notification channel and sending an alarm notification based on the category of the abnormal event includes: The alarm notification channels include email notifications, instant messaging, webhook notifications, and SMS notifications; When the abnormal event is a medium-risk abnormality, at least two alarm notification channels shall be selected from the alarm notification channels to send the alarm notification; When the abnormal event is a high-risk abnormality, the alarm notification is sent through all the alarm channels.

10. An electronic device comprising a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that, When the processor executes the computer program, it implements each step of the alarm method based on multi-dimensional health check as described in any one of claims 1 to 9.

Images