Anomaly detection and management methods, devices, distributed systems, and storage media

Abstract

This invention discloses an anomaly detection and management method, apparatus, distributed system, and storage medium. The method includes acquiring runtime data of a target service, including request processing time, thread usage in the thread pool, and node resource utilization; determining a service execution performance number based on the request processing time, thread usage, and node resource utilization; determining a dynamic feasible region interval based on historical service execution performance number data of the target service and a preset manual intervention factor-defined manual intervention interval; triggering a manual intervention alarm if the service execution performance number does not fall within the dynamic feasible region interval; recording the processing feedback results corresponding to the manual intervention alarm; and adjusting the manual intervention interval positively or negatively according to the processing feedback results and a preset strategy. This invention enables a closed-loop migration of machine learning from assisted decision-making to autonomous control by adjusting the dynamic feasible region interval.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to an anomaly detection and management method, apparatus, distributed system, and storage medium. Background Technology

[0002] In current distributed system operation and maintenance practices, anomaly detection and management still heavily rely on traditional monitoring methods, which have significant technical limitations. On the one hand, when abnormal interface calls occur during service operation (such as response timeouts, service unavailability, or malicious requests), the entire process from anomaly discovery and root cause localization to final repair generally relies on manual intervention, resulting in low automation and limited response efficiency. On the other hand, existing anomaly detection models are mostly based on static rules (such as time-consuming alarms with fixed thresholds), which cannot be dynamically predicted and adaptively adjusted based on the current actual operating status of the service and historical performance trends, resulting in a lack of scenario awareness in the early warning mechanism. In addition, abnormal events can often only be passively learned through external feedback (such as user complaints) or alarms issued by service providers, making it difficult to achieve proactive identification and early warning before failures occur, resulting in low efficiency in closed-loop handling. Summary of the Invention

[0003] This invention aims to address at least one of the technical problems existing in the prior art. To this end, this invention proposes an anomaly detection and management method, apparatus, distributed system, and storage medium, which can achieve a closed-loop migration of machine learning from assisted decision-making to autonomous control by adjusting the dynamic feasible domain interval.

[0004] In a first aspect, embodiments of the present invention provide an anomaly detection and management method, comprising: Obtain runtime data of the target service, including request processing time, thread usage of the thread pool, and node resource utilization. Based on the request processing time, the number of threads used, and the node resource utilization, a service execution performance number is determined. Based on the historical service execution performance data of the target service and the manual intervention interval defined by the preset manual intervention factor, the dynamic feasible domain interval is determined; If the service execution performance number does not fall within the dynamic feasible range, a manual intervention alarm is triggered. Record the processing feedback results corresponding to the manual intervention alarm, and adjust the manual intervention range positively or negatively according to the processing feedback results and a preset strategy.

[0005] According to some embodiments of the present invention, obtaining runtime data of the target service includes: Deploy a unified, non-intrusive agent probe on distributed service nodes; The agent probe utilizes bytecode enhancement technology to collect method-level runtime data of the target service in real time.

[0006] According to some embodiments of the present invention, obtaining runtime data of the target service includes: Obtain at least one of the CPU utilization, memory utilization, and I / O utilization of the distributed service node where the target service is located; The node resource utilization rate of runtime data is determined based on at least one of the CPU utilization rate, the memory utilization rate, and the I / O utilization rate.

[0007] According to some embodiments of the present invention, determining the service execution performance number based on the request processing time, the thread usage, and the node resource utilization includes: The service time deviation is determined based on the request processing time and the historical average processing time of the same interface. The thread load rate is determined based on the thread usage and the total number of available threads in the thread pool. The service execution performance number is determined based on the service time deviation, the thread load rate, and the node resource utilization rate.

[0008] According to some embodiments of the present invention, determining the service execution performance number based on the service latency deviation, the thread load rate, and the node resource utilization rate includes: The service execution performance number is obtained by multiplying the service time deviation, the thread load rate, and the node resource utilization rate.

[0009] According to some embodiments of the present invention, the manual intervention interval has a first lower limit and a first upper limit, and the step of determining the dynamic feasible region interval based on the historical service execution performance number data of the target service and the preset manual intervention factor includes: The lower limit of the second interval is obtained by multiplying the average historical service execution performance number of the target service by the lower limit of the first interval. Multiply the average historical service execution performance number of the target service by the upper limit of the first interval to obtain the upper limit of the second interval; The lower limit of the second interval and the upper limit of the second interval are combined to form a dynamic feasible region interval.

[0010] According to some embodiments of the present invention, adjusting the artificial intervention range positively or negatively according to the feedback result by a preset amplitude includes: If the processing feedback result indicates that no processing is required, the manual intervention range is positively adjusted by a preset range to increase the range of the manual intervention range; If the processing feedback result indicates that processing is required, the manual intervention range is negatively adjusted according to a preset range to narrow the range of the manual intervention range.

[0011] Secondly, embodiments of the present invention provide an anomaly detection and management device, comprising: The data acquisition module is used to acquire runtime data of the target service, including request processing time, thread usage of the thread pool, and node resource utilization. The first determining module is used to determine the service execution performance number based on the request processing time, the number of threads used, and the node resource utilization rate. The second determining module is used to determine the dynamic feasible domain range based on the historical service execution performance number data of the target service and the artificial intervention range defined by the preset artificial intervention factor. The alarm judgment module is used to trigger a manual intervention alarm when the service execution performance number does not fall within the dynamic feasible domain range; The feedback adjustment module is used to record the processing feedback results corresponding to the manual intervention alarm, and to adjust the manual intervention range positively or negatively according to the processing feedback results and a preset strategy.

[0012] Thirdly, embodiments of the present invention provide a distributed system, including a processor and a memory, wherein the memory stores a computer program, and the processor runs the computer program to implement the above-mentioned anomaly detection and management method.

[0013] Fourthly, embodiments of the present invention provide a storage medium storing a computer program, which, when run, implements the above-described anomaly detection and management method.

[0014] The embodiments of the present invention have at least the following beneficial effects: Alarm judgment is based on the service execution performance ID of the target service and historical service execution performance ID data. In the initial stage, due to the limited amount of historical service execution performance ID data, manual intervention is required to ensure the reliability of the judgment. As the number of service executions increases and historical service execution performance ID data is continuously accumulated, the accuracy of alarms gradually improves. Moreover, based on the feedback results of the processing of alarms by manual intervention, the range of the dynamic feasible domain can be gradually expanded, effectively reducing unnecessary alarms and manual intervention, and promoting the evolution of anomaly detection from human-led to machine autonomous decision-making. In this way, the closed-loop migration of machine learning from assisted decision-making to autonomous control can be achieved by adjusting the dynamic feasible domain.

[0015] Additional aspects and advantages of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. Attached Figure Description

[0016] The above and / or additional aspects and advantages of the present invention will become apparent and readily understood from the description of the embodiments taken in conjunction with the following drawings, in which: Figure 1 This is a flowchart illustrating the steps of the anomaly detection and management method according to an embodiment of the present invention; Figure 2 This is a schematic block diagram of the anomaly detection and management device according to an embodiment of the present invention; Figure 3 This is a schematic diagram of the distributed system according to an embodiment of the present invention. Detailed Implementation

[0017] Embodiments of the present invention are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention, and should not be construed as limiting the present invention.

[0018] In the description of this invention, "several" means one or more, "multiple" means two or more, "greater than," "less than," "exceeding," etc. are understood to exclude the stated number, and "above," "below," "within," etc. are understood to include the stated number. If "first," "second," etc. are used in the description, they are only for the purpose of distinguishing technical features and should not be construed as indicating or implying relative importance or implicitly indicating the number of indicated technical features or the order of the indicated technical features.

[0019] Please refer to Figure 1 This embodiment discloses an anomaly detection management method, including steps S100 to S500. It should be noted that the numbering of the steps in this embodiment is only for ease of review and understanding, and not to limit the execution order of the steps. The content of each step is described in detail below: S100. Obtain runtime data of the target service. Runtime data includes request processing time, thread usage of the thread pool, and node resource utilization. For example, in a distributed system, a target service is typically deployed on one or more service nodes to provide specific business functions (such as store information query, search recommendation, or order processing). When other service components (such as front-end applications, gateways, or other microservices) need to call the target service, they initiate the call through a standard request-response interaction pattern. During this process, the runtime context associated with the call can be naturally captured, thereby obtaining the runtime data of the target service.

[0020] In some application examples, runtime data includes: request processing time, thread usage in the thread pool, and node resource utilization. Request processing time characterizes the time interval from request to response, reflecting service response efficiency. Thread usage in the thread pool characterizes the number of currently active threads, reflecting concurrent load pressure. Node resource utilization includes at least one of CPU utilization, memory utilization, and I / O utilization, characterizing the consumption of underlying computing resources. In other application examples, runtime data may further include metadata for accurate identification and context association, such as: service name (to identify the specific service instance being called), request source (e.g., client IP address or upstream caller identifier), interface path (to distinguish different API endpoints within the same service), request method (e.g., HTTP methods such as GET and POST), call type (e.g., internal service call or external user request), and log framework type (e.g., Logbook, SLF4J, etc., to assist in structured log parsing), at least one of these.

[0021] S200. Determine the service execution performance number based on request processing time, thread usage, and node resource utilization. For example, request processing time, thread usage, and node resource utilization are all core indicators reflecting the critical resource status of a service node when executing a target service. The service execution performance ID (executeNo) characterizes the overall performance level of the target service on its host service node and can indirectly reflect whether there are abnormal interface calls during the target service's operation, such as severe response delays, resource overload, or unexpected high concurrency. By fusing and analyzing the above multi-dimensional resource status data, the resulting service execution performance ID can more comprehensively and objectively assess the actual execution status of the service. Compared to judging by a single indicator, this is beneficial for improving the accuracy and robustness of anomaly identification.

[0022] S300. Determine the dynamic feasible domain range based on the historical service execution performance number data of the target service and the manual intervention range defined by the preset manual intervention factors. For example, whenever the target service is invoked, the corresponding service execution performance ID can be calculated based on the current runtime data. Therefore, all previously generated service execution performance IDs can be used as historical service execution performance ID data to build the performance baseline of the target service, relative to the current invocation.

[0023] In conventional techniques, static rules are typically used for anomaly detection. For example, a fixed alarm threshold is set based on historical service performance ID data. Once the current service performance ID exceeds this threshold, an alarm is triggered. This method lacks adaptability to dynamic changes in service operation status, easily leading to false alarms or missed alarms. This embodiment, however, pre-sets a manual intervention factor and defines a manual intervention range based on this factor. The manual intervention factor can be configured with an initial static value, such as 0.5, 0.6, 0.7, or 0.8. Based on this, the manual intervention range is centered on the manual intervention factor, with upper and lower limits determined according to a preset tolerance range. For example, when the manual intervention factor is configured to 0.5, the manual intervention range can be set to [0.4, 0.6]; when configured to 0.8, the manual intervention range can be set to [0.75, 0.85]. The manual intervention range reflects the system's tolerance boundary for performance fluctuations at the current stage.

[0024] Based on the historical service performance data and the manual intervention intervals for the target service, a dynamic feasible region can be determined. Specifically, the lower and upper limits of the dynamic feasible region are obtained by multiplying the statistical values ​​(such as the mean) of the historical service performance data by the lower and upper limits of the manual intervention interval. This allows the dynamic feasible region to adjust dynamically as historical data is updated, thus enabling adaptive evaluation of service performance status.

[0025] S400: If the service execution performance number does not fall within the dynamic feasible range, a manual intervention alarm will be triggered. For example, by comparing the currently calculated service execution performance number with the dynamic feasible domain range, it can be preliminarily determined whether manual intervention is required. If the service execution performance number does not fall into the dynamic feasible domain range, a manual intervention alarm is triggered; if it falls into the dynamic feasible domain range, the system will automatically execute the subsequent processing strategy without manual intervention, thereby effectively reducing the proportion of manual intervention.

[0026] Specifically, the dynamic feasible region essentially defines the performance tolerance boundary for the system's autonomous handling of anomalies. By using the dynamic feasible region as the threshold for alarm triggering, the system can be endowed with a certain degree of adaptive decision-making capability while ensuring reliability. Since the dynamic feasible region is generated based on historical service execution performance data and adjustable manual intervention intervals, and can be continuously updated with operational feedback, the boundary of the dynamic feasible region possesses dynamic evolution characteristics. Therefore, the system can autonomously and dynamically adjust the allocation of permissions between machine decision-making and manual intervention in anomaly handling, gradually achieving a smooth transition from assisted judgment to autonomous control.

[0027] S500 records the processing feedback results corresponding to manual intervention alarms, and adjusts the manual intervention range positively or negatively according to the preset strategy based on the processing feedback results.

[0028] For example, because machine decision-making may contain errors, the system records the corresponding human intervention feedback after triggering a human intervention alarm. This feedback is used to evaluate the validity of the alarm: if the feedback indicates that the current anomaly requires human intervention, it is considered a valid alarm; if the feedback indicates that no action is needed or it is a false alarm, it is considered an invalid alarm. Based on this evaluation, the system adjusts the human intervention range according to a preset strategy. For example, in the case of a valid alarm, the human intervention range is negatively adjusted (e.g., narrowing the tolerance) to enhance alarm sensitivity; in the case of an invalid alarm, positively adjusted (e.g., widening the tolerance) is implemented to suppress excessive alarms. By continuously accumulating feedback and dynamically correcting the human intervention range, the system can gradually optimize the judgment boundary of the dynamic feasible region, improve the accuracy and reliability of machine decision-making, and thus promote the smooth evolution of the anomaly handling mechanism from being primarily based on human intervention to being primarily based on machine autonomous decision-making.

[0029] Therefore, alarm judgment is made based on the service execution performance ID of the target service and historical service execution performance ID data. In the initial stage, due to the limited amount of historical service execution performance ID data, manual intervention is required to ensure the reliability of the judgment. As the number of service executions increases and historical service execution performance ID data is continuously accumulated, the accuracy of alarms gradually improves. Moreover, based on the feedback results of the manual intervention alarm processing, the range of the dynamic feasible domain can be gradually expanded, effectively reducing unnecessary alarms and manual intervention, and promoting the evolution of anomaly detection from human-led to machine autonomous decision-making. In this way, the closed-loop migration of machine learning from assisted decision-making to autonomous control can be achieved by adjusting the dynamic feasible domain.

[0030] In some application examples, step S100, obtaining runtime data of the target service, includes: Deploy a unified, non-intrusive agent probe on distributed service nodes; The agent probe utilizes bytecode enhancement technology to collect method-level runtime data of the target service in real time.

[0031] For example, a unified, non-intrusive agent probe is deployed on each node of the distributed service. This agent probe is injected into the target application process via Java agent technology, enabling transparent monitoring of the target service's runtime status without modifying the business logic. When the target service processes an external request (such as an HTTP or RPC call), the agent probe automatically intercepts the call entry point and generates a globally unique TraceID and a local SpanID for that request, used to identify the complete call chain. It also records key chain information such as the interface path, request method, response status code, and request processing time.

[0032] In addition, the agent probe continuously collects two types of system-level runtime metrics: JVM (Java Virtual Machine) metrics and operating system metrics. JVM metrics include heap memory utilization, non-heap memory usage, garbage collection (GC) frequency and single-cycle time, which reflect the memory health and operational stability of Java applications. Operating system metrics include resource utilization data such as CPU utilization, I / O load, and number of active threads in the thread pool, which characterize the underlying computing and concurrent resource consumption of the node where the service is located.

[0033] The aforementioned data acquisition capabilities rely on bytecode enhancement technology, which modifies the bytecode of the target method during class loading or runtime, dynamically embedding monitoring logic at the method's entry and exit points. This technology enables agent probes to accurately capture input parameters, return values, exception information, and execution time at the method level, thereby achieving fine-grained, low-intrusion runtime data acquisition. This allows for real-time, structured acquisition of multi-dimensional runtime data of the target service during each call, including but not limited to request processing time, thread pool usage status, and node resource utilization. This provides a reliable data foundation for subsequent functions such as performance evaluation of computing services, construction of dynamic feasible domains, and implementation of closed-loop feedback control.

[0034] Step S100, obtaining runtime data of the target service, includes: Obtain at least one of the CPU utilization, memory utilization, and I / O utilization of the distributed service node where the target service is located; The node resource utilization of runtime data is determined based on at least one of CPU utilization, memory utilization, and I / O utilization.

[0035] For example, CPU utilization, memory utilization, and I / O utilization are key operating system metrics for distributed service nodes, used to characterize the consumption of underlying computing, storage, and input / output resources by the node hosting the target service during request execution. These metrics directly reflect the load level of system resources and are important indicators for determining whether the service is running normally. The node resource utilization in runtime data is determined by obtaining at least one of the CPU utilization, memory utilization, and I / O utilization of the nodes where the target service is deployed, and based on this at least one metric. In some application examples, the node resource utilization can be the maximum value among CPU utilization, memory utilization, and I / O utilization to reflect the most bottleneck resource dimension; or, in other application examples, the node resource utilization can be calculated as a weighted average or arithmetic mean of CPU utilization, memory utilization, and I / O utilization to comprehensively assess the overall resource pressure.

[0036] The node resource utilization rate determined by the above method can effectively characterize the actual degree of system resource occupation by the target service during execution. For example, when a call is accompanied by a significant increase in node resource utilization (such as a sudden increase in CPU to over 90%), even if the request processing time does not significantly exceed the limit, it may indicate potential abnormal behavior, such as the interface being subjected to high-frequency calls, resource leakage, or malicious attacks. Therefore, using node resource utilization rate as one of the multi-dimensional judgment factors can help identify hidden anomalies that are difficult to detect by relying solely on response time, thereby improving the sensitivity and coverage of detecting abnormal interface calls (such as service overload, unexpected high concurrency, resource contention, etc.).

[0037] Step S200: Based on request processing time, thread usage, and node resource utilization, determine the service execution performance number, including: Determine the service time deviation based on the request processing time and the historical average processing time of the same interface; Determine the thread load rate based on thread usage and the total number of available threads in the thread pool; The service execution performance number is determined based on the service time deviation, thread load rate, and node resource utilization.

[0038] For example, the historical average processing time is a baseline value obtained through statistical analysis of historical call records of the same interface in the target service. For instance, the average processing time of all successful requests within a sliding window can be used. Based on this, the ratio of the current request's processing time to the historical average processing time corresponding to that interface is calculated to obtain the service time deviation. The service time deviation is used to quantify the response latency of the current call relative to the historical performance baseline. Simultaneously, based on the ratio of the current thread usage to the total available threads in the thread pool, the thread load rate is determined to characterize the concurrent resource consumption level of the service node when processing the current request. Furthermore, by combining the service time deviation, thread load rate, and node resource utilization (such as at least one of CPU, memory, or I / O utilization), the execution status of the target service is comprehensively evaluated from three dimensions: response efficiency, concurrency pressure, and system resource consumption, thereby determining the service execution performance ID.

[0039] In a specific application example, the above steps—determining the service execution performance ID based on service latency deviation, thread load rate, and node resource utilization—include: Multiply the service execution time deviation, thread load rate, and node resource utilization to obtain the service execution performance number.

[0040] For example, the service execution performance number is obtained by multiplying the service time deviation, thread load rate, and node resource utilization. The product operation can effectively amplify the superposition effect of multidimensional anomalies. For example, when the request time is significantly extended, the thread pool is close to saturation, and the CPU utilization rate soars, the service execution performance number will increase sharply, thereby triggering the subsequent anomaly judgment mechanism more sensitively.

[0041] In some application examples, the manual intervention interval has a first lower limit and a first upper limit. Step S300: Based on the historical service execution performance ID data of the target service and the manual intervention interval defined by the preset manual intervention factor, determine the dynamic feasible domain interval, including: Multiply the average historical service execution performance number of the target service by the lower limit of the first interval to obtain the lower limit of the second interval; Multiply the average historical service execution performance number of the target service by the upper limit of the first interval to obtain the upper limit of the second interval; The lower limit of the second interval and the upper limit of the second interval form a dynamic feasible region interval.

[0042] For example, traditional alarm mechanisms often use fixed numerical thresholds, which are difficult to adapt to normal fluctuations in different interfaces or during peak business periods. This embodiment, however, combines the average historical service performance number with a manual intervention interval, allowing the boundaries of the feasible domain interval to dynamically adjust according to the actual operating level of the target service. Furthermore, the manual intervention interval exists in a dimensionless proportional form (e.g., 0.6–1.2), which can be used as a general policy template for multiple heterogeneous services, eliminating the need to set absolute thresholds for each service individually. Operations personnel only need to maintain one set of proportional parameters to automatically generate dynamic feasible domains adapted to the performance characteristics of each service, significantly reducing configuration complexity. Moreover, when adjusting the manual intervention interval based on the feedback structure (e.g., widening the upper limit from 1.2 to 1.3), the feasible domain intervals of all services will expand synchronously in the same proportion, achieving a globally consistent evolution of the policy.

[0043] In step S500, based on the feedback results, the manual intervention range is adjusted positively or negatively according to a preset range, including: If the feedback result indicates that no action is required, the manual intervention interval is positively adjusted according to a preset range to increase the range of the manual intervention interval. If the feedback results indicate that action is needed, the manual intervention interval is negatively adjusted according to a preset range to narrow the range of the manual intervention interval.

[0044] For example, if the feedback result indicates that the current alarm is a false alarm or does not require manual intervention (e.g., operations and maintenance personnel confirm that the service is running normally and there is no business impact), then the alarm is determined to be too sensitive, and a positive adjustment is made to the manual intervention range, that is, the lower limit of the original first range is reduced by a preset range, and the upper limit of the first range is increased by a preset range, thereby expanding the overall range of the manual intervention range. When the feedback indicates that the current alarm requires manual intervention (e.g., confirmation of performance degradation, resource overload, or business anomalies), the tolerance level is deemed too high, and a negative adjustment is performed on the manual intervention range: a preset range is added to the lower limit of the first range, and a preset range is decreased to the upper limit, thus narrowing the overall range of the manual intervention range. The preset range can be a fixed value (e.g., ±0.05), a percentage of the current range width, or proportional to the number of calls, ensuring a stable and controllable adjustment process. In the initial data-sparse phase, the system tends to conservatively issue alarms (with a narrower dynamic feasible region) to ensure reliability. As effective feedback accumulates and the range dynamically expands, the machine's ability to autonomously allow normal fluctuations continuously increases, significantly reducing the frequency of manual intervention, ultimately achieving automated anomaly handling under high confidence levels.

[0045] Based on the same technical concept as the above-mentioned anomaly detection management method, please refer to Figure 2 This embodiment provides an anomaly detection and management device, including: The data acquisition module 110 is used to acquire runtime data of the target service. The runtime data includes request processing time, thread usage of the thread pool, and node resource utilization. The first determining module 120 is used to determine the service execution performance number based on request processing time, thread usage, and node resource utilization. The second determining module 130 is used to determine the dynamic feasible domain range based on the historical service execution performance number data of the target service and the artificial intervention range defined by the preset artificial intervention factor. The alarm judgment module 140 is used to trigger a manual intervention alarm when the service execution performance number does not fall within the dynamic feasible range. The feedback adjustment module 150 is used to record the processing feedback results corresponding to manual intervention alarms, and to make positive or negative adjustments to the manual intervention range according to the processing feedback results and a preset strategy.

[0046] The inventive concept of this anomaly detection management device embodiment is the same as that of the anomaly detection management method embodiment described above. Content not covered in this anomaly detection management device embodiment can be referred to in the above anomaly detection management method embodiment, and will not be repeated here. Alarm judgment is performed based on the service execution performance ID of the target service and historical service execution performance ID data. In the initial stage, due to the limited historical service execution performance ID data, manual intervention is relied upon to ensure the reliability of the judgment. As the number of service executions increases, historical service execution performance ID data accumulates, and the accuracy of alarms gradually improves. Moreover, based on the feedback results of manual intervention in alarm processing, the range of the dynamic feasible region can be gradually expanded, effectively reducing unnecessary alarms and manual intervention, and promoting the evolution of anomaly detection from human-led to machine-autonomous decision-making. In this way, a closed-loop migration of machine learning from assisted decision-making to autonomous control can be achieved by adjusting the dynamic feasible region.

[0047] Please refer to Figure 3 This embodiment also provides a distributed system, including a processor 210 and a memory 220. The memory 220 stores a computer program, and the processor 210 runs the computer program to implement the above-described anomaly detection and management method. The anomaly detection and management method can be referred to above and will not be repeated here. Alarm judgment is performed based on the service execution performance number of the target service and historical service execution performance number data. In the initial stage, since there is little historical service execution performance number data, manual intervention is relied upon to ensure the reliability of the judgment. As the number of service executions increases, historical service execution performance number data is continuously accumulated, and the accuracy of alarms gradually improves. Moreover, based on the feedback results of the processing of alarms by manual intervention, the range of the dynamic feasible domain can be gradually expanded, effectively reducing unnecessary alarms and manual intervention, and promoting the evolution of anomaly detection from human-led to machine autonomous decision-making. In this way, the closed-loop migration of machine learning from assisted decision-making to autonomous control can be achieved by adjusting the dynamic feasible domain.

[0048] This embodiment also provides a storage medium storing a computer program. When the computer program is run, it implements the above-described anomaly detection and management method. The anomaly detection and management method can be referred to above and will not be repeated here. Alarm judgment is performed based on the service execution performance ID of the target service and historical service execution performance ID data. In the initial stage, since there is little historical service execution performance ID data, manual intervention is relied upon to ensure the reliability of the judgment. As the number of service executions increases, historical service execution performance ID data is continuously accumulated, and the accuracy of alarms gradually improves. Moreover, based on the feedback results of the processing of alarms by manual intervention, the range of the dynamic feasible region can be gradually expanded, effectively reducing unnecessary alarms and manual intervention, and promoting the evolution of anomaly detection from human-led to machine autonomous decision-making. In this way, the closed-loop migration of machine learning from assisted decision-making to autonomous control can be achieved by adjusting the dynamic feasible region.

[0049] The embodiments of the present invention have been described in detail above with reference to the accompanying drawings. However, the present invention is not limited to the above embodiments. Within the scope of knowledge possessed by those skilled in the art, various changes can be made without departing from the spirit of the present invention.

Claims

1. An anomaly detection and management method, characterized in that, include: Obtain runtime data of the target service, including request processing time, thread usage of the thread pool, and node resource utilization. Based on the request processing time, the number of threads used, and the node resource utilization, a service execution performance number is determined. Based on the historical service execution performance data of the target service and the manual intervention interval defined by the preset manual intervention factor, the dynamic feasible domain interval is determined; If the service execution performance number does not fall within the dynamic feasible range, a manual intervention alarm is triggered. Record the processing feedback results corresponding to the manual intervention alarm, and adjust the manual intervention range positively or negatively according to the processing feedback results and a preset strategy.

2. The anomaly detection and management method according to claim 1, characterized in that, The acquisition of runtime data for the target service includes: Deploy a unified, non-intrusive agent probe on distributed service nodes; The agent probe utilizes bytecode enhancement technology to collect method-level runtime data of the target service in real time.

3. The anomaly detection and management method according to claim 1 or 2, characterized in that, The acquisition of runtime data for the target service includes: Obtain at least one of the CPU utilization, memory utilization, and I / O utilization of the distributed service node where the target service is located; The node resource utilization rate of runtime data is determined based on at least one of the CPU utilization rate, the memory utilization rate, and the I / O utilization rate.

4. The anomaly detection and management method according to claim 1, characterized in that, The process of determining the service execution performance number based on the request processing time, thread usage, and node resource utilization includes: The service time deviation is determined based on the request processing time and the historical average processing time of the same interface. The thread load rate is determined based on the thread usage and the total number of available threads in the thread pool. The service execution performance number is determined based on the service time deviation, the thread load rate, and the node resource utilization rate.

5. The anomaly detection and management method according to claim 4, characterized in that, The process of determining the service execution performance number based on the service time deviation, the thread load rate, and the node resource utilization rate includes: The service execution performance number is obtained by multiplying the service time deviation, the thread load rate, and the node resource utilization rate.

6. The anomaly detection and management method according to claim 1, characterized in that, The manual intervention interval has a first lower limit and a first upper limit. The determination of the dynamic feasible region interval based on the historical service execution performance ID data of the target service and the preset manual intervention factor includes: The lower limit of the second interval is obtained by multiplying the average historical service execution performance number of the target service by the lower limit of the first interval. Multiply the average historical service execution performance number of the target service by the upper limit of the first interval to obtain the upper limit of the second interval; The lower limit of the second interval and the upper limit of the second interval are combined to form a dynamic feasible region interval.

7. The anomaly detection and management method according to claim 1, characterized in that, The step of adjusting the manual intervention range positively or negatively according to the feedback result includes: If the processing feedback result indicates that no processing is required, the manual intervention range is positively adjusted by a preset range to increase the range of the manual intervention range; If the processing feedback result indicates that processing is required, the manual intervention range is negatively adjusted according to a preset range to narrow the range of the manual intervention range.

8. An anomaly detection and management device, characterized in that, include: The data acquisition module is used to acquire runtime data of the target service, including request processing time, thread usage of the thread pool, and node resource utilization. The first determining module is used to determine the service execution performance number based on the request processing time, the number of threads used, and the node resource utilization rate. The second determining module is used to determine the dynamic feasible domain range based on the historical service execution performance number data of the target service and the artificial intervention range defined by the preset artificial intervention factor. The alarm judgment module is used to trigger a manual intervention alarm when the service execution performance number does not fall within the dynamic feasible domain range; The feedback adjustment module is used to record the processing feedback results corresponding to the manual intervention alarm, and to adjust the manual intervention range positively or negatively according to the processing feedback results and a preset strategy.

9. A distributed system, comprising a processor and a memory, wherein the memory stores a computer program, characterized in that, When the processor runs the computer program, it is used to implement the anomaly detection management method as described in any one of claims 1 to 7.

10. A storage medium storing a computer program, characterized in that, When the computer program is run, it implements the anomaly detection management method as described in any one of claims 1 to 7.

Images