Intelligent application health monitoring method and apparatus, computer device, and storage medium

Abstract

The application discloses a kind of intelligent application health monitoring method, device and medium, the method includes: starting health monitoring process reads preset configuration parameter, creates corresponding health state queue for each target application according to preset configuration parameter, and records recent reporting timestamp, the preset configuration parameter includes fatal level threshold, maximum historical number, time window length, timeout threshold and warning threshold and serious abnormal threshold of times / time dimension;Receive the current health state uploaded by each target application through health reporting component, the current health state includes discrete level, text description and reporting timestamp;According to current health state, update recent reporting timestamp, and utilize preset configuration parameter to judge the health condition of target application.The application can comprehensively multidimensional index, real-time evaluation application health state, and can be linked with quick recovery mechanism, to improve application high availability and realize quick failure perception and recovery.

Description

Technical Field

[0001] This invention relates to a smart application health monitoring method, device, computer equipment, and storage medium, belonging to the field of application high availability and automatic fault recovery technology. Background Technology

[0002] Existing application health monitoring and recovery technologies mainly employ two approaches: 1) Watchdog solutions based on timed active "feeding" signals. These solutions typically involve the application sending a "heartbeat" or "feeding" signal to the watchdog program at fixed time intervals. If the signal is not sent within the specified time, the application is deemed abnormal and restarted or switched over. This method relies on a fixed time period for monitoring granularity and cannot adaptively adjust to business load and application characteristics. It may fail to trigger recovery even when the application is clearly abnormal, or it may be mistakenly identified as abnormal and restarted incorrectly during brief application fluctuations. 2) Passive process monitoring methods, such as using process monitoring tools like Supervisor and pmon2. These solutions generally rely on process existence and exit codes for fault diagnosis, lacking the ability to perceive fine-grained operational states such as internal business metrics, thread states, and resource usage. Therefore, they cannot accurately reflect the true health status of the application.

[0003] The above-mentioned technical solutions generally have the following problems: 1) The monitoring granularity cannot be precisely controlled, mainly relying on fixed time intervals and simple rules, lacking the ability to adapt to load changes, business peaks, and application characteristics; 2) It is impossible to obtain the actual health status of the application, and most of them only focus on "whether it is alive or not" (whether the process is present or not, whether the port is present) while ignoring key indicators such as business response time, error rate, internal queue backlog, and thread pool exhaustion; 3) Fault detection is lagging, usually requiring several seconds or even longer to determine anomalies, making it difficult to meet the needs of millisecond or sub-second fault recovery; 4) The false positive rate is high. In high-load or instantaneous jitter scenarios, the application itself may not have a fatal fault, but may be mistakenly killed due to short-term slowdown or instantaneous timeout, thereby causing a wider range of service instability and decreased availability.

[0004] Therefore, there is an urgent need for an intelligent monitoring method that can comprehensively assess the health status of applications in real time by integrating multi-dimensional indicators and can be linked with a rapid recovery mechanism to improve application high availability and achieve rapid fault detection and recovery. Summary of the Invention

[0005] In view of this, the present invention provides an intelligent application health monitoring method, device, computer equipment and storage medium, which can comprehensively evaluate the health status of applications in real time based on multi-dimensional indicators, and can be linked with a rapid recovery mechanism to improve application high availability and achieve rapid fault detection and recovery.

[0006] The first objective of this invention is to provide a smart application health monitoring method.

[0007] The second objective of this invention is to provide an intelligent application health monitoring device.

[0008] A third objective of this invention is to provide a computer device.

[0009] A fourth objective of this invention is to provide a computer-readable storage medium.

[0010] The first objective of this invention can be achieved by adopting the following technical solution:

[0011] A smart application health monitoring method, the method comprising:

[0012] The health monitoring process is started to read the preset configuration parameters. According to the preset configuration parameters, a corresponding health status queue is created for each target application, and the most recent reporting timestamp is recorded. The preset configuration parameters include the fatality level threshold, the maximum number of historical entries, the time window length, the timeout threshold, and the warning threshold and the severe anomaly threshold in the number / time dimension.

[0013] Receive the current health status uploaded by each target application through the health reporting component. The current health status includes discrete levels, text descriptions, and reporting timestamps.

[0014] Based on the current health status, update the most recently reported timestamp and use preset configuration parameters to determine the health status of the target application.

[0015] Furthermore, the step of judging the health status of the target application using preset configuration parameters includes:

[0016] If the discrete level is greater than or equal to the critical level threshold, the target application is judged as a serious anomaly and a fault event is generated; otherwise, the current health status is appended to the corresponding health status queue, and the earliest record at the head of the queue is removed when the queue length exceeds the maximum number of historical records.

[0017] Based on the timer, the difference between the current time and the most recently reported timestamp of each target application is checked periodically. If the difference is greater than the timeout threshold, the target application is regarded as having a timeout exception, and a fault event is generated according to the critical level threshold processing logic.

[0018] For the health status queue, calculate the first-level cumulative sum of the most recent L records and the second-level cumulative sum of records within the time window [t-N, t] at the current time. Based on the first-level cumulative sum and the second-level cumulative sum, judge the health status of the target application, where t is the current time, L = min(M, n), M is the maximum number of historical records, N is the time window length, and n is the queue length.

[0019] Furthermore, the step of judging the health status of the target application based on the first-level cumulative sum and the second-level cumulative sum includes:

[0020] If either the first-level cumulative sum is greater than or equal to the severe anomaly threshold in the frequency dimension or the second-level cumulative sum is greater than or equal to the severe anomaly threshold in the time dimension, the target application will be judged as severely anomaly, and a preset rapid recovery strategy will be triggered based on the fault event.

[0021] If either the first-level cumulative sum is less than the severe abnormality threshold of the frequency dimension but greater than or equal to the warning threshold of the frequency dimension, or the second-level cumulative sum is less than the severe abnormality threshold of the time dimension but greater than or equal to the warning threshold of the time dimension, then the target application will be judged as sub-healthy.

[0022] If the cumulative sum of the first level is less than the warning threshold of the number dimension, and the cumulative sum of the second level is less than the warning threshold of the time dimension, then the target application is judged as healthy.

[0023] Furthermore, the preset fast recovery strategy includes at least one of the following operations:

[0024] Restart the target application using a process management tool or container orchestration platform;

[0025] New request traffic is switched to other healthy instances via load balancing or service discovery components;

[0026] Execute state recovery scripts to restore critical business states from snapshots, caches, or message queues.

[0027] Furthermore, the health reporting component reports the current health status in at least one of the following scenarios:

[0028] When the target application completes a critical task or request without any exceptions, it reports its current health status with a discrete level of 0.

[0029] When a short-term high load is detected that causes some requests to time out, a text description containing an exception is reported, as well as the current health status with a discrete level of 10 is reported.

[0030] When it is detected that a resource is continuously occupied for a predetermined period of time but may still be recoverable, a text description containing an anomaly is reported, as well as a health status with a discrete level of 20 is reported.

[0031] When a thread deadlock, critical module crash, or other fatal error that requires an immediate restart to recover is detected, a text description containing an exception description is reported, along with a health status with a discrete level equal to the fatal level threshold.

[0032] Furthermore, when the target application determines that an exception is caused by an external dependency and restarting itself cannot resolve the issue, it reports a text description containing the exception information and the current health status with a discrete level of 0 through the health reporting component.

[0033] Furthermore, the method also includes:

[0034] Within a preset time period, statistically analyze the correspondence between early warning events, fault events, and actual fault conditions;

[0035] Based on the statistically obtained false alarm and missed alarm counts, at least one of the following should be adjusted: the warning threshold for the frequency dimension, the warning threshold for the time dimension, the severe anomaly threshold for the frequency dimension, the severe anomaly threshold for the time dimension, the maximum number of historical records, the time window length, and the timeout threshold.

[0036] The second objective of this invention can be achieved by adopting the following technical solution:

[0037] A smart application health monitoring device, the device comprising:

[0038] The health status queue creation module is used to start the health monitoring process, read the preset configuration parameters, create a corresponding health status queue for each target application according to the preset configuration parameters, and record the most recent reporting timestamp. The preset configuration parameters include the fatality level threshold, the maximum number of historical entries, the time window length, the timeout threshold, and the warning threshold and the severe anomaly threshold in the number / time dimension.

[0039] The health status receiving module is used to receive the current health status uploaded by each target application through the health reporting component. The current health status includes discrete levels, text descriptions, and reporting timestamps.

[0040] The health status assessment module is used to update the most recently reported timestamp based on the current health status and to assess the health status of the target application using preset configuration parameters.

[0041] The third objective of this invention can be achieved by adopting the following technical solution:

[0042] A computer device includes a processor and a memory for storing a processor-executable program, wherein when the processor executes the program stored in the memory, it implements the above-described intelligent application health monitoring method.

[0043] The fourth objective of this invention can be achieved by adopting the following technical solution:

[0044] A computer-readable storage medium storing a program that, when executed by a processor, implements the above-described intelligent application health monitoring method.

[0045] The present invention has the following advantages over the prior art:

[0046] 1. The present invention is simple to implement but covers a wide range of dimensions. The application side only needs to perform a simple level mapping on the existing monitoring indicators, and the monitoring side only needs to maintain the queue and threshold to simultaneously cover multiple anomalies such as fatal errors, short-term jitter, long-term trends and timeouts.

[0047] 2. The monitoring granularity and sensitivity of this invention can be quantitatively adjusted. By adjusting parameters such as the lethality threshold, maximum number of historical records, time window length, timeout threshold, and warning threshold and severe anomaly threshold in the number / time dimension, the sensitivity to anomalies can be adjusted in both the number of records and time dimensions to meet the different trade-offs between false alarms and missed alarms in different business scenarios.

[0048] 3. The anomaly detection logic of this invention is transparent, and the status determination is based entirely on explicit formulas and inequalities. The rules are clear, highly readable, and easy for operation and maintenance personnel to understand, review, and adjust.

[0049] 4. This invention can be closely linked with a rapid recovery mechanism. Once the severe anomaly judgment conditions are met, it will immediately drive actions such as restart, traffic switching and state recovery, thereby shortening the fault recovery time.

[0050] 5. This invention is easy to implement and extend in engineering, does not depend on a specific language or framework, can be accessed through SDK or Sidecar, and is suitable for various forms such as single-machine applications, microservices and containerized clusters. Attached Figure Description

[0051] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the structures shown in these drawings without creative effort.

[0052] Figure 1 This is a schematic diagram of the system architecture of the intelligent application health monitoring method of Embodiment 1 of the present invention.

[0053] Figure 2 This is a flowchart of the intelligent application health monitoring method of Embodiment 1 of the present invention.

[0054] Figure 3 This is a schematic diagram of the multidimensional health status assessment model of Embodiment 1 of the present invention.

[0055] Figure 4 This is a schematic diagram illustrating the linkage between health events and rapid recovery in Embodiment 1 of the present invention.

[0056] Figure 5 This is a schematic diagram of the application restart determination process based on the health status queue in Embodiment 1 of the present invention.

[0057] Figure 6 This is a structural block diagram of the intelligent application health monitoring device according to Embodiment 2 of the present invention.

[0058] Figure 7 This is a structural block diagram of the computer device according to Embodiment 3 of the present invention. Detailed Implementation

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

[0060] Example 1:

[0061] Traditional solutions based on timed "dog-feeding" or passive process monitoring cannot accurately obtain the true health status of applications, leading to delayed or misjudged application fault detection and hindering rapid and reliable fault recovery. Therefore, this embodiment provides an intelligent application health monitoring method. This method allows applications to report their health status in discrete levels, maintains a sliding queue and time window on the monitoring end, and uses direct summation and threshold judgment rules to quantify and classify application status. This approach is easy to implement and optimize in engineering. The method is deployed on a host, container, or compute node running one or more target applications. This embodiment is applied to a compute node running multiple target applications, revolving around a resident health monitoring process, Hmon. Figures 1-5 As shown, it includes the following steps:

[0062] S201. Start the health monitoring process, read the preset configuration parameters, create a corresponding health status queue for each target application according to the preset configuration parameters, and record the most recent reporting timestamp.

[0063] This embodiment registers the health monitoring process Hmon as a system-level service in the operating system's service management component (e.g., systemd, init scripts, or container orchestration platforms under Linux, or Windows Services / Service Control Manager under Windows). The health monitoring process Hmon is started as a system-level service, reading preset configuration parameters from a configuration file or configuration center. Based on these parameters, a corresponding health status queue Q_app is created for each target application (app), and the most recent reporting timestamp lastTime[app] is recorded (lastTime[app] is automatically written with the first report and updated with each report). The preset configuration parameters may include a fatality level threshold, a maximum number of historical entries, a time window length, a timeout threshold, and warning thresholds and severe anomaly thresholds based on the number of occurrences / time dimension.

[0064] The fatality threshold is represented by L_fatal, and its value can be set to 100;

[0065] The maximum number of historical records is represented by M, which is the maximum number of historical records to be considered when counting by number of times, and can be used as a queue length threshold.

[0066] The time window length is represented by N, which is the length of the time window (in seconds) considered when performing statistics by time.

[0067] The timeout threshold is represented by T_timeout, which is the threshold (in seconds) for the target application to fail to report within the timeout period.

[0068] The warning threshold for the frequency dimension is represented by C_warn, which is the warning threshold based on the frequency.

[0069] The severity threshold for the frequency dimension is denoted by C_crit, which is the severity threshold for frequency-based statistics.

[0070] The warning threshold for the time dimension is represented by T_warn, which is the warning threshold calculated based on time.

[0071] The severe anomaly threshold in the time dimension is represented by T_crit, which is the severe anomaly threshold statistically calculated over time.

[0072] S202. Receive the current health status uploaded by each target application through the health reporting component.

[0073] In this embodiment, the target application loads the SDK or Agent upon startup, establishes an inter-process communication channel with Hmon, and calls the reporting interface `report_health(level, status)` in a critical branch. The target application maps the running results to discrete `level` values ​​based on its collected process-level, service-level, and business-level metrics. Specifically, a health reporting component is embedded in each target application. This component generates a health status structure `hs_k = (level_k, status_k, time_k)` when predetermined trigger conditions are met, based on multi-dimensional metrics collected within the application. This structure serves as the current health status and is reported to Hmon. Here, `level_k` represents a discrete level, ranging from 0 to 100. This value is an integer; a larger value indicates a worse health status. 0 represents normal or information level, and L_fatal represents a fatal exception. `status_k` is a text description describing the exception, including the cause or triggering scenario. `time_k` is a reporting timestamp, used to record the reporting time.

[0074] Furthermore, the health reporting component reports the current health status in at least one of the following scenarios:

[0075] 1) When the target application completes a critical task or request without any exceptions, report the current health status with a discrete level of 0;

[0076] 2) When a short-term high load is detected causing some requests to time out, report a text description containing an exception explanation, and report the current health status with a discrete level of 10.

[0077] 3) When it is detected that a resource is continuously occupied for a predetermined period of time but may still be recoverable, report a text description containing an anomaly, and report a health status with a discrete level of 20.

[0078] 4) When a thread deadlock, critical module crash, or other fatal error that requires immediate restart to recover is detected, report a text description containing an exception description, and report the health status with a discrete level of the fatal level threshold L_fatal.

[0079] S203. Based on the current health status, update the most recently reported timestamp and use preset configuration parameters to determine the health status of the target application.

[0080] In this embodiment, when the health monitoring process Hmon receives the current health status hs_k from the target application app, it updates lastTime[app] to time_k.

[0081] Furthermore, the assessment of the health status of the target application using preset configuration parameters specifically includes:

[0082] S2031. If the discrete level is greater than or equal to the fatal level threshold, i.e., level_k≥L_fatal, the target application is judged as a serious anomaly and a fault event is generated. Otherwise, i.e., level_k<L_fatal, the current health status is appended to the corresponding health status queue, and the earliest record at the head of the queue is removed when the queue length exceeds the maximum number of historical records M.

[0083] S2032. Based on the timer, periodically check the difference between the current time t and the most recently reported timestamp of each target application, i.e., Δt_timeout(app) = t - lastTime[app]. If the difference is greater than the timeout threshold, i.e. Δt_timeout(app) > T_timeout, then the target application is regarded as having a timeout exception, and a fault event is generated according to the fatal level threshold processing logic.

[0084] S2033. For the health status queue Q_app, at the current time t, calculate the first-level cumulative sum of the most recent L records and the second-level cumulative sum of the records within the time window [t-N, t]. Based on the first-level cumulative sum and the second-level cumulative sum, judge the health status of the target application, where L = min(M, n), M is the maximum number of historical records, N is the time window length, and n is the queue length.

[0085] Furthermore, based on the sum of the first and second levels, the health status of the target application is assessed, specifically including:

[0086] 1) If either the first-level cumulative sum is greater than or equal to the severe anomaly threshold in the number dimension (i.e., sumCount(app,t)≥C_crit) or the second-level cumulative sum is greater than or equal to the severe anomaly threshold in the time dimension (sumTime(app,t)≥T_crit), the target application is judged as severely anomaly, and a preset fast recovery strategy is triggered based on the fault event.

[0087] The preset fast recovery strategy includes at least one of the following operations:

[0088] Restart the target application using a process management tool or container orchestration platform;

[0089] New request traffic is switched to other healthy instances via load balancing or service discovery components;

[0090] Execute state recovery scripts to restore critical business states from snapshots, caches, or message queues.

[0091] 2) If either the first-level cumulative sum is less than the severe anomaly threshold of the frequency dimension and greater than or equal to the warning threshold of the frequency dimension (i.e., C_warn≤sumCount(app,t)<C_crit) or the second-level cumulative sum is less than the severe anomaly threshold of the time dimension and greater than or equal to the warning threshold of the time dimension (i.e., T_warn≤sumTime(app,t)<T_crit) is true, then the target application is judged to be in a sub-healthy state.

[0092] 3) If the cumulative sum of the first level is less than the warning threshold of the number dimension (i.e., sumCount(app,t) < C_warn) and the cumulative sum of the second level is less than the warning threshold of the time dimension (i.e., sumTime(app,t) < T_warn) are both true, that is, if neither 1) nor 2) above are true, then the target application is judged as healthy.

[0093] Based on the above status classification, the health monitoring process Hmon can generate three types of health events:

[0094] Healthy heartbeat event: When the status is healthy, it is reported in a low frequency and is used for display on the monitoring platform;

[0095] Warning event: When the status is sub-healthy, report sumCount, sumTime and several status descriptions to remind the operation and maintenance or automation system to perform preventive measures, such as capacity expansion, rate limiting, and degradation.

[0096] Fault event: When the status is critically abnormal, the application identifier, triggering conditions and necessary context are reported to drive automatic recovery.

[0097] Furthermore, the intelligent application health monitoring method of this embodiment may also include:

[0098] Within a preset time period, statistically analyze the correspondence between warning events, fault events, and actual fault conditions; based on the statistically obtained false alarms and missed alarms, adjust at least one of the following: warning threshold C_warn (frequency dimension), warning threshold T_warn (time dimension), severe anomaly threshold C_crit (frequency dimension), severe anomaly threshold T_crit (time dimension), maximum number of historical records M, time window length N, and timeout threshold T_timeout.

[0099] With the above approach, the method in this embodiment only needs to report discrete health levels by setting points according to the scenario on the application side. On the monitoring side, health measurement and classification can be completed by comparing simple queue summation formulas and inequalities. This avoids the cost of implementing complex models and is easy to implement and optimize in engineering.

[0100] It should be noted that although the above-described method operations are depicted in a specific order in the accompanying drawings, this does not require or imply that these operations must be performed in that specific order, or that all of the illustrated operations must be performed to achieve the desired result. On the contrary, the order of execution of the depicted steps can be changed. Additionally or alternatively, certain steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps.

[0101] Example 2:

[0102] like Figure 6 As shown, this embodiment provides an intelligent application health monitoring device, which includes a health status queue creation module 601, a health status receiving module 602, and a health status judgment module 603. The specific functions of each module are as follows:

[0103] The health status queue creation module 601 is used to start the health monitoring process, read the preset configuration parameters, create a corresponding health status queue for each target application according to the preset configuration parameters, and record the most recent reporting timestamp. The preset configuration parameters include the fatality level threshold, the maximum number of historical entries, the time window length, the timeout threshold, and the warning threshold and the severe anomaly threshold in the number / time dimension.

[0104] The health status receiving module 602 is used to receive the current health status uploaded by each target application through the health reporting component. The current health status includes discrete level, text description and reporting timestamp.

[0105] The health status judgment module 603 is used to update the most recently reported timestamp based on the current health status and to judge the health status of the target application using preset configuration parameters.

[0106] The specific implementation of each module in this embodiment can be found in Embodiment 1 above, and will not be repeated here. It should be noted that the device provided in this embodiment is only illustrated by the division of the above functional modules. In practical applications, the above functions can be assigned to different functional units as needed, that is, the internal structure can be divided into different functional units to complete all or part of the functions described above.

[0107] Example 3:

[0108] This embodiment provides a computer device, such as... Figure 7As shown, it includes a processor 702, a memory, an input device 703, a display device 704, and a network interface 705 connected via a device bus 701. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium 706 and internal memory 707. The non-volatile storage medium 706 stores operating devices, computer programs, and a database. The internal memory 707 provides an environment for the operation of the operating devices and computer programs in the non-volatile storage medium. When the processor 702 executes the computer program stored in the memory, it implements the intelligent application health monitoring method of Embodiment 1 described above, as follows:

[0109] The health monitoring process is initiated by reading preset configuration parameters. Based on these parameters, a corresponding health status queue is created for each target application, and the most recent reporting timestamp is recorded. The preset configuration parameters include a fatality level threshold, a maximum number of historical entries, a time window length, a timeout threshold, and warning thresholds and severe anomaly thresholds based on the frequency / time dimension. The process receives the current health status uploaded by each target application through the health reporting component. The current health status includes a discrete level, a text description, and a reporting timestamp. Based on the current health status, the most recent reporting timestamp is updated, and the health status of the target application is judged using the preset configuration parameters.

[0110] Example 4:

[0111] This embodiment provides a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it implements the intelligent application health monitoring method of Embodiment 1 above, as follows:

[0112] The health monitoring process is initiated by reading preset configuration parameters. Based on these parameters, a corresponding health status queue is created for each target application, and the most recent reporting timestamp is recorded. The preset configuration parameters include a fatality level threshold, a maximum number of historical entries, a time window length, a timeout threshold, and warning thresholds and severe anomaly thresholds based on the frequency / time dimension. The process receives the current health status uploaded by each target application through the health reporting component. The current health status includes a discrete level, a text description, and a reporting timestamp. Based on the current health status, the most recent reporting timestamp is updated, and the health status of the target application is judged using the preset configuration parameters.

[0113] It should be noted that the computer-readable storage medium in this embodiment can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. The computer-readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof.

[0114] In this embodiment, the computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in connection with an instruction execution system, apparatus, or device. In this embodiment, the computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying a computer-readable program. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. The computer-readable signal medium can also be any computer-readable storage medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The computer program contained on the computer-readable storage medium can be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (radio frequency), etc., or any suitable combination thereof.

[0115] The computer-readable storage medium described above can be used to write computer programs for executing this embodiment in one or more programming languages ​​or combinations thereof. These programming languages ​​include object-oriented programming languages—such as Java, Python, and C++—and conventional procedural programming languages—such as C or similar programming languages. The program can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0116] In summary, this invention can comprehensively evaluate the health status of applications in real time by integrating multi-dimensional indicators, and can be linked with a rapid recovery mechanism to improve application high availability and achieve rapid fault detection and recovery. Its rules are clear, its implementation is simple, and it is easy to implement in online services, cloud-native applications, and distributed systems. Furthermore, by adjusting thresholds and window parameters, it can meet the balance requirements of false positives and false negatives in different business scenarios.

[0117] The above description is merely a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any modifications made by those skilled in the art within the scope disclosed in the present invention, as long as they follow the basic idea of ​​"application-side discrete level reporting + monitoring-side queue summation and threshold comparison", to the implementation details, such as changing the communication method, adding or reducing level types, or adopting different weighting methods, should be considered as falling within the scope of protection of the present invention and are all within the scope of protection of the present invention.

Claims

1. A smart application health monitoring method, characterized in that, The method includes: The health monitoring process is started to read the preset configuration parameters. According to the preset configuration parameters, a corresponding health status queue is created for each target application, and the most recent reporting timestamp is recorded. The preset configuration parameters include the fatality level threshold, the maximum number of historical entries, the time window length, the timeout threshold, and the warning threshold and the severe anomaly threshold in the number / time dimension. Receive the current health status uploaded by each target application through the health reporting component. The current health status includes discrete levels, text descriptions, and reporting timestamps. Based on the current health status, update the most recently reported timestamp and use preset configuration parameters to determine the health status of the target application.

2. The intelligent application health monitoring method according to claim 1, characterized in that, The method of judging the health status of the target application using preset configuration parameters includes: If the discrete level is greater than or equal to the critical level threshold, the target application is judged as a serious anomaly and a fault event is generated; otherwise, the current health status is appended to the corresponding health status queue, and the earliest record at the head of the queue is removed when the queue length exceeds the maximum number of historical records. Based on the timer, the difference between the current time and the most recently reported timestamp of each target application is checked periodically. If the difference is greater than the timeout threshold, the target application is regarded as having a timeout exception, and a fault event is generated according to the critical level threshold processing logic. For the health status queue, calculate the first-level cumulative sum of the most recent L records and the second-level cumulative sum of records within the time window [t-N, t] at the current time. Based on the first-level cumulative sum and the second-level cumulative sum, judge the health status of the target application, where t is the current time, L = min(M, n), M is the maximum number of historical records, N is the time window length, and n is the queue length.

3. The intelligent application health monitoring method according to claim 2, characterized in that, The process of determining the health status of the target application based on the first-level cumulative sum and the second-level cumulative sum includes: If either the first-level cumulative sum is greater than or equal to the severe anomaly threshold in the frequency dimension or the second-level cumulative sum is greater than or equal to the severe anomaly threshold in the time dimension, the target application will be judged as severely anomaly, and a preset rapid recovery strategy will be triggered based on the fault event. If either the first-level cumulative sum is less than the severe abnormality threshold of the frequency dimension but greater than or equal to the warning threshold of the frequency dimension, or the second-level cumulative sum is less than the severe abnormality threshold of the time dimension but greater than or equal to the warning threshold of the time dimension, then the target application will be judged as sub-healthy. If the cumulative sum of the first level is less than the warning threshold of the number dimension, and the cumulative sum of the second level is less than the warning threshold of the time dimension, then the target application is judged as healthy.

4. The intelligent application health monitoring method according to claim 3, characterized in that, The preset fast recovery strategy includes at least one of the following operations: Restart the target application using a process management tool or container orchestration platform; New request traffic is switched to other healthy instances via load balancing or service discovery components; Execute state recovery scripts to restore critical business states from snapshots, caches, or message queues.

5. The intelligent application health monitoring method according to claim 1, characterized in that, The health reporting component reports the current health status in at least one of the following scenarios: When the target application completes a critical task or request without any exceptions, it reports its current health status with a discrete level of 0. When a short-term high load is detected that causes some requests to time out, a text description containing an exception is reported, as well as the current health status with a discrete level of 10 is reported. When it is detected that a resource is continuously occupied for a predetermined period of time but may still be recoverable, a text description containing an anomaly is reported, as well as a health status with a discrete level of 20 is reported. When a thread deadlock, critical module crash, or other fatal error that requires an immediate restart to recover is detected, a text description containing an exception description is reported, along with a health status with a discrete level equal to the fatal level threshold.

6. The intelligent application health monitoring method according to claim 1, characterized in that, When the target application determines that an exception is caused by an external dependency and restarting itself cannot resolve the issue, it reports a text description containing the exception information and the current health status with a discrete level of 0 through the health reporting component.

7. The intelligent application health monitoring method according to any one of claims 1-6, characterized in that, The method further includes: Within a preset time period, statistically analyze the correspondence between early warning events, fault events, and actual fault conditions; Based on the statistically obtained false alarm and missed alarm counts, at least one of the following should be adjusted: the warning threshold for the frequency dimension, the warning threshold for the time dimension, the severe anomaly threshold for the frequency dimension, the severe anomaly threshold for the time dimension, the maximum number of historical records, the time window length, and the timeout threshold.

8. A smart application health monitoring device, characterized in that, The device includes: The health status queue creation module is used to start the health monitoring process, read the preset configuration parameters, create a corresponding health status queue for each target application according to the preset configuration parameters, and record the most recent reporting timestamp. The preset configuration parameters include the fatality level threshold, the maximum number of historical entries, the time window length, the timeout threshold, and the warning threshold and the severe anomaly threshold in the number / time dimension. The health status receiving module is used to receive the current health status uploaded by each target application through the health reporting component. The current health status includes discrete levels, text descriptions, and reporting timestamps. The health status assessment module is used to update the most recently reported timestamp based on the current health status and to assess the health status of the target application using preset configuration parameters.

9. A computer device comprising a processor and a memory for storing a processor-executable program, characterized in that, When the processor executes the program stored in the memory, it implements the intelligent application health monitoring method according to any one of claims 1-7.

10. A computer-readable storage medium storing a program, characterized in that, When the program is executed by the processor, it implements the intelligent application health monitoring method according to any one of claims 1-7.

Images