Software anomaly diagnosis method, device, electronic device and storage medium

Abstract

An embodiment of the present invention provides a software anomaly diagnosis method, apparatus, electronic device, and storage medium. The method includes: after detecting a software access request to be diagnosed, determining whether to send a log corresponding to the software access request to be diagnosed to a log system based on the log level of the software access request to be diagnosed; if not, performing an anomaly diagnosis on the context data of the software access request to be diagnosed according to software anomaly diagnosis rules, and determining whether to send a log corresponding to the software access request to be diagnosed to a log system based on the anomaly diagnosis result. The embodiment of the present invention allows developers and operation and maintenance personnel to set software anomaly diagnosis rules in a targeted manner according to anomaly diagnosis requirements, and further accurately control the output of software anomaly diagnosis logs, thereby helping developers and operation and maintenance personnel to quickly and accurately locate problems.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a software anomaly diagnosis method, device, electronic device and storage medium. Background Art

[0002] The impact of inherent defects in computer software or abnormal environmental factors during software operation cannot be completely avoided. Therefore, diagnosing and handling exceptions during software operation has always been a crucial aspect of software development. This is especially true given the current internet microservices architecture, which must provide high-real-time, high-concurrency, and complex services. Therefore, rapid diagnosis and handling of software operation anomalies is even more crucial, as it directly determines the quality of service.

[0003] Existing methods for diagnosing software anomalies typically rely on hierarchical logging. During software development, different levels of logging logic are added to the code processing logic for development and debugging, anomaly diagnostic alerts, and error handling. However, for online services, especially those with high traffic volumes, excessive logging is generally not permitted; only anomaly warning logs are permitted. Developers often face situations where an online service experiences an anomaly but the logs obtained are too few to pinpoint the issue. Lowering the logging output level results in a large volume of log data, making it difficult to filter out useful information related to the issue. These issues can hinder the speed and efficiency of problem diagnosis. Summary of the Invention

[0004] In response to the problems in the prior art, embodiments of the present invention provide a software anomaly diagnosis method, device, electronic device, and storage medium.

[0005] Specifically, the embodiments of the present invention provide the following technical solutions:

[0006] In a first aspect, an embodiment of the present invention provides a software anomaly diagnosis method, comprising:

[0007] After detecting the software access request to be diagnosed, determine whether to send the log corresponding to the software access request to be diagnosed to the log system according to the log level of the software access request to be diagnosed; if not, perform an abnormality diagnosis on the context data of the software access request to be diagnosed according to the software abnormality diagnosis rules, and determine whether to send the log corresponding to the software access request to be diagnosed to the log system according to the abnormality diagnosis result.

[0008] In a second aspect, an embodiment of the present invention further provides a software anomaly diagnosis device, comprising:

[0009] a first determining module, configured to, after detecting a software access request to be diagnosed, determine, based on a log level of the software access request to be diagnosed, whether to send a log corresponding to the software access request to be diagnosed to a log system;

[0010] a diagnosis module configured to perform an anomaly diagnosis on the context data of the software access request to be diagnosed according to a software anomaly diagnosis rule when the first determination module determines, based on the log level of the software access request to be diagnosed, not to send the log corresponding to the software access request to be diagnosed to the log system;

[0011] The second determining module is configured to determine, based on the abnormality diagnosis result, whether to send the log corresponding to the software access request to be diagnosed to the log system.

[0012] In a third aspect, an embodiment of the present invention further provides an electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, the steps of the software anomaly diagnosis method as described in the first aspect are implemented.

[0013] In a fourth aspect, an embodiment of the present invention further provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the software anomaly diagnosis method as described in the first aspect.

[0014] In a fifth aspect, an embodiment of the present invention further provides a computer program product, which includes a computer program, and when the computer program is executed by a processor, the steps of the software anomaly diagnosis method as described in the first aspect are implemented.

[0015] It can be seen from the above technical solution that the software anomaly diagnosis method, device, electronic device and storage medium provided by the embodiments of the present invention, after detecting the software access request to be diagnosed, determine whether to send the log corresponding to the software access request to be diagnosed to the log system according to the log level of the software access request to be diagnosed; if not, perform an anomaly diagnosis on the context data of the software access request to be diagnosed according to the software anomaly diagnosis rules, and determine whether to send the log corresponding to the software access request to be diagnosed to the log system according to the anomaly diagnosis result. It can be seen that the embodiments of the present invention enable developers and operation and maintenance personnel to set software anomaly diagnosis rules in a targeted manner according to anomaly diagnosis requirements, and then accurately control the output of software anomaly diagnosis logs, thereby helping developers and operation and maintenance personnel to quickly and accurately locate problems. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following is a brief introduction to the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0017] Figure 1 A flowchart of a software anomaly diagnosis method provided by one embodiment of the present invention;

[0018] Figure 2 A schematic diagram of a software access abstract model provided by an embodiment of the present invention;

[0019] Figure 3 A schematic diagram of a software access abstract model including a diagnostic strategy module provided in one embodiment of the present invention;

[0020] Figure 4 A logic diagram of a diagnostic strategy module provided by an embodiment of the present invention;

[0021] Figure 5 A schematic flow chart of the single rule matching detection logic provided by one embodiment of the present invention;

[0022] Figure 6 A flow chart of log processing in a diagnostic strategy module according to an embodiment of the present invention;

[0023] Figure 7 A schematic diagram of the structure of a software anomaly diagnosis device provided by an embodiment of the present invention;

[0024] Figure 8 A schematic structural diagram of an electronic device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0025] To make the objectives, technical solutions, and advantages of the embodiments of the present invention more clear, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. All other embodiments obtained by ordinary technicians in this field based on the embodiments of the present invention without making any creative efforts shall fall within the scope of protection of the present invention.

[0026] In this embodiment, it should be noted that when a software anomaly occurs, developers or operations personnel are typically concerned with the entire process of the user operating the accessed resource within the software runtime environment, thereby identifying anomalies in the software, data, or runtime environment. When the alarm system notifies the developer or operations personnel of a service anomaly, the service request has already been completed. The anomaly diagnosis method accurately records a snapshot of the entire request process through logs based on rule-matching decision results, helping developers and operations personnel restore the entire service access process, thereby quickly locating and fixing the problem.

[0027] Existing methods for diagnosing software anomalies typically rely on hierarchical logging. During software development, different levels of logging logic are added to the code processing logic for development and debugging, anomaly diagnostic alerts, and error handling. However, for online services, especially those with high traffic volumes, excessive logging is generally not permitted; only anomaly warning logs are permitted. Developers often face situations where an online service experiences an anomaly but the logs obtained are too few to pinpoint the issue. Lowering the logging output level results in a large volume of log data, making it difficult to filter out useful information related to the issue. These issues can hinder the speed and efficiency of problem diagnosis. To solve this problem, an embodiment of the present invention provides a software anomaly diagnosis method. After detecting a software access request to be diagnosed, the embodiment of the present invention first determines whether to send the log corresponding to the software access request to be diagnosed to the log system based on the log level of the software access request to be diagnosed. If not, the context data of the software access request to be diagnosed is diagnosed according to the software anomaly diagnosis rule, and determines whether to send the log corresponding to the software access request to be diagnosed to the log system based on the anomaly diagnosis result. It can be seen that the embodiment of the present invention allows developers and operation and maintenance personnel to set software anomaly diagnosis rules in a targeted manner according to anomaly diagnosis requirements, and then accurately control the output of software anomaly diagnosis logs, thereby helping developers and operation and maintenance personnel to quickly and accurately locate problems. The content of the present invention will be explained and illustrated in detail through specific embodiments below.

[0028] Figure 1 FIG. 1 is a flow chart showing a method for diagnosing software anomalies according to an embodiment of the present invention. Figure 1 As shown, the software anomaly diagnosis method provided by the embodiment of the present invention includes the following steps:

[0029] Step 101: after detecting a software access request to be diagnosed, determining whether to send a log corresponding to the software access request to be diagnosed to a log system according to the log level of the software access request to be diagnosed;

[0030] Step 102: If it is determined based on the log level of the software access request to be diagnosed that the log corresponding to the software access request to be diagnosed is not to be sent to the log system, then performing an anomaly diagnosis on the context data of the software access request to be diagnosed according to a software anomaly diagnosis rule;

[0031] Step 103: Determine whether to send the log corresponding to the software access request to be diagnosed to the log system according to the abnormality diagnosis result.

[0032] In this embodiment, the log level can be graded according to one or more dimensions such as the importance of the information contained in the log, the importance of the software access request to be diagnosed corresponding to the log, the attention paid to the log, the urgency of the event represented by the log to be processed, the timeliness of the log output, the type of log, etc. For example, the log can be divided into various levels such as level 1, level 2, level 3, level 4, and level 5 according to the importance (or degree of attention or attention) of the software access request to be diagnosed corresponding to the log, where level 1 represents the highest level and the others are ranked in descending order. For example, when the importance of the software access request to be diagnosed is very high, the level of the log corresponding to the software access request to be diagnosed can be pre-set to level 1, so that the log generated by the software access request to be diagnosed with a very high degree of importance can be directly output to the log system without going through the judgment process of abnormal diagnosis, thereby meeting the demand for high-level logs to be output to the log system as soon as possible. At the same time, it is understandable that when the importance of the software access request to be diagnosed is relatively low, the level of the log corresponding to the software access request to be diagnosed can be pre-set to a lower level (such as level 3). According to the solution of the present application, for the lower level situation, it is necessary to perform abnormal diagnosis on the context data of the software access request to be diagnosed according to the software abnormal diagnosis rules, and then determine whether to send the log corresponding to the software access request to be diagnosed to the log system based on the abnormal diagnosis results. It can be seen that through such processing, not only can the logs generated by the software access request to be diagnosed with a very high degree of importance be directly output to the log system without going through the abnormal diagnosis judgment process, so as to meet the demand for high-level logs to be output to the log system as soon as possible, but also (through the abnormal diagnosis rules) the logs generated by the software access request to be diagnosed with a relatively low degree of importance can be purposefully screened, so that problems can be discovered and solved in a timely and targeted manner, thereby solving the problem that too few logs are obtained to locate the problem, and lowering the log output level will result in a large amount of log data, which is not easy to filter out useful information related to the problem.

[0033] In addition, it should be noted that the log level of the log generated by the software access request can be pre-set, or a modification interface can be provided, that is, the user is allowed to modify the log level through the modification interface as needed.

[0034] For example, the log level can also be determined according to the type of log generated. For example, the types of logs include DEBUG, INFO, WARNING, ERROR, etc. Therefore, it can be determined that the log levels include DEBUG, INFO, WARNING, ERROR and other log levels. Among them, the ERROR log has the highest level, the WARNING log has the second highest level, and the levels of the remaining logs are lower. Generally speaking, since logs with the ERROR level (or also including WARNING) need to be processed as soon as possible to find the cause of the fault, therefore, for logs with the ERROR level (or also including WARNING), no abnormal diagnosis processing can be performed, and they can be directly output to the log system so that they can be analyzed in time to find the cause of the problem. For logs of other levels, it can be determined according to actual needs whether to output them directly or to perform abnormal diagnosis first through the solution provided by the present application, and then determine whether to output them. It can be seen that through the present application solution, different log processing strategies are selected according to the different log levels, which can not only meet the needs of outputting high-level logs to the log system as soon as possible, but also perform abnormal diagnosis on lower-level logs, discover and solve problems in time, thereby solving the problems of too few logs obtained to locate the problem, and lowering the log output level will result in a large amount of log data, which is not easy to filter out useful information related to the problem.

[0035] It is understandable that for some logs with high log levels, no abnormal diagnosis processing may be performed and they may be directly output to the log system. Therefore, for the log corresponding to the software access request to be diagnosed, if the log level of the log is greater than or equal to the preset log level threshold (which can be understood as a log that meets the system's preset log output level), no abnormal diagnosis processing is performed and it is directly output to the log system; if the log level of the log is less than the preset log level threshold, then according to the scheme of this embodiment, it is necessary to perform abnormal diagnosis on the context data of the software access request to be diagnosed according to the software abnormal diagnosis rules, and determine whether to send the log corresponding to the software access request to be diagnosed to the log system based on the abnormal diagnosis results. Through this scheme, different log processing strategies are selected according to different log levels, which can not only meet the demand of outputting high-level logs to the log system as soon as possible, but also perform abnormal diagnosis on lower-level logs, and timely discover and solve problems, thereby solving the problem that too few logs are obtained to locate the problem, and lowering the log output level will result in a large amount of log data, making it difficult to filter out useful information related to the problem.

[0036] It should be noted that the log in the embodiment of the present application is generated during the visitor's access to the accessed resource. The log may include a variety of access-related information, such as: the visitor, the accessed resource, the environment relied upon in the process of accessing the resource, the actions performed in the process of accessing the accessed resource, and one or more of the access results.

[0037] In this embodiment, it should be noted that the software anomaly diagnosis rule may be a rule determined according to a software anomaly diagnosis requirement corresponding to the software access request to be diagnosed.

[0038] For example, software exception diagnosis requirements may include diagnosing whether an exception occurs when a specific visitor V1 performs a write operation on a specific resource R1. It may also include diagnosing whether an exception occurs when multiple specific visitors V1, V2, and V3 perform a write operation on a specific resource R2. It may also include diagnosing whether all accesses by a specific visitor V1 are abnormal. It may also include diagnosing whether all accesses to a specific resource R3 are abnormal. It may also include diagnosing whether an exception occurs when multiple specific visitors V1, V2, and V3 perform read and write operations on a specific resource R4. It may also include diagnosing whether an exception occurs when multiple specific visitors V1, V2, and V3 perform write operations on specific resources R5 and R6. It may also include diagnosing whether an exception occurs when multiple specific visitors V1, V2, and V3 perform write operations on a specific resource R7 under a specific environment E, and so on. This embodiment can set software exception diagnosis requirements in a targeted manner according to user needs, and then determine software exception diagnosis rules based on the set software exception diagnosis requirements, and then obtain the logs you want to know in a targeted manner, so that you can accurately output logs of related exceptions, which can help developers and operation and maintenance personnel quickly and accurately locate problems.

[0039] In this embodiment, the context data of the software access request to be diagnosed can be understood as the data represented or embodied or contained or generated by the software access request to be diagnosed. For example, it can be some data contained in the software access request to be diagnosed, such as one or more data of the visitor, accessed resource, action, environment and access result.

[0040] It can be seen from the above technical solution that the software exception diagnosis method provided by this embodiment, after detecting the software access request to be diagnosed, determines whether to send the log corresponding to the software access request to be diagnosed to the log system according to the log level of the software access request to be diagnosed; if not, then according to the software exception diagnosis rules, perform exception diagnosis on the context data of the software access request to be diagnosed, and determines whether to send the log corresponding to the software access request to be diagnosed to the log system according to the exception diagnosis result. It can be seen that the embodiment of the present invention enables developers and operation and maintenance personnel to set software exception diagnosis rules in a targeted manner according to exception diagnosis requirements, and then accurately control the output of software exception diagnosis logs, thereby helping developers and operation and maintenance personnel to quickly and accurately locate problems.

[0041] Based on the content of the above embodiment, in this embodiment, the context data of the software access request to be diagnosed includes one or more data of the accessor, accessed resource, action, environment and access result contained in the software access request to be diagnosed;

[0042] Correspondingly, the software exception diagnosis rules are rules determined based on the software exception diagnosis requirements corresponding to the software access request to be diagnosed; the software exception diagnosis requirements include: diagnosing whether an exception occurs when accessing one or more specified accessors, and / or, in one or more specified environments, and / or, to one or more specified accessed resources, and / or, performing one or more specified actions.

[0043] In this embodiment, it should be noted that a software access request can be described as: a visitor performs a certain action on the accessed resource in a dependent environment. Based on this, Figure 2 As shown, this embodiment abstracts the software access action into Figure 2 The software access abstract model shown in the figure indicates that a software access request can be abstracted into the following entities:

[0044] ① Visitor – The initiator of an interface request, which can be a human or some kind of operator entity (such as an automated alarm program). ② Accessed resource – The entity that the visitor initiates the request to operate on, generally a piece of data. ③ Action – The visitor's operation on the accessed resource, generally adding, deleting, modifying, or querying. ④ Access result: Success or failure. ⑤ Environment dependency – The visitor's reliance on relevant environmental conditions when accessing the accessed resource through a certain action.

[0045] based on Figure 2In the software access abstract model shown, this embodiment designs a set of simple software access request anomaly diagnosis rules. This rule service can provide a human-computer interaction interface, allowing developers or operation and maintenance personnel to set the diagnosis rules as needed. For example, it can be set for one or more service visitors to perform one or more action types on one or more resources in a certain environment, and decide whether to record the complete process log of the access based on the final result status of the interface access. The request diagnosis rule contains one or more of the following five types of conditions, such as: environmental information, visitor, accessed resource, action, and access result. Based on these types of conditions, the five entities of environmental information, visitor, accessed resource, action, and access result in any access request to be diagnosed can be set with conditions, and then the corresponding software anomaly diagnosis rules can be generated. Then, according to the software anomaly diagnosis rules, the context data of the software access request to be diagnosed is diagnosed, and the log with the anomaly is output to facilitate analysis by relevant personnel.

[0046] Because this embodiment sets requirements based on each entity in the abstract software access model, it allows precise control of software exception diagnosis log output based on the needs of developers and maintenance personnel. This means that this method accurately outputs relevant software exception diagnosis log information based on the needs of developers and maintenance personnel, helping them quickly and accurately locate problems.

[0047] As can be seen from the above technical solution, the software anomaly diagnosis method provided by this embodiment, based on the characteristics of software access, abstracts the software access action into a software access abstract model, which includes one or more entities of accessor, accessed resource, action, environment and access result. Based on the software access abstract model, developers or operation and maintenance personnel can set the software anomaly diagnosis requirements corresponding to each entity in the software access abstract model as needed, and then determine the diagnostic conditions corresponding to each entity in the software access abstract model according to the software anomaly diagnosis requirements. Then, according to the diagnostic conditions corresponding to each entity in the software access abstract model, software anomaly diagnosis rules are generated. Finally, according to the software anomaly diagnosis rules, the context data of the software access request to be diagnosed is diagnosed, and finally the anomaly diagnosis log result of the software access request to be diagnosed is output. It can be seen that, since the requirements are set based on each entity in the abstract software access model, developers and operation and maintenance personnel can set the anomaly diagnosis requirements in a targeted manner, and thus can accurately control the output of the software anomaly diagnosis log, thereby helping developers and operation and maintenance personnel to quickly and accurately locate the problem.

[0048] Based on the content of the above embodiment, in this embodiment, before performing abnormality diagnosis on the context data of the software access request to be diagnosed according to the software abnormality diagnosis rule, the method further includes:

[0049] The software anomaly diagnosis rules are generated according to the software anomaly diagnosis requirements: rules for diagnosing whether anomalies occur when accessing one or more specified visitors, and / or in one or more specified environments, and / or to one or more specified accessed resources, and / or performing one or more specified actions.

[0050] As described above with respect to the software access abstract model, in this embodiment, the software anomaly diagnosis rules are generated according to the software anomaly diagnosis requirements, which can be achieved in the following manner:

[0051] According to the software exception diagnosis requirements, the diagnostic conditions corresponding to each entity in the software access abstract model are determined, and according to the determined diagnostic conditions corresponding to each entity in the software access abstract model, software exception diagnosis rules are generated; wherein, the software access abstract model includes one or more entities of accessor, accessed resource, action, environment and access result.

[0052] This embodiment generates the software anomaly diagnosis rules in advance according to the software anomaly diagnosis requirements, so that they can be directly called when used, thereby simplifying the process.

[0053] Based on the content of the above embodiment, another implementation is provided in this embodiment. That is, before performing abnormality diagnosis on the context data of the software access request to be diagnosed according to the software abnormality diagnosis rule, the method further includes:

[0054] Acquire an anomaly diagnosis rule matching the software anomaly diagnosis requirement from an anomaly diagnosis rule library according to the software anomaly diagnosis requirement;

[0055] The anomaly diagnosis rule base stores rules for diagnosing whether anomalies occur when accessing one or more specified visitors, and / or in one or more specified environments, and / or to one or more specified accessed resources, and / or performing one or more specified actions.

[0056] As described above with respect to the software access abstract model, in this embodiment, obtaining an exception diagnosis rule that matches the software exception diagnosis requirement from the exception diagnosis rule library according to the software exception diagnosis requirement can be achieved in the following manner:

[0057] According to the software exception diagnosis requirement, the diagnostic conditions corresponding to each entity in the software access abstract model that match the software exception diagnosis requirement are obtained from the diagnostic conditions corresponding to each entity in the software access abstract model contained in the exception diagnosis rule library, and software exception diagnosis rules are generated based on the obtained diagnostic conditions corresponding to each entity in the software access abstract model; wherein the software access abstract model includes one or more entities of accessor, accessed resource, action, environment and access result.

[0058] This embodiment obtains matching rules from an anomaly diagnosis rule library, eliminating the need for a rule generation process, thereby simplifying the process.

[0059] In this embodiment, according to the software anomaly diagnosis requirements, the diagnostic conditions corresponding to the entities in the software access abstract model are determined, including:

[0060] If the software exception diagnosis requirement is: whether an exception occurs when accessing one or more specified visitors, and / or, in one or more specified environments, and / or, to one or more specified accessed resources, and / or, performing one or more specified actions, then the diagnostic conditions corresponding to each entity in the software access abstract model are determined as follows: determining that the diagnostic condition corresponding to the access result entity in the software access abstract model is failure, and determining that the diagnostic condition corresponding to the visitor entity in the software access abstract model is the one or more specified visitors; and / or, determining that the diagnostic condition corresponding to the accessed resource entity in the software access abstract model is the one or more specified accessed resources; and / or, determining that the diagnostic condition corresponding to the action entity in the software access abstract model is the one or more specified actions; and / or, determining that the diagnostic condition corresponding to the environment entity in the software access abstract model is the one or more specified environments.

[0061] In this embodiment, software exception diagnosis requirements can be set in a variety of ways based on the five entities in the software access abstract model: environment information, accessor, accessed resource, action, and access result. For example, a software exception diagnosis requirement might include diagnosing whether an exception occurs when a specific accessor V1 performs a write operation on a specific resource R1. Alternatively, a software exception diagnosis requirement might include diagnosing whether an exception occurs when multiple specific accessors V1, V2, and V3 perform a write operation on a specific resource R2. Alternatively, a software exception diagnosis requirement might include diagnosing whether all accesses by a specific accessor V1 produce an exception. Alternatively, a software exception diagnosis requirement might include diagnosing whether an exception occurs when all accesses to a specific resource R3 produce an exception. Alternatively, a software exception diagnosis requirement might include diagnosing whether an exception occurs when multiple specific accessors V1, V2, and V3 perform read and write operations on a specific resource R4. Alternatively, a software exception diagnosis requirement might include diagnosing whether an exception occurs when multiple specific accessors V1, V2, and V3 perform write operations on specific resources R5 and R6. Alternatively, a software exception diagnosis requirement might include diagnosing whether an exception occurs when multiple specific accessors V1, V2, and V3 perform write operations on a specific resource R7 under a specific environment E. And so on. It can be seen that this embodiment can set software exception diagnosis requirements in a targeted manner according to user needs, and then can obtain the logs that you want to know in a targeted manner, so that you can accurately output logs of related exceptions, which can help developers and operation and maintenance personnel quickly and accurately locate problems.

[0062] According to the above description, in this embodiment, the software anomaly diagnosis requirement can be a combination of one or more of the following solutions:

[0063] ①One or more designated visitors;

[0064] ②In one or more designated environments;

[0065] ③For one or more designated accessed resources;

[0066] ④ Perform one or more specified actions;

[0067] It should be noted that after determining that the software exception diagnosis requirement can be a combination of one or more of the above solutions, the diagnostic conditions corresponding to the visitor entity in the software access abstract model can be determined to be a combination of one or more of the following solutions:

[0068] ① determining that the diagnostic condition corresponding to the visitor entity in the software access abstract model is the one or more specified visitors, and determining that the diagnostic condition corresponding to the access result entity in the software access abstract model is failure;

[0069] ② Determining that the diagnostic condition corresponding to the accessed resource entity in the software access abstract model is the one or more designated accessed resources, and determining that the diagnostic condition corresponding to the access result entity in the software access abstract model is failure;

[0070] ③ Determining that the diagnostic condition corresponding to the action entity in the software access abstract model is the one or more specified actions, and determining that the diagnostic condition corresponding to the access result entity in the software access abstract model is failure;

[0071] ④ Determine that the diagnostic condition corresponding to the environment entity in the software access abstract model is the one or more specified environments, and determine that the diagnostic condition corresponding to the access result entity in the software access abstract model is failure.

[0072] In this embodiment, it should be noted that, since exception diagnosis requirements are set based on each entity in the abstract software access model, it is possible to set personalized exception diagnosis requirements based on the needs of developers and operation and maintenance personnel, and thus accurately control the output of software exception diagnosis logs based on the set personalized exception diagnosis requirements. Thus, this embodiment achieves the purpose of accurately outputting relevant software exception diagnosis log information based on the needs of developers and operation and maintenance personnel, thereby helping developers and operation and maintenance personnel quickly and accurately locate problems.

[0073] Based on the content of the above embodiment, in this embodiment, according to the software abnormality diagnosis requirements, the diagnostic conditions corresponding to each entity in the software access abstract model are determined, including:

[0074] If the software exception diagnosis requirement is whether any access has an exception, that is, if the software exception diagnosis requirement is all accesses with failed access results, then the diagnostic conditions corresponding to each entity in the software access abstract model are determined as follows: the diagnostic condition corresponding to the access result entity in the software access abstract model is determined to be failure, and the diagnostic conditions corresponding to other entities in the software access abstract model are determined to be empty.

[0075] This embodiment supports setting default diagnostic rules. This means that any access to any resource in any environment, using any action, requires diagnostic logs to be generated if the access ultimately fails. Correspondingly, the software exception diagnosis requirement can be set to detect any exceptions in any access, or to detect all failed accesses.

[0076] In this embodiment, it should be noted that in order to make the software anomaly diagnosis method provided by this embodiment universal, that is, compatible with the existing anomaly diagnosis logic, this embodiment supports setting default diagnostic rules, that is, it can be set that when any visitor accesses any resource in any environment with any action, if the final status of the access is failure, a diagnostic log needs to be output.

[0077] In this embodiment, software anomaly diagnosis rules are generated based on the diagnosis conditions corresponding to the entities in the software access abstract model, including:

[0078] The diagnostic conditions corresponding to each entity in the software access abstract model are combined to generate software anomaly diagnostic rules.

[0079] In this embodiment, it can be understood that the rule setting process is actually the process of assigning diagnostic conditions to related entities. Therefore, after obtaining the diagnostic conditions corresponding to each entity in the software access abstract model, the diagnostic conditions corresponding to each entity in the software access abstract model are combined to generate software anomaly diagnostic rules.

[0080] In this embodiment, it should be noted that, to improve the operational efficiency of filtering rules, this embodiment imposes certain constraints on the configuration of diagnostic rules based on actual usage scenarios. For example: ① The length of a single entity condition is limited, for example, a condition check that supports tracking a maximum of N1 visitors simultaneously. ② Single entity conditions support wildcarding, for example, supporting write operations on resource R1 by "all visitors." "All visitors" requires a wildcarding approach. ③ Data within a single entity condition uses an "OR" logical operation. For example, visitor V1 or V2 performs a write or read operation on resource R1. ④ Conditions between different entities use an "AND" logical operation. For example, visitor V1 performs a "write" operation on resource R1 in environment E1. ⑤ The number of rules that can run simultaneously is limited. For example, the maximum number of rules allowed simultaneously cannot exceed N4. It can be understood that based on these rule constraints, not only flexible software anomaly diagnosis can be achieved, but also simple and efficient software anomaly diagnosis can be achieved. Furthermore, the anomaly diagnosis process can minimize the consumption of system resources such as CPU and memory, thereby avoiding impacting normal business processing.

[0081] Based on the content of the above embodiment, in this embodiment, according to the software abnormality diagnosis rule, the context data of the software access request to be diagnosed is diagnosed for abnormality, and according to the abnormality diagnosis result, it is determined whether to send the log corresponding to the software access request to be diagnosed to the log system, including:

[0082] The log corresponding to the software access request to be diagnosed is cached, and according to the software exception diagnosis rules, the context data of the software access request to be diagnosed is diagnosed for exception diagnosis, and when it is determined according to the exception diagnosis result that the context data of the software access request to be diagnosed meets the exception diagnosis rules, the cached log is sent to the log system, and when it is determined according to the exception diagnosis result that the context data of the software access request to be diagnosed does not meet the exception diagnosis rules, the cached log is deleted.

[0083] In this embodiment, it should be noted that the introduction of a new abnormality diagnosis method into an existing software service needs to follow several principles. First, the method should be as simple and transparent as possible, and increase the developer's development complexity as little as possible or not at all. Second, the method should not affect the existing business logic process as much as possible. Third, the method should consume as little as possible the system's CPU, memory and other resources to avoid affecting normal business processing. Therefore, the software access abstract model for introducing the software abnormality diagnosis method can be adjusted as follows: Figure 3 As shown, Figure 3 The software anomaly diagnosis method provided by this embodiment is stored in the diagnostic strategy module in . Therefore, in this embodiment, in order to make the software anomaly diagnosis method as simple and transparent as possible, to increase the developer's development complexity as little as possible or not at all, and at the same time to make the software anomaly diagnosis method not affect the existing business logic process as much as possible, based on this, this embodiment provides the following Figure 4 The diagnostic strategy module logic diagram shown in Figure 4 In the embodiment, the diagnostic strategy module of the software anomaly diagnosis method provided by this embodiment is included, and is further designed to include three parts: an anomaly diagnosis rule management module, a log output interface agent module, and a log data cache module. Among them, the anomaly diagnosis rule management module is used to store anomaly diagnosis rules and to perform anomaly diagnosis, and the log output interface agent module is used to obtain logs from the business logic log output interface and send the anomaly logs to the existing log system. Specifically, after obtaining the log, the log output interface agent module needs to determine whether to send the log directly to the existing log system or to send the log to the log data cache module for caching based on the level of the log, and then use the anomaly diagnosis rule management module to perform anomaly diagnosis. If the anomaly is confirmed, the cached log will be sent to the existing log system, otherwise the cached log will be deleted.

[0084] It is understandable that since software generally has its own mature log output and collection services, in order to ensure that the introduction of the diagnostic method of this embodiment does not affect the system's existing log output and collection system, this embodiment adopts the method of adding a log interface proxy to introduce such a system without substantially increasing the developer's workload. Figure 4The diagnostic strategy module shown (further including abnormal diagnosis rule management module, log output interface agent module, log data cache module), in order to reduce developer workload and avoid increasing unnecessary development burden, in the present embodiment, the name and parameters of the log output function of the log output interface agent module should be consistent with the interface name and parameters of the existing log system of the software, so that the developer does not need to care about the diagnostic processing of the log, and only needs to use the log output interface of the log output interface agent module. It should be noted that the log output interface agent module does not directly output the log to the log output system when receiving the log output in the business logic, but judges the log level. If the log level is greater than or equal to the preset output level threshold, the log of the software access request to be diagnosed is output to the log data cache module. It is understandable that general online systems all allow a certain level of log output, for example, allowing log output above the WARNING level. Therefore, in order to make the introduction of the software abnormality diagnosis method not affect the log output logic of the existing log level. When processing logs, the log output interface agent module does not perform abnormal diagnosis processing on logs above the output level set by the existing system (that is, the output level threshold), and directly outputs them to the existing log system. It only performs caching and filtering rule checking on logs below the output level set by the existing system. This processing can reduce the resource consumption of the cache and rule engine.

[0085] It is understandable that when it is detected that the log level is lower than the preset output level threshold, it is necessary to perform an abnormal diagnosis on the context data of the software access request to be diagnosed according to the software abnormality diagnosis rules, and output the abnormal diagnosis log result of the software access request to be diagnosed.

[0086] It should be noted here that, when it is detected that the log level is less than the preset output level threshold, the log corresponding to the software access request to be diagnosed needs to be cached, and according to the software exception diagnosis rules, the context data of the software access request needs to be diagnosed for exception diagnosis, and when it is determined that the context data of the software access request meets the exception diagnosis rules, the cached log is output to the log data cache module, and when it is determined that the cached log does not meet the exception diagnosis rules, the cached log is deleted. It can be seen that for the cached log, it is necessary to make a judgment before deciding whether to actually output it. In addition, it should be noted that the output to the preset log storage location here refers to the output to the existing log system. Therefore, the existing log output and collection system can be fully utilized without modifying the existing log output and collection system, thereby reducing the workload of developers and not affecting the existing business logic.

[0087] Based on the content of the above embodiment, in this embodiment, if the log level is less than the preset output level threshold, an abnormality diagnosis is performed on the context data of the software access request to be diagnosed according to the software abnormality diagnosis rule, and an abnormality diagnosis log result of the software access request to be diagnosed is output, including:

[0088] If the log level is less than the preset output level threshold, the log corresponding to the software access request to be diagnosed will be cached, and according to the software exception diagnosis rule, the context data of the software access request will be diagnosed for exception, and when it is determined that the cached log meets the exception diagnosis rule, the cached log will be output to the preset log storage location, and when it is determined that the cached log does not meet the exception diagnosis rule, the cached log will be deleted.

[0089] In this embodiment, as described above and Figure 5 and Figure 6As shown, when the log output interface proxy module receives log output from the business logic, it does not directly output the log to the log output system provided by the microservice framework. Instead, it caches the log, which can be a memory cache or a Redis cache. When a software access request is completed, the proxy module then decides whether to actually output the log based on the matching decision of the filtering rules. (Understandably, diagnostic results are generally not available until the end of the previous request. Therefore, logs during the request process need to be cached first, and the final decision on whether to output all logs is based on the diagnostic results.) Online systems generally allow log output at a certain level, for example, logs above the WARNING level. The introduction of the diagnostic policy module does not affect the existing log output logic. When processing logs, the log output interface proxy module bypasses exception diagnosis for logs above the output level set by the existing system and directly outputs them to the existing logging system. Only logs below the output level set by the existing system are cached and checked for filtering rules. This reduces resource consumption on the cache and rule engine. It should be noted that developers use the interface provided by the log interface proxy to output logs. After receiving log output, the log output interface proxy module first checks the system's preset log output level. Logs that meet the preset log output level are directly output to the microservice's log output interface without performing any exception diagnosis. Logs below the set log level are cached and then output based on the exception diagnosis results. Once all request logic processing for that access is complete, the business logic submits a commit request to the proxy interface. The proxy interface calls the rule detection interface based on the request context and makes a decision based on the decision: output the log to the microservice's log output interface or discard the cached log. It should be noted that filtering rules support default rule settings. Therefore, when using this diagnostic log output policy, the failure of the microservice request will generally be treated as the default rule, and the log will faithfully record all failed microservice requests. Furthermore, the rule management module also supports on-demand configuration of log output rules, allowing developers and operations personnel to flexibly and precisely control the output of the log data they desire within the permitted range, thereby helping them quickly identify and resolve issues.

[0090] In this embodiment, it should be noted that the software anomaly diagnosis method provided in this embodiment should be as simple and transparent as possible, and should increase the development complexity of the developer as little as possible or not at all. At the same time, it is necessary to try to make the software diagnosis method not affect the existing business logic process. Based on this, Figure 4As shown in the architectural diagram, since software generally has its own mature log output and collection services, the introduction of the diagnostic strategy module of this embodiment cannot affect the system's existing log output and collection system. Therefore, this embodiment adopts the method of adding a log interface agent to introduce the diagnostic strategy module without basically increasing the developer's workload. The name and parameters of the log output function of the log output interface agent module must be kept consistent with the interface name and parameters of the software's existing log system. Developers do not need to worry about the diagnostic processing of the log, they only need to use the log output interface of the agent module. That is, Figure 4 As shown, this embodiment only needs to obtain the log of the software access request to be diagnosed from the unified business logic log acquisition interface, and then judge the log level. If the log level is greater than or equal to the preset output level threshold, the log of the software access request to be diagnosed is directly output to the preset log storage location; if the log level is less than the preset output level threshold, the context data of the software access request to be diagnosed is diagnosed according to the software abnormality diagnosis rule, and the abnormality diagnosis log result of the software access request to be diagnosed is output to the preset log storage location. The output to the preset log storage location here refers to the output to the existing log system. Therefore, the existing log output and collection system can be fully utilized without modifying the existing log output and collection system, thereby reducing the workload of developers and not affecting the existing business logic.

[0091] In this embodiment, it should be noted that the use of the log output control method for abnormal diagnosis can accurately and flexibly control the output of abnormal diagnostic data in the microservice interface access process according to the needs of developers or operation and maintenance personnel without increasing the development cost much, which greatly improves the accuracy and efficiency of developers and operation and maintenance personnel in discovering and solving problems, and can help software products improve product quality indicators such as reliability and stability.

[0092] Based on the content of the above embodiment, in this embodiment, when it is determined according to the abnormality diagnosis result that the context data of the software access request to be diagnosed meets the abnormality diagnosis rule, sending the cached log to the log system includes:

[0093] When it is determined according to the abnormality diagnosis result that the context data of the software access request to be diagnosed meets the abnormality diagnosis rule, the cached log is sent to the log system according to the preset output frequency and output total amount;

[0094] The output frequency refers to the output of the first number of logs per second, and logs exceeding the first number are discarded;

[0095] The total output amount refers to outputting a maximum of the second number of logs, and automatically closing the software anomaly diagnosis rule after outputting the second number of logs.

[0096] In this embodiment, the output of log data is also controlled, that is, when outputting the abnormal diagnosis log results of the software access request to be diagnosed, the abnormal diagnosis log results of the software access request to be diagnosed can be output according to the preset output frequency and output total amount. Among them, the preset output frequency and output total amount can be used to limit the frequency and total amount of log output through the human-computer interaction interface before performing software diagnosis. For example, for the log output that meets the filtering conditions, only N2 access logs are output per second, and the excess are discarded. A maximum of N3 access logs are output in total, and the rule is automatically closed after N3 times are output. In this embodiment, it should be noted that based on the above output control strategy, the abnormal diagnosis process can consume as little resources as possible on the system's CPU, memory, etc., thereby avoiding affecting normal business processing. Based on the above output control strategy, simple and efficient abnormal diagnosis can be achieved.

[0097] According to the above description, this embodiment sets exception diagnosis rules based on the entities in the abstract access model, so that the exception diagnosis method based on the exception diagnosis rules can meet the needs of developers and operation and maintenance personnel to conduct targeted exception diagnosis on a specific content of the software, thereby achieving fast and accurate exception positioning without the need to output a large number of logs. In addition, the output control method of the exception diagnosis log based on the log interface proxy, temporary cache mechanism and diagnosis rule decision-making in this embodiment can enable this embodiment to achieve targeted software diagnosis based on the abstract access model according to actual diagnostic needs without changing the existing business logic process, and, under the premise of making full use of the existing log output and collection services, the implementation of the diagnosis method of this embodiment will not increase the burden on developers, and can improve the accuracy and efficiency of developers and operation and maintenance personnel in discovering and solving problems, thereby helping software products improve product quality indicators such as reliability and stability.

[0098] In addition, it should be noted that in the prior art, the log output results can generally only be controlled by setting the log output level. The problem with this approach is that if the log output level is high, it is easy to miss some logs, resulting in too few logs to locate the problem. If the log output level is low, the log output volume will be very large, making it inconvenient to filter out useful information related to the problem, affecting the speed and efficiency of diagnosis. It can be seen that a problem in the prior art is that it is impossible to obtain logs that are related to specific businesses or objects in a targeted manner, thereby helping development and operation and maintenance personnel to quickly locate problems. To address this problem, this embodiment, based on the characteristics of software access, abstracts software access actions into a software access abstract model. The software access abstract model includes one or more entities: accessor, accessed resource, action, environment, and access result. Based on the software access abstract model, developers or operation and maintenance personnel can set software exception diagnosis requirements corresponding to each entity in the software access abstract model as needed. Then, based on the software exception diagnosis requirements, determine the diagnostic conditions corresponding to each entity in the software access abstract model. Then, based on the diagnostic conditions corresponding to each entity in the software access abstract model, generate software exception diagnosis rules. Finally, based on the software exception diagnosis rules, perform exception diagnosis on the context data of the software access request to be diagnosed, and finally output an exception log. As can be seen, the embodiment of the present invention, because the requirements are set based on the abstract software access model, enables the output of the software exception diagnosis log to be precisely controlled according to the needs of developers and operation and maintenance personnel. That is, the method can accurately output relevant software exception diagnosis log information according to the needs of developers and operation and maintenance personnel, thereby helping developers and operation and maintenance personnel to quickly and accurately locate problems.

[0099] Based on the content of the above embodiment, in this embodiment, the software anomaly diagnosis rule includes multiple diagnosis rules;

[0100] Accordingly, when performing abnormality diagnosis on the context data of the software access request to be diagnosed according to the software abnormality diagnosis rules, the number of diagnostic rules running simultaneously cannot exceed the first threshold.

[0101] In this embodiment, it should be noted that when developers or operation and maintenance personnel set software anomaly diagnosis rules, they can generate multiple diagnostic rules according to their needs, so that developers or operation and maintenance personnel can conduct software anomaly diagnosis from multiple angles and in a targeted manner, such as: ① Whether an anomaly occurs when the designated visitor V1 performs a write operation on the designated resource R1. ② Whether an anomaly occurs when the designated visitor V2 performs a read operation on the designated resource R2. ③ Whether an anomaly occurs when multiple designated visitors V, V2 and V3 perform a write operation on the designated resources R5 and R6. ④ Whether an anomaly occurs when multiple designated visitors V1, V2, V3 and V4 perform a write operation on the designated resource R7 under the specified environment E. However, it should be added that in order to avoid the abnormal diagnosis process affecting the system's CPU and memory resource consumption, in this embodiment, it is necessary to control the number of diagnostic rules running simultaneously to not exceed the first threshold, so as to avoid the impact of the abnormal diagnosis process on normal business processing. The first threshold here can be set as needed, and this embodiment does not limit it. For example, it can be 10.

[0102] Based on the content of the above embodiment, in this embodiment, determining whether to send a log corresponding to the software access request to be diagnosed to a log system according to the log level of the software access request to be diagnosed includes:

[0103] Determine whether the log level is greater than or equal to a preset log level threshold according to the log level of the software access request to be diagnosed; if so, send the log corresponding to the software access request to be diagnosed to a log system.

[0104] In this embodiment, it can be understood that for some logs with high log levels, exception diagnosis processing can be omitted and the logs can be directly output to the log system. Therefore, for the log corresponding to the software access request to be diagnosed, if the log level of the log is greater than or equal to the preset log level threshold (which can be understood as a log that meets the system's preset log output level), exception diagnosis processing can be omitted and the log can be directly output to the log system; if the log level of the log is less than the preset log level threshold, then according to the scheme of this embodiment, it is necessary to perform exception diagnosis on the context data of the software access request to be diagnosed according to the software exception diagnosis rules, and determine whether to send the log corresponding to the software access request to be diagnosed to the log system based on the exception diagnosis results, thereby solving the problem that the number of obtained logs is too small to locate the problem, and lowering the log output level will result in a large amount of log data, making it difficult to filter out useful information related to the problem.

[0105] Furthermore, in this embodiment, it should be noted that Internet microservice interface access can be considered a special type of software access. Therefore, the software diagnostic method provided in this embodiment is also suitable for Internet microservice interface access. It is understood that for Internet microservice interface access, the software access abstract model here can be considered an abstract model of the Internet microservice interface service, or simply referred to as the microservice interface access model. Figure 2 The model shown here also applies to microservice interface access models. Generally speaking, internet business microservice interfaces typically provide operations such as data addition, deletion, modification, and querying. Data operation requests for each interface are generally stateless, and each interface request is relatively independent. An access request to a service interface can be abstracted into the entities described above: accessor, accessed resource, action, access result, and environment dependency. From the perspective of an internet business microservice interface, a service request can be described as a visitor performing a certain action on an accessed resource within a dependent environment.

[0106] In this embodiment, it should be noted that the Internet microservices architecture divides the entire application into multiple services, resulting in a distributed operating environment, which can present certain difficulties in fault location. Currently, many methods and tools have achieved remarkable results in monitoring and tracing service call links. However, these monitoring and service call tracing methods all rely on diagnostic log data output by the system. Excessive or excessive log output can affect the efficiency and accuracy of problem location. To address this issue, the software anomaly diagnosis method proposed in this embodiment can effectively address this problem. Based on the characteristics of software access, this embodiment abstracts software access actions into an abstract software access model. This allows for requirement settings based on the abstract software access model, enabling precise control of software anomaly diagnostic log output based on the needs of developers and operations personnel. This method can accurately output relevant software anomaly diagnostic log information based on the needs of developers and operations personnel, helping them quickly and accurately locate problems.

[0107] For internet microservice interface access, this embodiment designs a simple set of interface request anomaly diagnosis rules based on the abstract model of the microservice interface. This rule service provides a human-computer interaction interface, allowing developers or operations and maintenance personnel to configure diagnostic rules as needed. When one or more service visitors perform one or more action types on one or more resources in a certain environment, the final result of the interface access determines whether to log the complete access process. The request diagnostic rules can include one or more of the following diagnostic conditions: environment information, visitor, accessed resource, action, and interface request result status. For example, a very simple and efficient diagnostic rule engine can be implemented, primarily providing two interfaces: a human-computer interaction rule setting interface for setting log rules, and a rule detection and calculation interface for the log proxy service, which is used to determine the output of anomaly diagnostic logs. Different microservice systems can predefine the entity types (visitor, resource, action, result, environment) of their own microservice abstract models. Setting rules involves assigning diagnostic conditions to the relevant entity types. Rule detection and calculation is based on a microservice interface request, obtaining the entity data of the corresponding microservice abstract model and then matching it with the rules of the diagnostic system. A logical diagram of the rule matching detection and calculation process for a single rule is shown below. Furthermore, it should be noted that microservice frameworks generally have their own mature log output and collection services. To ensure that the introduction of the diagnostic strategy module does not affect the system's existing log output and collection systems and can leverage existing log output and collection systems, this embodiment adopts the method of adding a log interface proxy to introduce the diagnostic strategy module, cache module, and log output interface proxy module without significantly increasing developer workload. The names and parameters of the log output functions of the log output interface proxy module must remain consistent with the interface names and parameters of the microservice framework's existing log system. Developers do not need to worry about log diagnostic processing; they only need to use the proxy module's log output interface. When the log output interface proxy module receives log output from the business logic, it does not directly output the log to the log output system provided by the microservice framework. Instead, it caches the log, which can be a memory cache or a Redis cache. After a microservice interface is processed, the proxy module decides whether to actually output the log based on the matching decision results of the filtering rules. Generally, online systems allow log output at a certain level, for example, log output at the WARNING level and above. Therefore, it is worth noting that the introduction of the diagnostic policy module should not affect the log output logic of the existing log level.Therefore, when processing logs, the log output interface proxy module can bypass exception diagnosis for logs above the output level set by the existing system and directly output them to the existing log system. However, it only caches and checks filtering rules for logs below the output level set by the existing system. This reduces resource consumption on the cache and rule engine. In this embodiment, the log output interface proxy module is used to provide an interface for log output. After receiving the log output, the log output interface proxy module first checks the system's preset log output level. Logs that meet the system's preset log output level are directly output to the microservice's log output interface without performing exception diagnosis. Logs below the set log level are then entered into the log cache. When all request logic processing for the microservice interface is complete, the business logic submits a commit request to the proxy interface. The proxy interface calls the rule detection interface based on the request context to make a decision. Based on the decision, it decides whether to output the log to the microservice's log output interface or discard the cached log. Furthermore, it should be noted that filtering rules support default rule settings. Therefore, when using this diagnostic log output strategy, failed microservice requests are generally treated as default rules, and the log will faithfully record all failed microservice requests. At the same time, the rule management module also supports on-demand setting of log output rules, which can flexibly and accurately control the output of log data that developers and operation and maintenance personnel want to obtain within the allowed range, thereby helping developers or operation and maintenance personnel to quickly discover and solve problems.

[0108] This embodiment combines the characteristics of the Internet microservice framework and proposes a software anomaly diagnosis method applicable to Internet microservices in accordance with the output control strategy of log data. This embodiment is based on an abstract microservice interface access model and accurately controls the output of software anomaly diagnosis logs according to the needs of developers or operation and maintenance personnel. This method can accurately output relevant software anomaly diagnosis log information according to the needs of developers and operation and maintenance personnel, thereby helping developers and operation and maintenance personnel to quickly and accurately locate problems. In addition, it should be noted that the software anomaly diagnosis method provided by this embodiment is not only applicable to Internet microservices, but also to other types of software access services. As long as the corresponding software access service meets the software access abstract model defined above, this embodiment does not make specific limitations.

[0109] Figure 7 FIG. 1 shows a schematic diagram of the structure of a software anomaly diagnosis device provided by an embodiment of the present invention. Figure 7 As shown, the software anomaly diagnosis device provided in this embodiment includes: a first determination module 21, a diagnosis module 22 and a second determination module 23, wherein:

[0110] A first determining module 21 is configured to, after detecting a software access request to be diagnosed, determine, based on a log level of the software access request to be diagnosed, whether to send a log corresponding to the software access request to be diagnosed to a log system;

[0111] a diagnostic module 22 configured to perform an anomaly diagnosis on the context data of the software access request to be diagnosed according to a software anomaly diagnosis rule when the first determining module determines, based on the log level of the software access request to be diagnosed, not to send the log corresponding to the software access request to be diagnosed to the log system;

[0112] The second determining module 23 is configured to determine, based on the abnormality diagnosis result, whether to send the log corresponding to the software access request to be diagnosed to the log system.

[0113] Based on the content of the above embodiment, in this embodiment, the context data of the software access request to be diagnosed includes one or more data of the accessor, accessed resource, action, environment and access result contained in the software access request to be diagnosed;

[0114] Correspondingly, the software exception diagnosis rules are rules determined based on the software exception diagnosis requirements corresponding to the software access request to be diagnosed; the software exception diagnosis requirements include: diagnosing whether an exception occurs when accessing one or more specified accessors, and / or, in one or more specified environments, and / or, to one or more specified accessed resources, and / or, performing one or more specified actions.

[0115] Based on the content of the above embodiment, in this embodiment, before performing abnormality diagnosis on the context data of the software access request to be diagnosed according to the software abnormality diagnosis rule, the diagnosis module 22 is further configured to:

[0116] The software anomaly diagnosis rules are generated according to the software anomaly diagnosis requirements: rules for diagnosing whether anomalies occur when accessing one or more specified visitors, and / or in one or more specified environments, and / or to one or more specified accessed resources, and / or performing one or more specified actions.

[0117] Based on the content of the above embodiment, in this embodiment, before performing abnormality diagnosis on the context data of the software access request to be diagnosed according to the software abnormality diagnosis rule, the diagnosis module 22 is further configured to:

[0118] Acquire an anomaly diagnosis rule matching the software anomaly diagnosis requirement from an anomaly diagnosis rule library according to the software anomaly diagnosis requirement;

[0119] The anomaly diagnosis rule base stores rules for diagnosing whether anomalies occur when accessing one or more specified visitors, and / or in one or more specified environments, and / or to one or more specified accessed resources, and / or performing one or more specified actions.

[0120] Based on the content of the above embodiment, in this embodiment, according to the software abnormality diagnosis rule, the context data of the software access request to be diagnosed is diagnosed for abnormality, and according to the abnormality diagnosis result, it is determined whether to send the log corresponding to the software access request to be diagnosed to the log system, including:

[0121] The log corresponding to the software access request to be diagnosed is cached, and according to the software exception diagnosis rules, the context data of the software access request to be diagnosed is diagnosed for exception diagnosis, and when it is determined according to the exception diagnosis result that the context data of the software access request to be diagnosed meets the exception diagnosis rules, the cached log is sent to the log system, and when it is determined according to the exception diagnosis result that the context data of the software access request to be diagnosed does not meet the exception diagnosis rules, the cached log is deleted.

[0122] Based on the content of the above embodiment, in this embodiment, when it is determined according to the abnormality diagnosis result that the context data of the software access request to be diagnosed meets the abnormality diagnosis rule, sending the cached log to the log system includes:

[0123] When it is determined according to the abnormality diagnosis result that the context data of the software access request to be diagnosed meets the abnormality diagnosis rule, the cached log is sent to the log system according to the preset output frequency and output total amount;

[0124] The output frequency refers to the output of the first number of logs per second, and logs exceeding the first number are discarded;

[0125] The total output amount refers to outputting a maximum of the second number of logs, and automatically closing the software anomaly diagnosis rule after outputting the second number of logs.

[0126] Based on the content of the above embodiment, in this embodiment, the software anomaly diagnosis rule includes multiple diagnosis rules;

[0127] Accordingly, when performing abnormality diagnosis on the context data of the software access request to be diagnosed according to the software abnormality diagnosis rules, the number of diagnostic rules running simultaneously cannot exceed the first threshold.

[0128] Based on the content of the above embodiment, in this embodiment, determining whether to send a log corresponding to the software access request to be diagnosed to a log system according to the log level of the software access request to be diagnosed includes:

[0129] Determine whether the log level is greater than or equal to a preset log level threshold according to the log level of the software access request to be diagnosed; if so, send the log corresponding to the software access request to be diagnosed to a log system.

[0130] Since the software anomaly diagnosis device provided in the embodiment of the present invention can be used to execute the software anomaly diagnosis method described in the above embodiment, its working principle and beneficial effects are similar, so they will not be described in detail here. For specific details, please refer to the introduction of the above embodiment.

[0131] In this embodiment, it should be noted that the various modules in the apparatus of the embodiment of the present invention can be integrated into one or deployed separately. The above modules can be combined into one module or further divided into multiple sub-modules.

[0132] Based on the same inventive concept, another embodiment of the present invention provides an electronic device, see Figure 8 , the electronic device specifically includes the following contents: a processor 301, a memory 302, a communication interface 303 and a communication bus 304;

[0133] The processor 301, memory 302, and communication interface 303 communicate with each other via the communication bus 304;

[0134] The processor 301 is used to call the computer program in the memory 302. When the processor executes the computer program, it implements all the steps of the above-mentioned software anomaly diagnosis method. For example, when the processor executes the computer program, it implements the following process: after detecting the software access request to be diagnosed, it is determined whether to send the log corresponding to the software access request to be diagnosed to the log system according to the log level of the software access request to be diagnosed; if not, according to the software anomaly diagnosis rules, the context data of the software access request to be diagnosed is diagnosed, and it is determined whether to send the log corresponding to the software access request to be diagnosed to the log system according to the anomaly diagnosis result.

[0135] It can be understood that the detailed functions and extended functions that can be executed by the computer program can refer to the description of the above embodiments.

[0136] Based on the same inventive concept, another embodiment of the present invention provides a non-transitory computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, all the steps of the above-mentioned software exception diagnosis method are implemented. For example, when the processor executes the computer program, the following process is implemented: after detecting a software access request to be diagnosed, determine whether to send the log corresponding to the software access request to be diagnosed to the log system according to the log level of the software access request to be diagnosed; if not, perform an exception diagnosis on the context data of the software access request to be diagnosed according to the software exception diagnosis rules, and determine whether to send the log corresponding to the software access request to be diagnosed to the log system according to the exception diagnosis result.

[0137] It can be understood that the detailed functions and extended functions that can be executed by the computer program can refer to the description of the above embodiments.

[0138] Based on the same inventive concept, another embodiment of the present invention provides a computer program product, which includes a computer program. When the computer program is executed by a processor, it implements all the steps of the above-mentioned associated application startup control method. For example, when the processor executes the computer program, it implements the following process: after detecting a software access request to be diagnosed, determine whether to send the log corresponding to the software access request to be diagnosed to the log system according to the log level of the software access request to be diagnosed; if not, perform an abnormal diagnosis on the context data of the software access request to be diagnosed according to the software abnormality diagnosis rules, and determine whether to send the log corresponding to the software access request to be diagnosed to the log system according to the abnormality diagnosis result.

[0139] It can be understood that the detailed functions and extended functions that can be executed by the computer program can refer to the description of the above embodiments.

[0140] In addition, the logical instructions in the above-mentioned memory can be implemented in the form of a software functional unit and can be stored in a computer-readable storage medium when sold or used as an independent product. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present invention. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0141] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, i.e., they may be located in one place or distributed across multiple network units. Some or all of the modules may be selected based on actual needs to achieve the objectives of the embodiments of the present invention. Persons of ordinary skill in the art will be able to understand and implement the present invention without inventive effort.

[0142] Through the description of the above embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus the necessary general hardware platform, or of course, by hardware. Based on this understanding, the essence of the above technical solution or the part that contributes to the existing technology can be embodied in the form of a software product. The computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, a magnetic disk, an optical disk, etc., and includes a number of instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) to execute the software anomaly diagnosis method described in each embodiment or certain parts of the embodiment.

[0143] In addition, in the present invention, relational terms such as first and second, etc. are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "comprises", "comprising" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device that includes a series of elements includes not only those elements, but also includes other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further limitations, an element defined by the statement "comprising a ..." does not exclude the presence of other identical elements in the process, method, article or device that includes the element.

[0144] In addition, in the present invention, the description with reference to the terms "one embodiment", "some embodiments", "example", "specific example", or "some examples" means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present invention. In this specification, the schematic expressions of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described can be combined in any one or more embodiments or examples in a suitable manner. In addition, those skilled in the art can combine and combine different embodiments or examples described in this specification and the features of different embodiments or examples without contradiction.

[0145] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the various embodiments of the present invention.

Claims

1. A software anomaly diagnosis method, characterized in that: include: After detecting a software access request to be diagnosed, determining whether to send a log corresponding to the software access request to be diagnosed to a log system according to a log level of the software access request to be diagnosed; if not, performing an abnormality diagnosis on context data of the software access request to be diagnosed according to a software abnormality diagnosis rule, and determining whether to send the log corresponding to the software access request to be diagnosed to the log system according to the abnormality diagnosis result; When it is determined according to the abnormality diagnosis result that the context data of the software access request to be diagnosed meets the abnormality diagnosis rule, the cached log is sent to the log system according to the preset output frequency and output total amount; The output frequency refers to the output of the first number of logs per second, and logs exceeding the first number are discarded; The total output amount refers to outputting a maximum of the second number of logs, and automatically closing the software anomaly diagnosis rule after outputting the second number of logs.

2. The software anomaly diagnosis method according to claim 1, wherein: The context data of the software access request to be diagnosed includes one or more data of the accessor, accessed resource, action, environment and access result contained in the software access request to be diagnosed; Correspondingly, the software exception diagnosis rules are rules determined based on the software exception diagnosis requirements corresponding to the software access request to be diagnosed; the software exception diagnosis requirements include: diagnosing whether an exception occurs when accessing one or more specified accessors, and / or, in one or more specified environments, and / or, to one or more specified accessed resources, and / or, performing one or more specified actions.

3. The software anomaly diagnosis method according to claim 2, characterized in that: Before performing abnormality diagnosis on the context data of the software access request to be diagnosed according to the software abnormality diagnosis rule, the method further includes: The software anomaly diagnosis rules are generated according to the software anomaly diagnosis requirements: rules for diagnosing whether anomalies occur when accessing one or more specified visitors, and / or in one or more specified environments, and / or to one or more specified accessed resources, and / or performing one or more specified actions.

4. The software anomaly diagnosis method according to claim 2, wherein: Before performing abnormality diagnosis on the context data of the software access request to be diagnosed according to the software abnormality diagnosis rule, the method further includes: Acquire an anomaly diagnosis rule matching the software anomaly diagnosis requirement from an anomaly diagnosis rule library according to the software anomaly diagnosis requirement; The anomaly diagnosis rule base stores rules for diagnosing whether anomalies occur when accessing one or more specified visitors, and / or in one or more specified environments, and / or to one or more specified accessed resources, and / or performing one or more specified actions.

5. The software anomaly diagnosis method according to claim 1, wherein: Performing an anomaly diagnosis on context data of the software access request to be diagnosed according to a software anomaly diagnosis rule, and determining whether to send a log corresponding to the software access request to be diagnosed to a log system according to the anomaly diagnosis result, including: The log corresponding to the software access request to be diagnosed is cached, and according to the software exception diagnosis rules, the context data of the software access request to be diagnosed is diagnosed for exception diagnosis, and when it is determined according to the exception diagnosis result that the context data of the software access request to be diagnosed meets the exception diagnosis rules, the cached log is sent to the log system, and when it is determined according to the exception diagnosis result that the context data of the software access request to be diagnosed does not meet the exception diagnosis rules, the cached log is deleted.

6. The software anomaly diagnosis method according to claim 1, wherein: The software anomaly diagnosis rules include multiple diagnosis rules; Accordingly, when performing abnormality diagnosis on the context data of the software access request to be diagnosed according to the software abnormality diagnosis rules, the number of diagnostic rules running simultaneously cannot exceed the first threshold.

7. The software anomaly diagnosis method according to claim 1, wherein: Determining, according to the log level of the software access request to be diagnosed, whether to send a log corresponding to the software access request to be diagnosed to a log system includes: Determine whether the log level is greater than or equal to a preset log level threshold according to the log level of the software access request to be diagnosed; if so, send the log corresponding to the software access request to be diagnosed to a log system.

8. A software anomaly diagnosis device, characterized in that: include: a first determining module, configured to, after detecting a software access request to be diagnosed, determine, based on a log level of the software access request to be diagnosed, whether to send a log corresponding to the software access request to be diagnosed to a log system; a diagnosis module configured to perform an anomaly diagnosis on the context data of the software access request to be diagnosed according to a software anomaly diagnosis rule when the first determination module determines, based on the log level of the software access request to be diagnosed, not to send the log corresponding to the software access request to be diagnosed to the log system; a second determining module, configured to determine, based on the abnormality diagnosis result, whether to send a log corresponding to the software access request to be diagnosed to a log system; The second determining module is specifically configured to send the cached log to the log system according to a preset output frequency and output total amount when it is determined based on the abnormality diagnosis result that the context data of the software access request to be diagnosed meets the abnormality diagnosis rule; The output frequency refers to the output of the first number of logs per second, and logs exceeding the first number are discarded; The total output amount refers to outputting a maximum of the second number of logs, and automatically closing the software anomaly diagnosis rule after outputting the second number of logs.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the program, the steps of the software anomaly diagnosis method according to any one of claims 1 to 7 are implemented.

10. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the software anomaly diagnosis method according to any one of claims 1 to 7 are implemented.

11. A computer program product comprising a computer program, characterized in that: When the computer program is executed by a processor, the steps of the software anomaly diagnosis method according to any one of claims 1 to 7 are implemented.

Images