Business process exception monitoring method and device, storage medium and electronic equipment

Abstract

This disclosure relates to a method, apparatus, storage medium, and electronic device for monitoring business process anomalies. The program code of the business process includes multiple sub-code segments. The method includes: for each sub-code segment, when the sub-code is executed, adding the sub-code to a method path list, which stores all sub-codes that have been executed before the currently running sub-code; and timing the runtime of the currently running sub-code using a timer; when the timer's duration exceeds a preset duration corresponding to the currently running sub-code, reporting the method path list to a monitoring platform. By monitoring the runtime of each running sub-code, all possible anomalies in the business process can be monitored, improving the comprehensiveness of monitoring. Reporting the method path list of executed sub-codes when an anomaly occurs facilitates developers in quickly locating the monitored anomaly and analyzing the business anomaly based on the method path list.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and more specifically, to a method, apparatus, storage medium, and electronic device for monitoring business process anomalies. Background Technology

[0002] Current online business monitoring typically falls into two categories: dashboard monitoring and anomaly monitoring. Dashboard monitoring relies on overall data and can detect widespread anomalies. However, when the impact of anomalies is small, especially in the early stages of a version when there are few users, the impact of a few anomalies on the business scope is limited, leading to the failure to detect small-scale anomalies in a timely manner. As the version is updated, the scope of the anomaly's impact will increase, eventually leading to a major online incident. Anomaly monitoring can detect small-scale anomalies and can identify online defects in the early stages of a version. However, anomaly monitoring relies on anomaly tracking points implemented by developers during development, i.e., inserting anomaly monitoring code. To detect all anomalies, anomaly monitoring code needs to be inserted in all possible places where anomalies may occur. However, it is difficult to predict all possible anomalies during the development phase, making it difficult to guarantee that all anomalies can be monitored.

[0003] In addition, when monitoring code anomalies, the relevant technologies can only locate the location of the code that was running when the anomaly occurred. For a business process consisting of multiple code segments, simply locating the location of the code that was running when the anomaly occurred cannot provide developers with a good way to analyze the cause of the anomaly. Summary of the Invention

[0004] The purpose of this disclosure is to provide a business process exception monitoring method, device, storage medium, and electronic device that can monitor all possible exceptions in the business and determine the code method path executed when the exception occurs. This improves the comprehensiveness of exception monitoring and can quickly locate the method path when the exception occurs, thus facilitating developers to analyze the cause of business exceptions.

[0005] To achieve the above objectives, firstly, this disclosure provides a method for monitoring business process anomalies, wherein the program code of the business process includes multiple code segments, and the method includes:

[0006] For each of the aforementioned sub-code segments, when execution reaches that sub-code segment, it is added to the method path list, which stores all sub-code segments that have been executed before the currently executing sub-code segment; and,

[0007] The runtime of the currently running sub-code is timed using a timer;

[0008] When the timer's duration exceeds the preset duration corresponding to the currently running sub-code, the method path list is reported to the monitoring platform.

[0009] The above technical solution addresses the issue that most exceptions in the business process will lead to increased code execution time. In other words, the actual execution time of each sub-code segment reflects the impact of all possible exceptions. Therefore, monitoring the runtime of each running sub-code segment improves the comprehensiveness of the monitoring. Furthermore, it collects the running sub-code in the business process to obtain a method path list. Thus, when an exception is detected in the business process, the method path list of the running sub-code at the time of the exception is reported to the monitoring platform. This facilitates developers in quickly locating the detected exception and performing business exception analysis based on the method path list.

[0010] Optionally, the multiple sub-code segments include process start code and process intermediate code. For each sub-code segment, when the process reaches that sub-code segment, the method adds the sub-code to the method path list, including:

[0011] When the process starts, the method path list is initialized, the process start code is added to the method path list, and the timer is initialized.

[0012] When the process reaches the intermediate code, the intermediate code is added to the method path list, and the timer is reset so that the timer restarts.

[0013] Multiple code segments are categorized, including process start code and process intermediate code. When the process start code, which marks the beginning of the business process, is executed, an instruction is given to initialize a method path list and a timer. The initialized method path list records the process start code, and the initialized timer tracks the runtime of the running process start code, thus monitoring its runtime. When the process intermediate code is executed, it is added to the method path list that already includes the process start code, thus recording the paths of the executed code and resetting the timer, facilitating the tracking of the intermediate code's runtime and achieving the same goal of monitoring the runtime of the process start code.

[0014] Optionally, the method further includes:

[0015] After the method path list is reported to the monitoring platform, it is determined whether the end flag of the program code of the business process is true.

[0016] If the end flag is true, terminate the execution of the program code, release the resources of the method path list, and delete the timer;

[0017] If the end flag is not true, continue running the program code.

[0018] When an exception occurs in a certain piece of program code within a business process, considering that the business process may not have ended yet (meaning other sub-codes may continue to execute), in order to completely record the executed code of the business process that has encountered an exception in the method path list, the end flag indicating whether the business process has ended is identified in the program code. This allows the program code to continue running if it is determined that the business process has not ended, thus achieving the purpose of continuing to monitor the running code. Furthermore, if it is determined that the business process has ended, the resources of the method path list are released and the timer is deleted, thereby saving device memory.

[0019] Optionally, the program code of the business process further includes code for normal process termination, and the method further includes:

[0020] When the code for the process to terminate normally is reached, the resources of the method path list are released, and the timer is deleted.

[0021] Since the normal termination code indicates from a business perspective that the business process has been completed, meaning that no sub-code of the business process is running, when the normal termination code is reached, the resources of the method path list can be released and the timer can be deleted directly to save device memory.

[0022] Optionally, the program code of the business process further includes code for abnormal process termination, and the method further includes:

[0023] When the process terminates abnormally, the abnormal termination code is added to the method path list.

[0024] The list of method paths for which the abnormal termination code of the process has been added shall be reported to the monitoring platform;

[0025] After reporting the method path list to the monitoring platform, release the resources of the method path list and delete the timer.

[0026] Since the abnormal termination code of the process indicates from the business level that the business process has been completed, that is, no sub-code of the business process is running, the method path list is reported when the abnormal termination code of the process is reached. This makes it easier to analyze the reason for the abnormal termination code of the process. After the method path list is reported, the resources of the method path list are released and the timer is deleted to save the device's running memory.

[0027] Optionally, the program code of the business process is marked with segmentation identifiers during the code development phase, and the method further includes:

[0028] During the code compilation phase, each segment of sub-code represented by the segment identifier is instrumented to insert monitoring code corresponding to each segment of sub-code. The monitoring code is used to perform operations related to the method path list and the timer during the execution of the corresponding sub-code.

[0029] Considering that the sub-codes are located in different places, each sub-code implements different functions for the method path list and timer. Therefore, during the code compilation stage, each sub-code segment is instrumented by segmentation markers so that during the actual code execution, each sub-code can execute the operations related to the method path list and timer corresponding to that sub-code.

[0030] Optionally, each of the monitoring codes includes a timeout callback function, and the step of reporting the list of method paths to the monitoring platform includes:

[0031] The timeout callback function is invoked to report the list of method paths to the monitoring platform.

[0032] By setting a timeout callback function in each monitoring code that runs only under specific events or conditions, it is easy and simple to report the method path list when the timer duration exceeds the preset duration corresponding to the currently running sub-code.

[0033] Secondly, this disclosure provides a business process exception device, wherein the program code of the business process includes multiple code segments, and the device includes:

[0034] The monitoring module is configured to, for each piece of sub-code, add the sub-code to a method path list when execution reaches it; the method path list stores all sub-codes that have been executed before the currently executing sub-code; and,

[0035] The runtime of the currently running sub-code is timed using a timer;

[0036] The first reporting module is configured to report the method path list to the monitoring platform when the timer duration exceeds the preset duration corresponding to the currently running sub-code.

[0037] The above technical solution addresses the issue that most exceptions in the business process will lead to increased code execution time. In other words, the actual execution time of each sub-code segment reflects the impact of all possible exceptions. Therefore, monitoring the runtime of each running sub-code segment improves the comprehensiveness of the monitoring. Furthermore, it collects the running sub-code in the business process to obtain a method path list. Thus, when an exception is detected in the business process, the method path list of the running sub-code at the time of the exception is reported to the monitoring platform. This facilitates developers in quickly locating the detected exception and performing business exception analysis based on the method path list.

[0038] Optionally, the multi-segment code includes process start code and process intermediate code, and the monitoring module includes:

[0039] The first running submodule is configured to initialize the method path list, add the process start code to the method path list, and initialize the timer when running to the process start code.

[0040] The second execution submodule is configured to add the intermediate code of the process to the method path list and reset the timer when the execution reaches the intermediate code of the process, so that the timer restarts counting.

[0041] Optionally, the device further includes:

[0042] The judgment module is configured to determine whether the end flag of the program code of the business process is true after the method path list is reported to the monitoring platform.

[0043] The first termination module is configured to terminate the execution of the program code, release the resources of the method path list, and delete the timer when the termination flag is true.

[0044] The continuation module is configured to continue running program code if the end flag is not true.

[0045] Optionally, the program code of the business process further includes code for normal process termination, and the device further includes:

[0046] The second termination module is configured to release the resources of the method path list and delete the timer when the normal termination code of the process is reached.

[0047] Optionally, the device further includes:

[0048] An exception execution module is configured to add the abnormal process termination code to the method path list when the execution reaches the abnormal process termination code.

[0049] The second reporting module is configured to report a list of method paths for which the abnormal termination code of the process has been added to the monitoring platform.

[0050] The third termination module is configured to release the resources of the method path list and delete the timer after the method path list is reported to the monitoring platform.

[0051] Optionally, the program code of the business process is marked with segmentation identifiers during the code development phase, and the device further includes:

[0052] The instrumentation module is configured to instrument each segment of the sub-code represented by the segment identifier during the code compilation phase, to insert monitoring code corresponding to each segment of the sub-code. The monitoring code is used to perform operations related to the method path list and the timer during the execution of the corresponding sub-code.

[0053] Optionally, each monitoring code includes a timeout callback function, and the reporting of the method path list to the monitoring platform is implemented using the following sub-modules:

[0054] The calling submodule is configured to invoke the timeout callback function to report the list of method paths to the monitoring platform.

[0055] Thirdly, this disclosure provides a computer-readable storage medium having a computer program stored thereon, characterized in that, when the program is executed by a processor, it implements the steps of the business process anomaly monitoring method described in the first aspect above.

[0056] Fourthly, this disclosure provides electronic devices, including:

[0057] A memory on which computer programs are stored;

[0058] A processor is configured to execute the computer program in the memory to implement the steps of the business process anomaly monitoring method described in the first aspect above.

[0059] Other features and advantages of this disclosure will be described in detail in the following detailed description section. Attached Figure Description

[0060] The accompanying drawings are provided to further illustrate the present disclosure and form part of the specification. They are used together with the following detailed description to explain the present disclosure, but do not constitute a limitation thereof. In the drawings:

[0061] Figure 1 This is a flowchart illustrating a business process anomaly monitoring method according to an exemplary embodiment.

[0062] Figure 2 This is another flowchart illustrating a business process anomaly monitoring method according to an exemplary embodiment.

[0063] Figure 3 This is a block diagram illustrating a business process anomaly monitoring device according to an exemplary embodiment.

[0064] Figure 4 This is a block diagram illustrating an electronic device according to an exemplary embodiment. Detailed Implementation

[0065] As the delivery business continues to grow and its volume increases, the impact of online business anomalies is also becoming more significant. To detect online anomalies early and respond quickly, monitoring of online business anomalies is necessary. As mentioned in the background section, dashboard monitoring in related technologies cannot promptly detect small-scale anomalies. With business version updates, the scope of anomaly impact will expand, eventually leading to major online incidents. While anomaly monitoring in business anomaly monitoring can detect small-scale anomalies, it relies on anomaly tracking implemented by developers during development. If developers cannot anticipate all possible anomalies, monitoring cannot guarantee the detection of all anomalies. Furthermore, when reporting the location of business anomaly code, only the location of the code actually running at the time of the anomaly can be pinpointed, which does not effectively facilitate developers' analysis of the cause of the anomaly. Therefore, this disclosure provides a method, apparatus, storage medium, and electronic device for business process anomaly monitoring.

[0066] The specific embodiments of this disclosure will be described in detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are for illustration and explanation only and are not intended to limit this disclosure.

[0067] Figure 1 This is a flowchart illustrating a business process anomaly monitoring method according to an exemplary embodiment. The program code of the business process includes multiple code segments. This method can be applied to electronic devices with processing capabilities, such as terminals or servers. Figure 1 As shown, the method may include the following steps.

[0068] In S101, for each piece of sub-code, when the sub-code is executed, the sub-code is added to the method path list. The method path list stores all the sub-codes that have been executed before the currently running sub-code. In addition, the runtime of the currently running sub-code is timed by a timer.

[0069] In practical applications, a business process is generally composed of a set of business nodes, and each business node is implemented by a piece of code. Thus, a business process corresponds to a piece of program code, and the program code corresponding to a business process can be divided into multiple code segments according to the business nodes.

[0070] For example, taking the order-grabbing business process as an example, the order-grabbing business process includes the following nodes: triggering the order acceptance process node, pre-order acceptance permission verification process node, initiating the order acceptance network request process node, order success processing process node, and order failure processing process node. Furthermore, the execution process of the order-grabbing business process can be: triggering the order acceptance process node - pre-order acceptance permission verification process node - initiating the order acceptance network request process node - order success processing process node; or it can be: triggering the order acceptance process node - pre-order acceptance permission verification process node - initiating the order acceptance network request process node - order failure processing process node. Thus, according to the execution order of each node, we can divide the code into 5 segments. And according to the execution order, we can consider the triggering the order acceptance process node as the start code of the process, the pre-order acceptance permission verification process node and the initiating the order acceptance network request process node as the intermediate code of the process, the order success processing process node as the normal end code of the process, and the order failure processing process node as the abnormal end code of the process.

[0071] In practical applications, considering that the execution time of the sub-code corresponding to each node in the business process can be estimated if it can run normally, if a piece of sub-code fails to complete or succeed for a long time, it indicates that an anomaly has occurred in the execution of that piece of code. Therefore, by monitoring the execution time of each piece of sub-code, it is possible to determine whether an anomaly has occurred in each piece of sub-code, and thus, to determine whether an anomaly has occurred in the business process.

[0072] Furthermore, in practical applications, considering that different code execution paths may lead to different causes of business exceptions, and related technologies only report the code location where the exception occurred when a business exception occurs, it is not convenient for developers to analyze the cause of the exception. Therefore, in this disclosure, for each piece of sub-code, when the execution reaches that sub-code, the sub-code is added to the method path table. This method path table stores all sub-codes that have been executed before the currently running sub-code. In this way, according to the method path table, not only can the location of the sub-code when the exception occurred be located, but also the sub-codes that were executed before the exception occurred can be determined, which facilitates developers in analyzing the cause of the exception.

[0073] In S102, a timer is used to time the runtime of the currently running sub-code.

[0074] In S103, when the timer's duration exceeds the preset duration corresponding to the currently running sub-code, the method path list is reported to the monitoring platform.

[0075] It's worth noting that the preset duration for each sub-code can be set according to actual needs. For example, in practical applications, the runtime of each sub-code can be measured multiple times during the development phase, and the preset duration for that sub-code can be set based on the values ​​obtained from these measurements. For instance, the maximum value among the multiple measurements can be taken as the preset duration for the sub-code. Choosing the maximum value is to avoid false alarms caused by setting the preset duration too small.

[0076] By employing the above technical solution, the runtime of each running sub-code can be monitored. Since most exceptions that may occur in the business process will lead to an increase in code execution time, the actual execution time of each sub-code segment can reflect the impact of all possible exceptions on the code. Therefore, monitoring the runtime of each sub-code improves the comprehensiveness of monitoring. Furthermore, the running sub-code in the business process is collected to obtain a method path list. Thus, when an exception is detected in the business process, the method path list of the running sub-code at the time of the exception is reported to the monitoring platform, facilitating developers to quickly locate the detected exception and analyze the business exception based on the method path list.

[0077] In one embodiment, the multiple code segments include process start code and process intermediate code. Figure 1 S101 can further include: First, when the process starts, the method path list is initialized, the process start code is added to the method path list, and the timer is initialized. Second, when the process is interrupted, the process interrupted code is added to the method path list, and the timer is reset so that the timer restarts.

[0078] It's worth noting that the process start code represents the first piece of code that needs to be executed to implement the business process. The process intermediate code represents the intermediate sub-codes that need to be executed among all the sub-codes included in the business process to implement the business process.

[0079] Understandably, when starting the execution of the first business node in a business process (corresponding to the process start code), a method path list needs to be initialized to collect the code that has been executed in that business process. At the same time, a timer also needs to be initialized to keep track of the runtime of the currently running sub-code (i.e., the process start code).

[0080] In addition, when running the intermediate code of the process, the intermediate code of the process needs to be added to the method path list first, and the timer needs to be reset so that the timer can start timing for the currently running intermediate code of the process.

[0081] It's worth noting that if the currently running sub-code is the first intermediate code in the process, then the method path list should only store the process start code. Similarly, if the currently running sub-code is the second intermediate code in the process, then the method path list should store both the process start code and the first intermediate code.

[0082] In one embodiment, Figure 2 This is another flowchart illustrating a business process anomaly monitoring method according to an exemplary embodiment, such as... Figure 2 As shown, the method further includes the following steps.

[0083] In S201, after reporting the list of method paths to the monitoring platform, it is determined whether the end flag of the program code of the business process is true.

[0084] In S202, the execution of the program code is terminated, the resources of the method path list are released, and the timer is deleted.

[0085] In S203, continue running the program code.

[0086] It should be noted that if the end flag is true, S202 is executed; if the end flag is not true, S203 is executed.

[0087] In this disclosure, when an exception is detected in a sub-code of a business process and reported to the method path table on the monitoring platform, considering that the business process is not yet finished and other sub-codes may continue to execute, to facilitate developers' overall analysis of the cause of the code exception and which sub-codes the exception might affect, the code path is continuously collected and recorded in the method path list while the business process is still ongoing; and when the business process ends, the resources in the method path list can be directly released and the timer deleted to save device memory. Based on this, this disclosure determines whether the end flag of the business process's program code is true, and determines whether to release the resources in the method path list and delete the timer based on whether the end flag is true.

[0088] It is worth noting that during the development phase, developers can mark the end flag of each sub-code segment differently when editing the code. The end flag of sub-code that does not indicate the end of the business process is set to a false value, while the end flag of sub-code that indicates the end of the business process is set to a true value.

[0089] For example, in end=false and end=true, end is the end flag, while false and true are the end flag values. False can be a false value, and true can be a true value.

[0090] In one embodiment, the program code of the business process also includes normal process termination code. Furthermore, the method may also include releasing the resources of the method path list and deleting the timer when the normal process termination code is reached.

[0091] In this disclosure, if the business process reaches the code indicating normal process termination, signifying that the business process has been successfully executed, and no further sub-code runs, then there is no need to monitor or record the execution of sub-codes. Therefore, to save device memory, when the normal process termination code is reached, the resources of the method path list can be released and the timer deleted, thereby saving device memory.

[0092] In one embodiment, the program code of the business process further includes code for abnormal process termination, and the method further includes:

[0093] First, when the process terminates abnormally, add the abnormal termination code to the method path list.

[0094] Secondly, the list of method paths for which abnormal process termination code has been added should be reported to the monitoring platform.

[0095] Next, after reporting the method path list to the monitoring platform, release the resources of the method path list and delete the timer.

[0096] In this disclosure, if a business process reaches the abnormal termination code, it signifies that the business process has been completed. Unlike reaching the normal termination code, this indicates a failure from a business perspective. For example, in an order-grabbing business, successfully grabbing an order means the business process has successfully completed, equivalent to reaching the normal termination code; failing to grab an order means the business process has not successfully completed, equivalent to reaching the abnormal termination code. Similar to reaching the normal termination code, no sub-codes in this business process run, meaning there's no need to monitor or record the execution of sub-codes. Therefore, to save device memory, when the abnormal termination code is reached, the resources of the method path list can be directly released and the timer deleted, thus conserving device memory.

[0097] In addition, to facilitate developers in analyzing the reasons for abnormal business termination, it is necessary to add the abnormal termination code of the process to the method path list and report the method path list with the abnormal termination code of the process to the monitoring platform.

[0098] In one embodiment, the program code of the business process is marked with segment identifiers during the code development phase. Accordingly, the method further includes: during the code compilation phase, instrumenting each sub-code segment represented by the segment identifier to insert monitoring code corresponding to each sub-code segment.

[0099] It should be noted that instrumentation involves inserting probes into the program while ensuring the original logical integrity of the program under test. A probe is essentially a code segment that collects information, which can be an assignment statement or a function call that collects coverage information. The test objective is achieved by executing the probe.

[0100] In this disclosure, we consider that the code executed differs depending on the location of the sub-code. For example, the code at the beginning of the process needs to initialize the method path list, while this initialization is not required in other sub-codes. Therefore, to implement different operations for different sub-codes, different monitoring code needs to be inserted into each sub-code. Different segmentation identifiers can represent the position of different sub-codes within the code included in the entire business process; that is, segmentation identifiers can be used to instrument the sub-codes included in the business process. These segmentation identifiers can be added by developers during the code development phase for each sub-code.

[0101] It should be noted that the monitoring code is used to execute operations related to the method path list and timers during the execution of the corresponding sub-code. For example, taking the program code following the above business process, including the code for abnormal program termination, the monitoring code executing the code for normal process termination performs the following operations related to the method path list: when the abnormal process termination code is encountered, it adds the abnormal process termination code to the method path list; and reports the method path list containing the abnormal process termination code to the monitoring platform. The monitoring code executing the code for normal process termination performs the following operations related to timers: after reporting the method path list to the monitoring platform, it releases the resources of the method path list and deletes the timers.

[0102] By using the instrumentation method described above, corresponding monitoring code can be inserted into sub-code based on different segmentation identifiers, so as to ensure that the monitoring code of each sub-code can perform operations related to the method path list and timers during the execution of each sub-code.

[0103] In one embodiment, each monitoring code includes a timeout callback function, and reporting the method path list to the monitoring platform may include: calling the timeout callback function to report the method path list to the monitoring platform.

[0104] It should be noted that a callback function is a function called through a function pointer. It runs only when a specific event or condition occurs, and is used to respond to that event or condition.

[0105] In this disclosure, when the timer's duration exceeds the preset duration corresponding to the currently running sub-code, it can be regarded as a condition or an event. The timeout callback function responds to the condition or event, and the result of the response is to report the method path list to the monitoring platform.

[0106] In some implementations, to facilitate developers in prioritizing the resolution of frequently occurring exceptions in the business process code, the number of times each method path list is reported can be counted within a preset time period. Based on the number of times each method path list is reported within the preset time period, a priority is set for each method path list, and an exception list is generated. This exception list is a list of various method path lists arranged in descending order of priority. Through this exception list, developers can intuitively identify the method path list with high-frequency exception types and prioritize the analysis and processing of this method path list, which can efficiently resolve most of the exceptions that occur in the business process.

[0107] It should be understood that the higher the frequency, the higher the priority.

[0108] Based on the same inventive concept, this disclosure provides a business process anomaly monitoring device. Figure 3 This is a block diagram illustrating a business process anomaly monitoring device according to an exemplary embodiment. Figure 3 As shown, the business process anomaly monitoring device 300 may include:

[0109] The monitoring module 301 is configured to, for each segment of the sub-code, add the sub-code to a method path list when execution reaches the sub-code; the method path list stores all sub-codes that have been executed before the currently executing sub-code; and,

[0110] The runtime of the currently running sub-code is timed using a timer;

[0111] The first reporting module 302 is configured to report the method path list to the monitoring platform when the timer's duration exceeds the preset duration corresponding to the currently running sub-code.

[0112] Optionally, the multi-segment code includes process start code and process intermediate code, and the monitoring module 301 includes:

[0113] The first running submodule is configured to initialize the method path list, add the process start code to the method path list, and initialize the timer when running to the process start code.

[0114] The second execution submodule is configured to add the intermediate code of the process to the method path list and reset the timer when the execution reaches the intermediate code of the process, so that the timer restarts counting.

[0115] Optionally, the business process anomaly monitoring device 300 may also include:

[0116] The judgment module is configured to determine whether the end flag of the program code of the business process is true after the method path list is reported to the monitoring platform.

[0117] The first termination module is configured to terminate the execution of the program code, release the resources of the method path list, and delete the timer when the termination flag is true.

[0118] The continuation module is configured to continue running program code if the end flag is not true.

[0119] Optionally, the program code of the business process further includes code for normal process termination, and the business process anomaly monitoring device 300 may further include:

[0120] The second termination module is configured to release the resources of the method path list and delete the timer when the normal termination code of the process is reached.

[0121] Optionally, the business process anomaly monitoring device 300 may further include:

[0122] An exception execution module is configured to add the abnormal process termination code to the method path list when the execution reaches the abnormal process termination code.

[0123] The second reporting module is configured to report a list of method paths for which the abnormal termination code of the process has been added to the monitoring platform.

[0124] The third termination module is configured to release the resources of the method path list and delete the timer after the method path list is reported to the monitoring platform.

[0125] Optionally, the program code of the business process is marked with segmentation identifiers during the code development phase, and the business process anomaly monitoring device 300 may further include:

[0126] The instrumentation module is configured to instrument each segment of the sub-code represented by the segment identifier during the code compilation phase, to insert monitoring code corresponding to each segment of the sub-code. The monitoring code is used to perform operations related to the method path list and the timer during the execution of the corresponding sub-code.

[0127] Optionally, each monitoring code includes a timeout callback function, and the reporting of the method path list to the monitoring platform can be implemented using the following sub-modules:

[0128] The calling submodule is configured to invoke the timeout callback function to report the list of method paths to the monitoring platform.

[0129] Regarding the apparatus in the above embodiments, the specific manner in which each module performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated upon here.

[0130] By employing the above technical solution, the runtime of each running sub-code can be monitored. Since most exceptions that may occur in the business process will lead to an increase in code execution time, the actual execution time of each sub-code segment can reflect the impact of all possible exceptions on the code. Therefore, monitoring the runtime of each sub-code improves the comprehensiveness of monitoring. Furthermore, the running sub-code in the business process is collected to obtain a method path list. Thus, when an exception is detected in the business process, the method path list of the running sub-code at the time of the exception is reported to the monitoring platform, facilitating developers to quickly locate the detected exception and analyze the business exception based on the method path list.

[0131] Based on the same inventive concept, this disclosure also provides a computer-readable storage medium storing a computer program thereon, characterized in that, when the program is executed by a processor, it implements the steps of the business process anomaly monitoring method described in the above method embodiments.

[0132] Based on the same inventive concept, this disclosure also provides an electronic device, comprising:

[0133] A memory on which computer programs are stored;

[0134] A processor is configured to execute the computer program in the memory to implement the steps of the business process anomaly monitoring method described in the above method embodiments.

[0135] Figure 4This is a block diagram illustrating an electronic device 400 according to an exemplary embodiment. For example, the electronic device 400 may be a mobile phone, a computer, a tablet device, etc.

[0136] Reference Figure 4 The electronic device 400 may include one or more of the following components: processing component 402, memory 404, power component 406, multimedia component 408, audio component 410, input / output (I / O) interface 412, and communication component 414.

[0137] Processing component 402 typically controls the overall operation of electronic device 400, such as operations associated with display, data communication, and recording. Processing component 402 may include one or more processors 420 to execute instructions to complete all or part of the steps of the aforementioned business anomaly monitoring method. Furthermore, processing component 402 may include one or more modules to facilitate interaction between processing component 402 and other components. For example, processing component 402 may include a multimedia module to facilitate interaction between multimedia component 408 and processing component 402.

[0138] Memory 404 is configured to store various types of data to support the operation of electronic device 400. Examples of such data include instructions for any application or method operating on electronic device 400. Memory 404 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0139] Power component 406 provides power to various components of electronic device 400. Power component 406 may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to device 400.

[0140] Multimedia component 408 includes a screen that provides an output interface between the electronic device 400 and the user. In some embodiments, the screen may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, the screen may be implemented as a touchscreen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touches, swipes, and gestures on the touch panel. The touch sensors may sense not only the boundaries of the touch or swipe action but also the duration and pressure associated with the touch or swipe operation.

[0141] Audio component 410 is configured to output and / or input audio signals. For example, audio component 410 includes a microphone (MIC) configured to receive external audio signals when electronic device 400 is in an operating mode, such as a voice recognition mode. The received audio signals may be further stored in memory 404 or transmitted via communication component 414. In some embodiments, audio component 410 also includes a speaker for outputting audio signals.

[0142] Input / output (I / O) interface 412 provides an interface between processing component 402 and peripheral interface modules, such as keyboards, click wheels, buttons, etc. These buttons may include, but are not limited to, home buttons, volume buttons, power buttons, and lock buttons.

[0143] Communication component 414 is configured to facilitate wired or wireless communication between electronic device 400 and other devices. Electronic device 400 can access wireless networks based on communication standards, such as WiFi, 2G, or 3G, or combinations thereof. In one exemplary embodiment, communication component 414 receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In one exemplary embodiment, communication component 414 also includes a near-field communication (NFC) module to facilitate short-range communication. For example, the NFC module may be implemented based on radio frequency identification (RFID) technology, Infrared Data Association (IrDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology, and other technologies.

[0144] In an exemplary embodiment, the electronic device 400 may be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to perform the above-described method for recognizing entities in text.

[0145] In an exemplary embodiment, a non-transitory computer-readable storage medium including instructions is also provided, such as a memory 404 including instructions that can be executed by a processor 420 of an electronic device 400 to complete the method for identifying entities in text. For example, the non-transitory computer-readable storage medium may be a ROM, random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device, etc.

[0146] In another exemplary embodiment, a computer program product is also provided, the computer program product comprising a computer program executable by a programmable device, the computer program having a code portion for performing the above-described business anomaly monitoring method when executed by the programmable device.

[0147] The preferred embodiments of this disclosure have been described in detail above with reference to the accompanying drawings. However, this disclosure is not limited to the specific details of the above embodiments. Within the scope of the technical concept of this disclosure, various simple modifications can be made to the technical solutions of this disclosure, and these simple modifications all fall within the protection scope of this disclosure.

[0148] It should also be noted that the various specific technical features described in the above embodiments can be combined in any suitable manner without contradiction. To avoid unnecessary repetition, this disclosure will not describe the various possible combinations separately.

[0149] Furthermore, various different embodiments of this disclosure can be combined in any way, as long as they do not violate the spirit of this disclosure, they should also be regarded as the content disclosed in this disclosure.

Claims

1. A method of business process anomaly monitoring, characterized by, The program code of the business process comprises multiple sub-codes, the multiple sub-codes comprise process start code, process intermediate code, process normal end code and process abnormal end code, and the positions of the sub-codes are different, and the executed codes are different, and the method comprises: In the code development stage, the multiple sub-codes are marked with segment identifiers representing the logical positions of the multiple sub-codes in the business process; In the code compiling stage, the corresponding sub-codes are instrumented according to the segment identifiers to insert monitoring codes for performing monitoring operations, the instrumenting is inserting a code segment for information collection in the program on the basis of ensuring the original logical integrity of the program to be tested, the method path list and the timer are initialized when the process start code is run, and when the process abnormal end code is run, the process abnormal end code is added to the method path list, and the method path list with the added process abnormal end code is reported to the monitoring platform; When the business process is running, the following steps are performed through the monitoring codes: For each of the sub-codes, when the sub-code is run, the sub-code is added to the method path list, and all the sub-codes that have been run before the currently running sub-code are stored in the method path list in the order of execution; The running duration of the currently running sub-code is timed by the timer; When the timing duration of the timer exceeds the preset duration corresponding to the currently running sub-code, a timeout callback function is called; In response to the timeout callback function, the following steps are performed: the method path list is reported to the monitoring platform, On the side of the monitoring platform, the following steps are performed: Within a preset time period, the reporting frequency of each method path list is counted; According to the reporting frequency, a processing priority is set for each method path list, the higher the frequency, the higher the priority, and an abnormal list is generated in the order of priority.

2. The method of claim 1, wherein, The multiple sub-codes comprise process start code and process intermediate code, and the method comprises, for each of the sub-codes, when the sub-code is run, adding the sub-code to the method path list, comprising: When the process start code is run, the process start code is added to the method path list; When the process intermediate code is run, the process intermediate code is added to the method path list, and the timer is reset so that the timer starts timing again.

3. The method of claim 1, wherein, The method further comprises: After the method path list is reported to the monitoring platform, it is judged whether an end flag of the program code of the business process is a true value; In the case that the end flag is a true value, the running of the program code is terminated, and the resources of the method path list are released, and the timer is deleted; In the case that the end flag is not a true value, the program code is continuously run.

4. The method of claim 1, wherein, The program code of the business process further comprises process normal end code, and the method further comprises: When the process normal end code is run, the resources of the method path list are released, and the timer is deleted.

5. The method of claim 1, wherein, The program code of the business process further comprises process abnormal end code, and the method further comprises: After reporting the method path list to the monitoring platform, resources of the method path list are released, and the timer is deleted.

6. The method of claim 1, wherein, The program code of the business process is marked with a segment identifier in a code development stage, and the method further comprises: In a code compilation stage, each segment of the sub-code represented by the segment identifier is instrumented to insert monitoring code corresponding to each segment of the sub-code, and the monitoring code is used to perform operations related to the method path list and the timer in a process of running the corresponding sub-code.

7. A computer-readable storage medium having stored thereon a computer program, characterized in that The program is executed by the processor to implement the steps of the business process exception monitoring method in any one of claims 1-6.

8. An electronic device, comprising: Comprise: a memory having a computer program stored thereon; a processor configured to execute the computer program in the memory to implement the steps of the business process exception monitoring method in any one of claims 1-6.

Images