Service exception analysis method and device, equipment, storage medium and program product

Abstract

The application relates to a service exception analysis method and device, equipment, a storage medium and a program product. The method comprises the following steps: in the case that a target service appears an exception, determining a task flow corresponding to the target service and an exception time period, and acquiring an exception log obtained by executing the task flow in the exception time period; executing the task flow in a test environment corresponding to the target service to obtain a test log; and determining an exception type of the target service according to the exception log and the test log. The method can quickly and accurately locate the exception type when the service is abnormal.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a service anomaly analysis method, apparatus, device, storage medium, and program product. Background Technology

[0002] In computer systems, service stability and performance are crucial. However, in practical applications, due to the complexity and diversity of online environments, service anomalies occur frequently. When service anomalies occur, it is of great significance to quickly and accurately locate the problem and reduce troubleshooting time. Summary of the Invention

[0003] Therefore, it is necessary to provide a service anomaly analysis method, device, equipment, storage medium, and program product that can quickly and accurately locate the anomaly type when a service is abnormal, in order to address the above-mentioned technical problems.

[0004] Firstly, this application provides a service anomaly analysis method, the method comprising:

[0005] In the event of an anomaly in the target service, determine the task flow corresponding to the target service and the abnormal time period, and obtain the anomaly logs obtained by executing the task flow during the abnormal time period.

[0006] The task flow is executed in the test environment corresponding to the target service to obtain test logs;

[0007] Based on the exception logs and the test logs, determine the exception type of the target service.

[0008] In this embodiment, when a service malfunctions, taking the target service as an example, the problem is attempted to be reproduced and the type of malfunction is determined based on the exception logs obtained from executing the task flow online and the test logs obtained from executing the task flow in the test environment. For example, if the problem is successfully reproduced, it indicates that the target service is malfunctioning; if the problem cannot be successfully reproduced, the malfunction of the target service can be ruled out, and environmental issues should be considered instead. This allows for quick and accurate location of the problem, reducing troubleshooting time.

[0009] In one embodiment, determining the exception type of the target service based on the exception log and the test log includes:

[0010] Compare the first service execution status included in the exception log with the second service execution status included in the test log;

[0011] If the first service execution status is the same as the second service execution status, then the exception type is determined to be a service exception;

[0012] If the execution status of the first service is different from that of the second service, then the exception type is determined to be an environmental exception.

[0013] In this embodiment, when the target service is abnormal, the first service execution status included in the exception log can be compared with the second service execution status included in the test log to quickly and conveniently determine the exception type of the target service. The exception type includes service exception or environment exception. Service exception refers to the target service itself having logical problems, etc., while environment exception refers to excluding the logical problems of the target service itself and considering the influence of environmental factors. The method of determining the exception type has a small amount of computation, which is conducive to improving the speed of exception type determination and saving server computing resources.

[0014] In one embodiment, the method further includes:

[0015] During the execution of the task flow in the test environment, first resource usage data is acquired;

[0016] In the case where the anomaly type is an environmental anomaly, obtain the second resource usage data when the task flow is executed during the anomaly time period;

[0017] The first resource usage data is compared with the second resource usage data to determine resource bottleneck information.

[0018] In this embodiment, when the anomaly type is environmental anomaly, the correlation between the anomaly and system resources can be analyzed to locate resource bottlenecks, improve the accuracy of anomaly analysis, and facilitate system performance optimization. Furthermore, it can promptly identify potential system performance issues, improving system stability and reliability.

[0019] In one embodiment, the method further includes:

[0020] According to the preset data format, the anomaly type and the resource bottleneck information are output, and the anomaly type and the resource bottleneck information are used for system performance analysis.

[0021] In this embodiment, when a performance bottleneck occurs, the exception type and resource bottleneck information are output for easy viewing and analysis by the user. This helps to analyze the cause of the performance bottleneck and enable effective measures to be taken for optimization and repair.

[0022] In one embodiment, the step of executing the task flow in the test environment corresponding to the target service to obtain test logs includes:

[0023] The task flow is triggered and executed in the test environment according to a preset trigger frequency to obtain the test log. The trigger frequency is greater than the execution frequency of the task flow during the abnormal time period.

[0024] Currently, while most testing environments strive to simulate online environments, the uniqueness and complexity of online environments make it difficult for testing environments to completely replicate them. This leads to situations where service issues cannot be reproduced. Even if the testing environment simulates various online conditions as closely as possible, there may still be some subtle differences. These differences may prevent the accurate reproduction of problems. In this embodiment, increasing the triggering frequency of task flows is beneficial for the reproduction of service issues and further improves the accuracy of service anomaly analysis.

[0025] In one embodiment, the task flow includes multiple tasks, and the task flow is triggered and executed in the test environment according to a preset trigger frequency to obtain the test log, including:

[0026] For each task, the task is repeatedly triggered and executed according to the triggering frequency to obtain the test log. The tasks include starting and stopping tasks, page-triggered user operation tasks, or interface call tasks.

[0027] In practical applications, online environments are often extremely complex, making it very difficult to reproduce problems. This embodiment attempts to reproduce service problems and improve the success rate of service anomaly analysis by repeatedly triggering service anomaly conditions and executing tasks such as start / stop tasks, page-triggered user operation tasks, or interface call tasks.

[0028] Secondly, this application provides a service anomaly analysis device, the device comprising:

[0029] The first determining module is used to determine the task flow and abnormal time period corresponding to the target service when the target service is abnormal, and to obtain the abnormal log obtained by executing the task flow during the abnormal time period.

[0030] The execution module is used to execute the task flow in the test environment corresponding to the target service and obtain test logs;

[0031] The second determining module is used to determine the exception type of the target service based on the exception log and the test log.

[0032] Thirdly, this application provides a computer device including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the method described in the first aspect above.

[0033] Fourthly, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method described in the first aspect above.

[0034] Fifthly, this application provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the method described in the first aspect above.

[0035] The aforementioned service anomaly analysis method, apparatus, device, storage medium, and program product, when a target service experiences an anomaly, determines the task flow and abnormal time period corresponding to the target service, and obtains the anomaly logs obtained from executing the task flow during the abnormal time period. Then, the task flow is executed in the test environment corresponding to the target service to obtain test logs. Based on the anomaly logs and the test logs, the anomaly type of the target service can be determined. Thus, in this embodiment, when a service anomaly occurs, taking the target service as an example, the problem is attempted to be reproduced and the anomaly type determined based on the anomaly logs obtained from executing the task flow online and the test logs obtained from executing the task flow in the test environment. For example, if the problem is successfully reproduced, it indicates that the target service is anomaly; if the problem cannot be successfully reproduced, the anomaly of the target service can be ruled out, and environmental issues can be considered instead. This allows for quick and accurate location of the problem, reducing troubleshooting time. Attached Figure Description

[0036] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the drawings used in the description of the embodiments of this application or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0037] Figure 1 This is a diagram illustrating the application environment of a service anomaly analysis method in one embodiment.

[0038] Figure 2 This is a flowchart illustrating a service anomaly analysis method in one embodiment;

[0039] Figure 3 This is a flowchart illustrating the service anomaly analysis method in another embodiment;

[0040] Figure 4 This is a flowchart illustrating the process of determining resource bottleneck information in another embodiment;

[0041] Figure 5 This is a flowchart illustrating the service anomaly analysis method in another embodiment;

[0042] Figure 6This is a flowchart illustrating the service anomaly analysis method in another embodiment;

[0043] Figure 7 This is a structural block diagram of a service anomaly analysis device in one embodiment;

[0044] Figure 8 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0045] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0046] In computer systems, service stability and performance are crucial. However, in practical applications, due to the complexity and diversity of online environments, service anomalies occur frequently. When service anomalies occur, it is of great significance to quickly and accurately locate the problem and reduce troubleshooting time.

[0047] In view of this, embodiments of this application provide a service anomaly analysis method, apparatus, device, storage medium, and program product that can quickly and accurately locate the anomaly type when a service anomaly occurs.

[0048] The service anomaly analysis method provided in this application embodiment can be applied to, for example, Figure 1 The implementation environment shown includes servers, which can be implemented using standalone servers or server clusters composed of multiple servers. A data storage system stores the data that the servers need to process. The data storage system can be integrated onto the server or hosted in the cloud or on other network servers.

[0049] In other possible implementations, the service anomaly analysis method provided in this application embodiment can also be applied to a terminal. The terminal can be, but is not limited to, various personal computers, laptops, smartphones, tablets, IoT devices, and portable wearable devices. IoT devices can be smart speakers, smart TVs, smart air conditioners, smart in-vehicle devices, etc. Portable wearable devices can be smartwatches, smart bracelets, head-mounted devices, etc.

[0050] In one exemplary embodiment, such as Figure 2 As shown, a service anomaly analysis method is provided, which can be applied to... Figure 1 Taking the server in the example, the explanation includes the following steps 201 to 203. Wherein:

[0051] Step 201: In the event of an anomaly in the target service, determine the task flow and the abnormal time period corresponding to the target service, and obtain the anomaly logs obtained from executing the task flow during the abnormal time period.

[0052] A service can be a single program or a set of related programs, or it can be a network-based distributed service. In this embodiment, the target service is any service that malfunctions in the online environment.

[0053] When an online target service encounters an anomaly, the server first determines the task flow corresponding to the target service.

[0054] Optionally, the server can read the task flow from the relevant configuration information of the target service; alternatively, the server can obtain the underlying calling logic of the target service. For example, the server can obtain the underlying calling logic of the target service based on its identifier and create a task flow based on the underlying calling logic. The task flow is as follows: submitting an API (Application Programming Interface) request from the page -> calling the LDAP (Lightweight Directory Access Protocol) module -> user authentication -> sssd (System Security Services Daemon) clears the cache and restarts the sssd service.

[0055] When the target service encounters an anomaly, the server also determines the time period of the anomaly and obtains the anomaly logs obtained from the task flow executed during that time period.

[0056] For example, the server can obtain the service logs generated by running each service, identify the target service that is abnormal and the abnormal time period when the target service is abnormal from the service logs, and the server can also export the running logs of the target service during the abnormal time period from the service logs to obtain the above-mentioned abnormal logs.

[0057] Step 202: Execute the task flow in the test environment corresponding to the target service to obtain test logs.

[0058] In this embodiment of the application, the test environment can be pre-built.

[0059] Optionally, resource usage data can be obtained when the online cluster executes the task flow corresponding to the target service during the above-mentioned abnormal time period. This resource usage data may include at least one of the cluster's average CPU utilization, average memory utilization, and average disk utilization during the abnormal time period. Then, based on the resource usage data when the cluster executes the task flow, a test environment can be built. For example, the resource usage level can be determined based on the resource usage data when the cluster executes the task flow, and then the resource usage data of the test environment can be flexibly configured within the resource usage level.

[0060] Alternatively, the testing environment can also be a general testing environment that can be used by all services; no specific restrictions are placed on the testing environment here.

[0061] After configuring the test environment corresponding to the target service, execute the task flow in the test environment and use the service logs obtained from executing the task flow as test logs.

[0062] Step 203: Determine the exception type of the target service based on the exception logs and test logs.

[0063] The server attempts to reproduce the problem and determine the type of exception by analyzing the exception logs obtained from executing the task flow on the online cluster and the test logs obtained from executing the task flow in the test environment.

[0064] If both the exception logs and test logs show the same problem, then the issue has been successfully reproduced, indicating that the target service is faulty. If the problem cannot be reproduced, then the faulty target service cannot be ruled out, meaning the issue is not a logical problem with the target service itself, and the influence of environmental factors should be considered.

[0065] Optionally, the server can visualize the exception logs and test logs, allowing users to determine the exception type based on the displayed exception logs and test logs. The server can also obtain the exception type based on the human-computer interaction page.

[0066] Optionally, the server can also input exception logs and test logs into the prediction model, which will then predict the exception type of the target service.

[0067] Optionally, the server can also send exception logs and test logs to an external device, which can then determine the exception type of the target service and return that exception type to the server, and so on.

[0068] Overall, the above embodiments, when the target service malfunctions, attempt to reproduce the problem and determine the type of anomaly by using exception logs obtained from executing the task flow online and test logs obtained from executing the task flow in the test environment. For example, if the problem is successfully reproduced, it indicates that the target service is malfunctioning; if the problem cannot be successfully reproduced, it can be ruled out that the target service is malfunctioning, and environmental issues should be considered instead. This allows for quick and accurate location of the problem, reducing troubleshooting time.

[0069] In one embodiment, based on Figure 2 The illustrated embodiment can be found in [reference]. Figure 3 Step 203 may include Figure 3 Steps 301, 302, and 303 are shown below:

[0070] Step 301: Compare the first service execution status included in the exception log with the second service execution status included in the test log.

[0071] In this embodiment of the application, the exception log obtained by the online cluster executing the task flow corresponding to the target service includes the first service execution status of the target service. The first service execution status includes the task execution result of the cluster executing the task flow, and may also include error information during the execution process. Similarly, the second service execution status contains similar content to the first service execution status.

[0072] The server compares the first service execution status included in the exception log with the second service execution status included in the test log to obtain the comparison result.

[0073] Step 302: If the execution status of the first service is the same as that of the second service, then the exception type is determined to be a service exception.

[0074] If the comparison result shows that the execution status of the first service is the same as that of the second service, it means that the target service has the same problem whether it is running in the online environment or the test environment. This indicates that the problem of the target service has been successfully reproduced, that is, the target service itself may have logical problems, etc. In this case, the exception type is determined to be a service exception.

[0075] Furthermore, in the case of a service exception, the task flow corresponding to the target service can be repeatedly executed in the test environment to reproduce the service exception. This allows developers to modify the logic code of the target service based on the service exception. Developers can conduct in-depth investigations into the logic of the target service itself, analyze the problems that cause the service to fail to start, and find potential logical vulnerabilities or unreasonable aspects by carefully analyzing the design architecture, code implementation, and business processes of the target service, and then fix the exception.

[0076] Step 303: If the execution status of the first service is different from that of the second service, then the exception type is determined to be an environment exception.

[0077] If the comparison result shows that the execution status of the first service is different from that of the second service, it indicates that the target service has a problem when running in the online environment, but does not have a problem when running in the test environment. In this case, we can rule out the logical problem of the target service itself and consider the influence of environmental factors, that is, determine the exception type as an environmental exception.

[0078] In this embodiment, when the target service is abnormal, the first service execution status included in the exception log can be compared with the second service execution status included in the test log to quickly and conveniently determine the exception type of the target service. The exception type includes service exception or environment exception. Service exception refers to the target service itself having logical problems, etc., while environment exception refers to excluding the logical problems of the target service itself and considering the influence of environmental factors. The method of determining the exception type has a small amount of computation, which helps to improve the speed of exception type determination and save server computing resources.

[0079] In one embodiment, based on Figure 3 The illustrated embodiment can be found in [reference]. Figure 4 In this embodiment, the service anomaly analysis method also includes Figure 4 Steps 401 to 403 are shown below:

[0080] Step 401: During the execution of the task flow in the test environment, obtain the first resource usage data.

[0081] The first resource usage data may include at least one of the server's average CPU utilization, average memory utilization, and average disk usage when the server is executing a task flow in the test environment.

[0082] Step 402: In the case of an exception type of environmental exception, obtain the second resource usage data when the task flow is executed during the exception time period.

[0083] The server can also obtain second resource usage data when the online cluster executes the task flow corresponding to the target service during the above-mentioned abnormal time period. Similar to the first resource usage data, the second resource usage data may include at least one of the cluster's average CPU utilization, average memory utilization, and average disk utilization during the abnormal time period.

[0084] Step 403: Compare the first resource usage data with the second resource usage data to determine the resource bottleneck information.

[0085] In this embodiment of the application, the resource changes can be monitored by combining the first resource usage data and the second resource usage data, and abnormal resources can be found. That is, the correlation between service abnormalities and system resources can be found.

[0086] For example, the server compares the first resource usage data with the second resource usage data to analyze the hardware resource usage. If a bottleneck occurs in a certain resource, the resource bottleneck information can be determined. This resource bottleneck information may include, for example, the resource name and resource attribute information of the resource that is experiencing the bottleneck.

[0087] In this embodiment of the application, the server can use a variety of resource monitoring methods to compare the first resource usage data with the second resource usage data to locate the resource bottleneck of the cluster (or performance bottleneck, which refers to the key factors that limit the overall performance improvement of the system during the operation of the system (i.e., the online cluster). These factors may lead to problems such as extended system response time, reduced throughput, and excessively high or low resource utilization). Resource monitoring methods include hardware resource monitoring graphs of the operation and maintenance platform.

[0088] Optionally, the abnormal time period can be combined with the time of the resource bottleneck for analysis, and the specific location of the resource bottleneck can be located based on the analysis results.

[0089] In this embodiment, when the anomaly type is environmental anomaly, the correlation between the anomaly and system resources can be analyzed to locate resource bottlenecks, improve the accuracy of anomaly analysis, and facilitate system performance optimization. Furthermore, it can promptly identify potential system performance problems, improving system stability and reliability.

[0090] Optionally, the server can also use log analysis tools, such as the ELK (Elasticsearch, Logstash, Kibana) stack, to perform real-time or offline analysis of service logs in the online environment. By analyzing metrics such as request response time, error messages, and resource usage in the service logs, performance bottlenecks can be identified.

[0091] It can analyze historical data to identify long-standing performance issues and can be integrated with other monitoring systems to provide more comprehensive performance analysis.

[0092] Optionally, the server can also use stress testing tools to simulate load tests on the online environment. By gradually increasing the load, the performance of the online environment under different loads can be observed to identify performance bottlenecks. Stress tests can be conducted before the target service goes live or periodically after the target service goes live to ensure that the cluster can withstand the expected load. This can proactively identify cluster performance bottlenecks, avoid problems in the actual production environment, test the stability and reliability of the cluster under high load, and help optimize cluster configuration and adjust performance parameters.

[0093] Optionally, after step 403, the server can also output the exception type and resource bottleneck information according to a preset data format. The exception type and resource bottleneck information are used for system performance analysis.

[0094] The server outputs the exception type and resource bottleneck information. For example, the exception type and resource bottleneck information can be output as a text report to facilitate the operation and maintenance personnel to analyze system performance. Performance analysis can include analyzing the system resource usage and performance indicators.

[0095] For example, relevant information can be collected online, and the output anomaly types and resource bottleneck information can reflect the resource usage and performance status of the online cluster. This information can then be combined with the relevant information collected online to analyze the online environment.

[0096] For example, during the information gathering phase, it was discovered that disk resources were scarce, resulting in a large number of write queues and causing CPU usage to escalate from 10% to over 20%. Further analysis of the processes consuming disk resources using relevant tools revealed that a large number of copy commands were being executed, consuming disk resources.

[0097] In this embodiment of the application, when a performance bottleneck occurs, the exception type and resource bottleneck information are output, which is convenient for users to view and analyze. This helps to analyze the cause of the performance bottleneck so that effective measures can be taken to optimize and repair it.

[0098] Furthermore, the embodiments of this application are highly scalable, and monitoring various hardware resources can be achieved through scripts or monitoring platforms. Resource bottlenecks can depend on a variety of processes, but the troubleshooting approach is fixed and applicable to analyzing performance bottlenecks in various environments.

[0099] In one embodiment, based on any of the above embodiments, see [link to embodiment]. Figure 5 In this embodiment, step 202 includes Figure 5 Step 501 shown:

[0100] Step 501: Trigger the execution task flow in the test environment according to the preset trigger frequency to obtain the test log.

[0101] Among them, the triggering frequency is greater than the execution frequency of the task flow during the abnormal time period.

[0102] In this embodiment of the application, when executing the task flow in the test environment, the triggering frequency can be increased. For example, for restarting a service, the frequency of restarting the service can be adjusted from once every 60 seconds to once every 30 seconds, etc. The triggering frequency can be flexibly set for different services, making the testing method flexible.

[0103] Currently, while most testing environments strive to simulate online environments, the uniqueness and complexity of online environments make it difficult for testing environments to completely replicate them. This leads to situations where service issues cannot be reproduced. Even if the testing environment simulates various online conditions as closely as possible, there may still be some subtle differences. These differences may prevent the accurate reproduction of problems. In this embodiment, increasing the triggering frequency of task flows is beneficial for reproducing service issues and further improves the accuracy of service anomaly analysis.

[0104] As one implementation method, a task flow can include multiple tasks. For example, as exemplified above, a task flow could be: submitting an API request via a page -> invoking the LDAP module -> user authentication -> clearing the sssd cache and restarting the sssd service. Each node in the task flow is a task.

[0105] During the execution of step 501, the server can repeatedly trigger the execution of each task according to the triggering frequency to obtain test logs. The tasks include start and stop tasks, page-triggered user operation tasks, or interface call tasks.

[0106] In practical applications, online environments are often extremely complex, making it very difficult to reproduce problems. This application embodiment attempts to reproduce service problems and improve the success rate of service anomaly analysis by repeatedly triggering service anomaly conditions and triggering task flow, including start and stop tasks, page-triggered user operation tasks, or interface call tasks.

[0107] In one embodiment, such as Figure 6 As shown, a service anomaly analysis method is provided, which can be applied to... Figure 1 Taking the server in the example, the following steps are included:

[0108] Step 601: In the event of an anomaly in the target service, determine the task flow and the abnormal time period corresponding to the target service, and obtain the anomaly logs obtained from executing the task flow during the abnormal time period.

[0109] Step 602: For each task included in the task flow, repeatedly trigger the execution of the task in the test environment corresponding to the target service according to the triggering frequency to obtain test logs.

[0110] Tasks include starting and stopping tasks, page-triggered user actions, or API call tasks.

[0111] Step 603: Compare the first service execution status included in the exception log with the second service execution status included in the test log.

[0112] Step 604: If the execution status of the first service is the same as that of the second service, then the exception type is determined to be a service exception.

[0113] Step 605: If the execution status of the first service is different from that of the second service, then the exception type is determined to be an environment exception.

[0114] Step 606: During the execution of the task flow in the test environment, obtain the first resource usage data.

[0115] Step 607: In the case of an exception type of environmental exception, obtain the second resource usage data when the task flow is executed during the exception time period.

[0116] Step 608: Compare the first resource usage data with the second resource usage data to determine the resource bottleneck information.

[0117] Step 609: Output the anomaly type and resource bottleneck information according to the preset data format. The anomaly type and resource bottleneck information are used for system performance analysis.

[0118] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0119] Based on the same inventive concept, this application also provides a service anomaly analysis apparatus for implementing the service anomaly analysis method described above. The solution provided by this apparatus is similar to the implementation scheme described in the above method; therefore, the specific limitations in one or more service anomaly analysis apparatus embodiments provided below can be found in the limitations of the service anomaly analysis method described above, and will not be repeated here.

[0120] In one exemplary embodiment, such as Figure 7 As shown, a service anomaly analysis device is provided, comprising:

[0121] The first determining module 701 is used to determine the task flow and abnormal time period corresponding to the target service when the target service is abnormal, and to obtain the abnormal log obtained by executing the task flow during the abnormal time period.

[0122] Execution module 702 is used to execute the task flow in the test environment corresponding to the target service and obtain test logs;

[0123] The second determining module 703 is used to determine the exception type of the target service based on the exception log and the test log.

[0124] In one embodiment, the second determining module 703 is specifically used to compare the first service execution status included in the exception log with the second service execution status included in the test log; if the first service execution status is the same as the second service execution status, then the exception type is determined to be a service exception; if the first service execution status is different from the second service execution status, then the exception type is determined to be an environment exception.

[0125] In one embodiment, the device further includes:

[0126] The first acquisition module is used to acquire first resource usage data during the execution of the task flow in the test environment;

[0127] The second acquisition module is used to acquire second resource usage data when the task flow is executed during the abnormal time period if the abnormality type is an environmental abnormality.

[0128] The first determining module 701 is further configured to compare the first resource occupancy data with the second resource occupancy data to determine resource bottleneck information.

[0129] In one embodiment, the device further includes:

[0130] The output module is used to output the anomaly type and the resource bottleneck information according to a preset data format. The anomaly type and the resource bottleneck information are used for system performance analysis.

[0131] In one embodiment, the execution module 702 is specifically used to trigger the execution of the task flow in the test environment according to a preset trigger frequency to obtain the test log, wherein the trigger frequency is greater than the execution frequency of the task flow during the abnormal time period.

[0132] In one embodiment, the task flow includes multiple tasks, and the execution module 702 is specifically used to repeatedly trigger the execution of each task according to the triggering frequency to obtain the test log. The tasks include start / stop tasks, page-triggered user operation tasks, or interface call tasks.

[0133] Each module in the aforementioned service anomaly analysis device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can call and execute the corresponding operations of each module.

[0134] In one exemplary embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 8 As shown, this computer device includes a processor, memory, input / output interfaces (I / O), and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores data for data processing. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communication with external terminals via a network connection. When the computer program is executed by the processor, it implements a service anomaly analysis method.

[0135] Those skilled in the art will understand that Figure 8 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0136] In one exemplary embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to perform the following steps:

[0137] In the event of an anomaly in the target service, determine the task flow corresponding to the target service and the abnormal time period, and obtain the anomaly logs obtained by executing the task flow during the abnormal time period.

[0138] The task flow is executed in the test environment corresponding to the target service to obtain test logs;

[0139] Based on the exception logs and the test logs, determine the exception type of the target service.

[0140] In one embodiment, the processor executes the following steps when executing a computer program:

[0141] Compare the first service execution status included in the exception log with the second service execution status included in the test log;

[0142] If the first service execution status is the same as the second service execution status, then the exception type is determined to be a service exception;

[0143] If the execution status of the first service is different from that of the second service, then the exception type is determined to be an environmental exception.

[0144] In one embodiment, the processor, when executing a computer program, also performs the following steps:

[0145] During the execution of the task flow in the test environment, first resource usage data is acquired;

[0146] In the case where the anomaly type is an environmental anomaly, obtain the second resource usage data when the task flow is executed during the anomaly time period;

[0147] The first resource usage data is compared with the second resource usage data to determine resource bottleneck information.

[0148] In one embodiment, the processor, when executing a computer program, also performs the following steps:

[0149] According to the preset data format, the anomaly type and the resource bottleneck information are output, and the anomaly type and the resource bottleneck information are used for system performance analysis.

[0150] In one embodiment, the processor executes the following steps when executing a computer program:

[0151] The task flow is triggered and executed in the test environment according to a preset trigger frequency to obtain the test log. The trigger frequency is greater than the execution frequency of the task flow during the abnormal time period.

[0152] In one embodiment, the task flow includes multiple tasks, and the processor executes the following steps when executing the computer program:

[0153] For each task, the task is repeatedly triggered and executed according to the triggering frequency to obtain the test log. The tasks include starting and stopping tasks, page-triggered user operation tasks, or interface call tasks.

[0154] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, the computer program performing the following steps when executed by a processor:

[0155] In the event of an anomaly in the target service, determine the task flow corresponding to the target service and the abnormal time period, and obtain the anomaly logs obtained by executing the task flow during the abnormal time period.

[0156] The task flow is executed in the test environment corresponding to the target service to obtain test logs;

[0157] Based on the exception logs and the test logs, determine the exception type of the target service.

[0158] In one embodiment, when a computer program is executed by a processor, it specifically implements the following steps:

[0159] Compare the first service execution status included in the exception log with the second service execution status included in the test log;

[0160] If the first service execution status is the same as the second service execution status, then the exception type is determined to be a service exception;

[0161] If the execution status of the first service is different from that of the second service, then the exception type is determined to be an environmental exception.

[0162] In one embodiment, when the computer program is executed by a processor, it also performs the following steps:

[0163] During the execution of the task flow in the test environment, first resource usage data is acquired;

[0164] In the case where the anomaly type is an environmental anomaly, obtain the second resource usage data when the task flow is executed during the anomaly time period;

[0165] The first resource usage data is compared with the second resource usage data to determine resource bottleneck information.

[0166] In one embodiment, when the computer program is executed by a processor, it also performs the following steps:

[0167] According to the preset data format, the anomaly type and the resource bottleneck information are output, and the anomaly type and the resource bottleneck information are used for system performance analysis.

[0168] In one embodiment, when a computer program is executed by a processor, it specifically implements the following steps:

[0169] The task flow is triggered and executed in the test environment according to a preset trigger frequency to obtain the test log. The trigger frequency is greater than the execution frequency of the task flow during the abnormal time period.

[0170] In one embodiment, the task flow includes multiple tasks, and the computer program, when executed by a processor, specifically implements the following steps:

[0171] For each task, the task is repeatedly triggered and executed according to the triggering frequency to obtain the test log. The tasks include starting and stopping tasks, page-triggered user operation tasks, or interface call tasks.

[0172] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, performs the following steps:

[0173] In the event of an anomaly in the target service, determine the task flow corresponding to the target service and the abnormal time period, and obtain the anomaly logs obtained by executing the task flow during the abnormal time period.

[0174] The task flow is executed in the test environment corresponding to the target service to obtain test logs;

[0175] Based on the exception logs and the test logs, determine the exception type of the target service.

[0176] In one embodiment, when a computer program is executed by a processor, it specifically implements the following steps:

[0177] Compare the first service execution status included in the exception log with the second service execution status included in the test log;

[0178] If the first service execution status is the same as the second service execution status, then the exception type is determined to be a service exception;

[0179] If the execution status of the first service is different from that of the second service, then the exception type is determined to be an environmental exception.

[0180] In one embodiment, when the computer program is executed by a processor, it also performs the following steps:

[0181] During the execution of the task flow in the test environment, first resource usage data is acquired;

[0182] In the case where the anomaly type is an environmental anomaly, obtain the second resource usage data when the task flow is executed during the anomaly time period;

[0183] The first resource usage data is compared with the second resource usage data to determine resource bottleneck information.

[0184] In one embodiment, when the computer program is executed by a processor, it also performs the following steps:

[0185] According to the preset data format, the anomaly type and the resource bottleneck information are output, and the anomaly type and the resource bottleneck information are used for system performance analysis.

[0186] In one embodiment, when a computer program is executed by a processor, it specifically implements the following steps:

[0187] The task flow is triggered and executed in the test environment according to a preset trigger frequency to obtain the test log. The trigger frequency is greater than the execution frequency of the task flow during the abnormal time period.

[0188] In one embodiment, the task flow includes multiple tasks, and the computer program, when executed by a processor, specifically implements the following steps:

[0189] For each task, the task is repeatedly triggered and executed according to the triggering frequency to obtain the test log. The tasks include starting and stopping tasks, page-triggered user operation tasks, or interface call tasks.

[0190] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0191] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0192] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0193] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A service anomaly analysis method, characterized in that, The method includes: In the event of an anomaly in the target service, determine the task flow corresponding to the target service and the abnormal time period, and obtain the anomaly logs obtained by executing the task flow during the abnormal time period. The task flow is executed in the test environment corresponding to the target service to obtain test logs; Based on the exception logs and the test logs, determine the exception type of the target service.

2. The method according to claim 1, characterized in that, The step of determining the anomaly type of the target service based on the anomaly log and the test log includes: Compare the first service execution status included in the exception log with the second service execution status included in the test log; If the first service execution status is the same as the second service execution status, then the exception type is determined to be a service exception; If the execution status of the first service is different from that of the second service, then the exception type is determined to be an environmental exception.

3. The method according to claim 1 or 2, characterized in that, The method further includes: During the execution of the task flow in the test environment, first resource usage data is acquired; In the case where the anomaly type is an environmental anomaly, obtain the second resource usage data when the task flow is executed during the anomaly time period; The first resource usage data is compared with the second resource usage data to determine resource bottleneck information.

4. The method according to claim 3, characterized in that, The method further includes: According to the preset data format, the anomaly type and the resource bottleneck information are output, and the anomaly type and the resource bottleneck information are used for system performance analysis.

5. The method according to claim 1, characterized in that, The task flow is executed in the test environment corresponding to the target service to obtain test logs, including: The task flow is triggered and executed in the test environment according to a preset trigger frequency to obtain the test log. The trigger frequency is greater than the execution frequency of the task flow during the abnormal time period.

6. The method according to claim 5, characterized in that, The task flow includes multiple tasks. The task flow is triggered and executed in the test environment according to a preset trigger frequency to obtain the test log, which includes: For each task, the task is repeatedly triggered and executed according to the triggering frequency to obtain the test log. The tasks include starting and stopping tasks, page-triggered user operation tasks, or interface call tasks.

7. A service anomaly analysis device, characterized in that, The device includes: The first determining module is used to determine the task flow and abnormal time period corresponding to the target service when the target service is abnormal, and to obtain the abnormal log obtained by executing the task flow during the abnormal time period. The execution module is used to execute the task flow in the test environment corresponding to the target service and obtain test logs; The second determining module is used to determine the exception type of the target service based on the exception log and the test log.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

Images