Fault alarm method based on JVM-Sandbox

Abstract

The invention discloses a fault alarm method based on JVM-Sandbox. The fault alarm method comprises the following steps: monitoring all events needing to be intercepted in a service application based on the JVM-Sandbox; the BeforeEvent event, the RetunEvent event and the ThrowEvent event of each request are intercepted, and data information of the events needing to be intercepted is obtained; configuring a dynamic rule of fault alarm, performing matching filtering on the data information based on the dynamic rule, obtaining an alarm event after coarse-grained noise reduction, and uploading the alarm event to a cloud alarm platform; and after the cloud alarm platform receives the alarm events, counting the times of different alarm events in a time window, configuring an alarm rule, carrying out selective noise reduction, and then giving an alarm. According to the method, the dynamic rules of the related keywords are configured in a scene mode to identify the fault alarm information needing to be manually intervened and processed, accurate alarm is achieved, the scheme flexibility is improved, and more abnormal scenes can be dealt with.

Description

Technical Field

[0001] The present invention relates to the technical field of fault alarm, and in particular to a fault alarm method based on JVM-Sandbox. Background Art

[0002] Nowadays, with the widespread application of large-scale complex systems, the stability and reliability of the system have become extremely important concerns. However, due to the complexity and diversity of the system, troubleshooting has become extremely difficult. Conventional monitoring methods often cannot accurately capture the specific scenarios where the fault occurs, resulting in a long fault handling cycle and low efficiency.

[0003] Existing methods usually provide alarm notifications based on fault collection and analysis or based on error logs. The above methods have several technical problems: 1. Alarm events are not converged and denoised, resulting in too many fault event alarms; 2. There are a large number of fault events with low weights, which increases the number of fault alarms; 3. The same fault problem cannot be accurately identified, resulting in repeated alarms for the same fault; 4. Error log alarms are too redundant and contain a large number of invalid error logs.

[0004] To solve the above problems, the present invention proposes a scenario-based accurate fault alarm method based on JVM-Sandbox. The method mainly lists common fault scenarios and uses the Agent method of JVM-Sandbox to realize real-time collection of fault information and alarm notification. Summary of the invention

[0005] In view of the above technical problems, the present invention provides a fault alarm method based on JVM-Sandbox, which can help the development team to discover fault problems more accurately and solve the problem of interference caused by a large number of invalid or non-serious fault alarm events.

[0006] To achieve the above purpose, the technical solution adopted by the present invention is as follows: A fault alarm method based on JVM-Sandbox includes the following steps: S1. Monitor the events that need to be intercepted by business applications based on JVM-Sandbox; S2. Intercept the BeforeEvent, ReturnEvent and ThrowEvent of each request to obtain the data information of the events that need to be intercepted; S3. Configure dynamic rules for fault alarms, match and filter data information based on dynamic rules, obtain alarm events and upload them to the cloud alarm platform; S4. After receiving the alarm event, the cloud alarm platform counts the number of different alarm events within the time window and configures the alarm rules for selective alarm.

[0007] In some embodiments of the present invention, in S1, the ModuleEventWatcher mechanism based on JVM-Sandbox monitors the events that need to be intercepted by the business application.

[0008] In some embodiments of the present invention, in S1, the business application is loaded in an Agent manner.

[0009] In some embodiments of the present invention, in S2: for the Dubbo calling mode, the BeforeEvent event, ReturnEvent event and ThrowEvent event of FutureFilter and GenericFilter in the Dubbo framework are intercepted; for the Controller calling mode, the BeforeEvent event, ReturnEvent event and ThrowEvent event of DispatcherServlet in the Spring framework are intercepted; for the MyBatis calling mode, the BeforeEvent event, ReturnEvent event and ThrowEvent event of MapperMethod in the MyBatis framework are intercepted; for the MQ calling mode, the BeforeEvent event, ReturnEvent event and ThrowEvent event of MessageListenerConcurrently and MessageListenerOrderly are intercepted; for the Job calling mode, the BeforeEvent event, ReturnEvent event and ThrowEvent event of IJobHandler are intercepted.

[0010] In some embodiments of the present invention, in S2, the data information includes metadata information, business results during calling, and fault event information during calling. The metadata information is obtained through the BeforeEvent event, the business results of the call are parsed through the ReturnEvent event, and the fault event information during calling is obtained through the ThrowEvent event.

[0011] In some embodiments of the present invention, S3 includes: S31, configuring dynamic rules for fault alarms, the dynamic rules including a customized first keyword and a second keyword, and there are multiple first keywords and second keywords; S32, using dynamic rules to match and filter metadata information, business results and fault event information. If the character string of the exception stack in the metadata information or the fault event information contains at least one first keyword, or the business result contains at least one second keyword, the event that needs to be intercepted corresponding to the current metadata information, fault event information or business result is marked as an alarm event and the alarm event is asynchronously uploaded to the cloud alarm platform.

[0012] In some embodiments of the present invention, the first keyword includes character strings representing null pointer exception, database deadlock exception, Dubbo call with no service provider, SQL execution exception, and server internal error.

[0013] In some embodiments of the present invention, the second keyword includes a character string representing insufficient API call times and please recharge first.

[0014] In some embodiments of the present invention, in S4, the number of alarm events of different fault types is counted within the time window.

[0015] In some embodiments of the present invention, configuring alarm rules for selective alarms includes: within a specified time window, if an alarm event of a certain fault type has been issued, then the current alarm event is counted and then ignored directly; if no alarm has been issued, then an alarm is issued directly; within a specified time window, a specified interface of a specified business application is called, and if multiple call failures occur within the specified time window based on business results, then an alarm is issued directly.

[0016] Compared with the prior art, the present invention has the following beneficial effects: 1. The present invention uses JVM-Sandbox to monitor events that need to be intercepted, and then loads business applications, thereby realizing asynchronous monitoring, collection, and reporting of fault events to the cloud alarm platform.

[0017] 2. The present invention realizes accurate collection of fault events through dynamic rules of fault alarm, thereby reducing a large number of invalid or unimportant fault events.

[0018] 3. The present invention realizes the noise reduction and convergence capability of faults within the time window on the cloud fault alarm platform according to the data statistics within the time window, thereby greatly reducing the fault events received by developers.

[0019] 4. The present invention filters out alarm events that require human intervention through the matching of dynamic rules of fault alarms, and alerts the fault problems that developers really need to be concerned about, and the final effect is that the alarm is the problem. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] Figure 1 The figure is a flow chart of the method of the present invention. DETAILED DESCRIPTION

[0021] Terminology explanation: ‌JVM-Sandbox is a non-intrusive runtime Aspect-Oriented Programming (AOP) solution for the Java Virtual Machine (JVM) platform.

[0022] The agent approach is a method that uses artificial intelligence agents to complete tasks through agent workflows.

[0023] The ModuleEventWatcher mechanism is a technique for monitoring and responding to module-level events. It allows developers or system administrators to set up specific watchers to monitor module activities and trigger corresponding actions or reactions when specific events occur.

[0024] FutureFilter is a filter in the Dubbo framework for processing event notifications.

[0025] ‌GenericFilter‌ is a custom filter in the Dubbo framework.

[0026] DispatcherServlet DispatcherServlet is a front controller in the Spring framework.

[0027] MapperMethod is an internal class in the MyBatis framework.

[0028] MessageListenerConcurrently is an interface in RocketMQ for concurrent message consumption.

[0029] MessageListenerOrderly is a consumer interface in RocketMQ. RocketMQ is a distributed messaging middleware.

[0030] IJobHandler is an interface in the XXL-JOB framework.

[0031] XXL-JOB is a distributed task scheduling platform.

[0032] In order to make the purpose, technical solutions and advantages of the present invention more clearly understood, the present invention is further described in detail below in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, rather than all of the embodiments. Based on the embodiments in the present invention, all other embodiments obtained by ordinary technicians in the field without making creative work are within the scope of protection of the present invention. In the description of the present invention, it should be noted that the terms "first", "second", etc. are only used for descriptive purposes and cannot be understood as indicating or implying relative importance.

[0033] like Figure 1 As shown, a fault alarm method based on JVM-Sandbox provided by the present invention comprises the following steps: S1. Monitor the events that need to be intercepted by business applications based on JVM-Sandbox; S2. Intercept the BeforeEvent, ReturnEvent and ThrowEvent of each request to obtain the data information of the events that need to be intercepted; S3. Configure dynamic rules for fault alarms, match and filter data information based on dynamic rules, obtain alarm events and upload them to the cloud alarm platform; S4. After receiving the alarm event, the cloud alarm platform counts the number of different alarm events within the time window and configures the alarm rules for selective alarm.

[0034] The present invention uses JVM-Sandbox to monitor events that need to be intercepted, then loads business applications, and then uses dynamic rules of fault alarms to match and filter out alarm events that require human intervention, thereby reducing a large number of invalid or unimportant fault events. Finally, on the cloud-based fault alarm platform, based on data statistics within the time window, the noise reduction and convergence capabilities of faults within the time window are achieved, thereby greatly reducing the fault events received by developers.

[0035] In one embodiment, S1 monitors the events that the business application needs to intercept based on the ModuleEventWatcher mechanism of JVM-Sandbox. The ModuleEventWatcher mechanism is an event monitoring mechanism based on the observer pattern, which allows the corresponding observer to be notified when the target object changes.

[0036] In one embodiment, the S1 loads the business application through an agent method. The agent method is a method of completing tasks using an artificial intelligence agent through an agent workflow.

[0037] In one embodiment, the events that need to be intercepted under different calling modes are intercepted, and the event data information that needs to be intercepted is obtained by intercepting the BeforeEvent event, ReturnEvent event and ThrowEvent event of different filters or interfaces. The data information includes metadata information, business results when calling, and fault event information when calling, wherein metadata information is obtained through the BeforeEvent event; the business results of the call are parsed through the ReturnEvent event, so that some scenarios can selectively determine whether an alarm is required based on the business results; the fault event information when calling is obtained through the ThrowEvent event, and then selective fault alarms can be implemented based on information such as the fault event type.

[0038] According to the Dubbo calling method, the BeforeEvent event, ReturnEvent event and ThrowEvent event of FutureFilter and GenericFilter in the Dubbo framework are intercepted to obtain data information of the events (RPC events) that need to be intercepted. The metadata information in the data information includes request time, request URL, request parameters, response parameters, application, client IP, exception stack, current user ID, and current user name.

[0039] According to the Controller calling method, the BeforeEvent, ReturnEvent and ThrowEvent events of the DispatcherServlet in the Spring framework are intercepted to obtain the data information of the events (HTTP events) that need to be intercepted. The metadata information in the data information includes request time, request URL, request parameters, response parameters, application, client IP, exception stack, current user ID, and current user name.

[0040] According to the MyBatis calling method, intercept the BeforeEvent event, ReturnEvent event and ThrowEvent event of the MapperMethod in the MyBatis framework to obtain the data information of the event (SQL execution event) that needs to be intercepted. The metadata information in the data information includes the request time, request Mapper address, request parameters, response parameters, application, execution SQL, exception stack, current user ID, and current user name.

[0041] For the MQ calling method (taking RocketMQ as an example), intercept the BeforeEvent event, ReturnEvent event and ThrowEvent event of MessageListenerConcurrently and MessageListenerOrderly to obtain the data information of the event that needs to be intercepted (MQ consumption execution event). The metadata information in the data information includes request time, Topic (the first level classification of the message), Group (a type of producer or consumer), Tags (the second level classification of the message), request parameters, response parameters, application, exception stack, current user ID, and current user name.

[0042] According to the Job calling method (taking XXL-JOB as an example), intercept the BeforeEvent event, ReturnEvent event and ThrowEvent event of IJobHandler to obtain the data information of the event that needs to be intercepted (scheduled task execution event). The metadata information in the data information includes request time, task address, task name, request parameters, response parameters, application to which it belongs, and exception stack.

[0043] Further, the S3 includes: S31, configuring dynamic rules for fault alarms, the dynamic rules include a customized first keyword and a second keyword, and there are multiple first keywords and second keywords; S32, using dynamic rules to match and filter metadata information, business results and fault event information, if the metadata information or / and the fault event information contains at least one first keyword in the string of the exception stack, the current metadata information or fault event information corresponding to the event to be intercepted is marked as an alarm event and the alarm event is asynchronously uploaded to the cloud alarm platform. The exception stack represents the scene when the call throws an exception, and by setting the keyword indicating the call throws an exception, if the string of the exception stack contains the set keyword, it means that the corresponding event to be intercepted is an exception and an alarm is required. The first keyword includes a string representing a null pointer exception (NullPointerException), a string representing a database deadlock exception (Deadlock), a string representing a Dubbo call with no service provider (No provider available), a string representing an SQL execution exception (SQLException), and a string representing an internal server error (customized string based on the specific error), and other first keywords can also be set or customized according to actual conditions. The above are more about matching scenarios when exceptions are thrown during calls, but in actual situations, there may be no exceptions thrown, but the business results did not meet expectations, and an alarm is also required. Therefore, the alarm here is based on the business results. If the business result contains at least one second keyword, the second keyword includes a string representing insufficient API call times and please recharge first, that is, when calling a third-party API interface, if the number of times is exhausted, it will not throw an exception, but return through parameter status or description. When the business result contains this keyword, the event that needs to be intercepted corresponding to the current business result can also be marked as an alarm event. Other second keywords can also be set or customized according to actual conditions.

[0044] In one of the embodiments, after receiving an alarm event, the cloud alarm platform counts the number of alarm events of different fault types within a time window. If an alarm event of a certain fault type has been issued within a specified time window, the current alarm event will be counted and ignored directly. If no alarm has been issued (such as only counting once within a time window of 5 minutes), an alarm will be issued directly to prevent a large number of repeated alarms of the same fault type. Within the specified time window, the specified interface of the specified business application is called. Based on the business results, if multiple calls fail within the specified time window, an alarm will be issued directly (such as 20 consecutive calls fail within a time window of 5 minutes).

[0045] The present invention realizes data information collection based on JVM-Sandbox, and then realizes the effect of accurate alarm by configuring dynamic rules for fault alarm. The dynamic rules contain keywords that indicate scenarios that require human intervention. Only keywords need to be configured to filter out alarm events, which greatly improves the flexibility of the solution and can cope with more abnormal scenarios.

[0046] Finally, it should be noted that the above embodiments are only preferred embodiments of the present invention to illustrate the technical solutions of the present invention, rather than limiting them, and certainly not limiting the patent scope of the present invention. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions recorded in the aforementioned embodiments, or replace some or all of the technical features therein by equivalents. These modifications or replacements do not make the essence of the corresponding technical solutions deviate from the scope of the technical solutions of the embodiments of the present invention. In other words, any changes or modifications made to the main design concept and spirit of the present invention that have no substantive significance, and the technical problems they solve are still consistent with the present invention, should be included in the protection scope of the present invention. In addition, the direct or indirect application of the technical solutions of the present invention in other related technical fields is also included in the patent protection scope of the present invention.

Claims

1. A fault alarm method based on JVM-Sandbox, characterized in that: The following steps are involved: S1. Monitor the events that need to be intercepted by business applications based on JVM-Sandbox; S2. Intercept the BeforeEvent, ReturnEvent and ThrowEvent of each request to obtain the data information of the events that need to be intercepted; S3. Configure dynamic rules for fault alarms, match and filter data information based on dynamic rules, obtain alarm events and upload them to the cloud alarm platform; S4. After receiving the alarm event, the cloud alarm platform counts the number of different alarm events within the time window and configures the alarm rules for selective alarm.

2. According to a JVM-Sandbox-based fault alarm method according to claim 1, it is characterized in that: In S1, the ModuleEventWatcher mechanism based on JVM-Sandbox monitors the events that need to be intercepted by the business application.

3. According to a JVM-Sandbox-based fault alarm method according to claim 1, it is characterized in that: In S1, the business application is loaded in an Agent manner.

4. A fault alarm method based on JVM-Sandbox according to claim 1, characterized in that: In the S2: for the Dubbo calling method, the BeforeEvent event, ReturnEvent event and ThrowEvent event of FutureFilter and GenericFilter in the Dubbo framework are intercepted; for the Controller calling method, the BeforeEvent event, ReturnEvent event and ThrowEvent event of DispatcherServlet in the Spring framework are intercepted; for the MyBatis calling method, the BeforeEvent event, ReturnEvent event and ThrowEvent event of MapperMethod in the MyBatis framework are intercepted; for the MQ calling method, the BeforeEvent event, ReturnEvent event and ThrowEvent event of MessageListenerConcurrently and MessageListenerOrderly are intercepted; for the Job calling method, the BeforeEvent event, ReturnEvent event and ThrowEvent event of IJobHandler are intercepted.

5. A fault alarm method based on JVM-Sandbox according to claim 1, characterized in that: In S2, the data information includes metadata information, business results during calling, and fault event information during calling. The metadata information is obtained through the BeforeEvent event, the business results of the call are parsed through the ReturnEvent event, and the fault event information during calling is obtained through the ThrowEvent event.

6. A fault alarm method based on JVM-Sandbox according to claim 5, characterized in that: The S3 includes: S31, configuring dynamic rules for fault alarms, the dynamic rules including a customized first keyword and a second keyword, and there are multiple first keywords and second keywords; S32, using dynamic rules to match and filter metadata information, business results and fault event information. If the character string of the exception stack in the metadata information or the fault event information contains at least one first keyword, or the business result contains at least one second keyword, the event that needs to be intercepted corresponding to the current metadata information, fault event information or business result is marked as an alarm event and the alarm event is asynchronously uploaded to the cloud alarm platform.

7. A fault alarm method based on JVM-Sandbox according to claim 6, characterized in that: The first keywords include character strings representing null pointer exception, database deadlock exception, Dubbo call without service provider, SQL execution exception, and server internal error respectively.

8. A fault alarm method based on JVM-Sandbox according to claim 6, characterized in that: The second keyword includes a character string representing insufficient API call times and please recharge first.

9. A fault alarm method based on JVM-Sandbox according to claim 1, characterized in that: In S4, the number of alarm events of different fault types is counted within the time window.

10. A fault alarm method based on JVM-Sandbox according to claim 9, characterized in that: Configuring alarm rules for selective alarms includes: within a specified time window, if an alarm event of a certain fault type has been issued, the current alarm event will be counted and then ignored; if no alarm has been issued, an alarm will be issued directly; within a specified time window, the specified interface of the specified business application is called, and if multiple call failures occur within the specified time window based on business results, an alarm will be issued directly.

Images